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.