7 August 2007

There is no such thing as a corporate project?

There is no such thing as a corporate project. It's alwasy programme management, and here's why:

After my conversation with my colleague on Agile Project Management ran it's course we got talking about the different aspects of projects and how, to a degree, it’s feasible to break projects into sub-projects.

The project justification and planning work such as defining the problem, defining a solution architecture, cost estimating and strategic planning become a project within itself, with a clear definable outcome; the business case, and a go/no go decision.

The next project becomes the requirements definition, solution design and build work. Another project is the validation and implementation work. And a fourth is the change management aspect where you are tooling around with business processes, user training and so on.

Basically you are breaking the project into sub-projects by typical corporate project governance phases, but not exactly. And that’s the joy. When planning projects today many people break them into each of these stages then line then up with an end-start relationship, but that makes little sense at the execution level because you have inefficient use of resources and as many “business side” project workers will attest, too little time and effort spent on the business implementation work.

If you take this programme management approach to corporate business projects will you solve a lot of the integration and scheduling headaches? Does it make more sense when pitching your plan at the sponsor and steering committee? I think it does.

If you have any ideas about this please comment here and let me know.


  1. I'm not completely sure I understand what you are trying to get at. Are you talking about not limiting all project resources to the confines of a particular waterfall phase? So one group is doing requirements gathering while another is doing execution or training, etc?

    If that is what you mean, I can see your point. I've been on projects where it seemed like half way through gathering requirements, there were components which were already well defined, and it would have been advantageous to get a group of developers working on that part immediately. Instead, we normally wait for a final sign-off on the requirements as a whole.

    Perhaps the best approach in these cases would be to incorporate the flexibility to break off sub-projects when there is a clear opportunity for it, so that requirements sign-off can be done separately...

  2. Thanks for the comment Josh.

    That's pretty much what I mean. For example you can separate out the technical development and the business change activities so they don't have to meet the same waterfall milestones at the same time.

    Same goes if you have a couple of different system components; for example one new system, one piece of integration from the new system to the existing infrastructure, and maybe one or two enhancements to existing infrastructure.

    Ideas like agile methods suggest you can do it in other ways, but programme management is here to use for project managers and addresses many of the scheduling complexity you get out of corporate process driven project management.