Governance life cycles are generic approaches to structuring the way a project, programme or portfolio is managed. They are typically found in guides and standards that are not context specific. Inevitably, each guide or standard presents the fundamental principles in a different way using different language.
The aim of this encyclopaedia entry is to illustrate that regardless of presentation or language, all guides and standards use the same fundamental principles in their governance life cycles.
The diagram below uses very simple descriptive terms to illustrate a 5-phase linear (serial) life cycle.
In simple linear terms: an initial idea is used to identify high-level approximate costs, risks, timescales and predicted benefits. If that looks promising, work is done on a more detailed definition; if it still looks OK, work can start on the delivery and produce an output. When the output is complete the project is closed down and the customer uses the output to generate benefits.
Of course, it isn’t usually that linear or straightforward, but it’s a good place to start the comparison.
Six guides will be examined to see how they address this life cycle.
APM BoK 7th Edition
The simplest comparison with the Association for Project Management’s (APM) Body of Knowledge v71.
In the APM life cycle the term ‘extended’ is used simply because this life cycle includes ‘Adoption’ and ‘Benefits realisation’. These are shown separately and in parallel in BoK7 but by combining them there is a one-to-one relationship between the phases and, apart from the phase names, the two life cycles are the same.
Now the comparisons need a bit more interpretation because guides such as PRINCE2®, Managing Successful Programmes and the Project Management Institute’s PMBoK Guide® take a process approach to the life cycle.
Once again, Praxis Framework is useful as a benchmark because it carefully maintains the same naming conventions for the life cycle phases and the processes used to manage them.
Each life cycle phase has a corresponding management process. The only difference here being that delivery is broken down into stages and benefits realisation is more realistically shown as something that runs partly in parallel with the delivery process.
The most popular methodology for projects is PRINCE22.
This diagram shows that the delivery process actually combines three processes: the overall co-ordination of the delivery phase (Delivery process), the physical creation of products (Development process) and the management of boundaries between development stages (Boundaries process).
Apart from the names, the arrangement of processes in PRINCE2 is the same – with the one exception that PRINCE2 doesn’t cover the realisation of benefits, which it leaves to the Managing Successful Programmes methodology (but more of that later).
PMBoK Guide® and ISO21500
And so to the PMBoK Guide®3. At first sight this looks quite different with its matrix of knowledge areas and process groups. The trick here is to look at the ‘Project Integration Management’ knowledge area as this shows the processes used to manage the project life cycle.
At a detailed level the PMBOK Guide’s Integration Management processes take a different approach. For example, the closure process doubles up as a project closure process and a stage closure process – but that’s detail, fundamentally the management of the life cycle follows the same principles as Praxis and PRINCE2 (as with PRINCE2, the PMBoK doesn’t include benefits management in the project life cycle).
Since ISO215004 is closely based on the PMBoK Guide’s process model the same principles apply.
These simple comparisons show that most guides adopt the same generic life cycle when designing processes to manage a project. But what about programmes, surely they are different? Not really.
Managing Successful Programmes (MSP) 5th Edition
At first sight the Managing Successful Programmes (MSP)5 lifecycle looks very different. It is drawn mainly as a circle to emphasise the inherently iterative nature of a programme but as we will see, the fundamental principles are maintained.
The MSP life cycle starts with ‘Identify the Programme’ which is pretty much the same as the identification process in Praxis.
The definition phase is then split into two processes: ‘Design the outcomes’ and ‘Plan progressive delivery’. This splits the design of ‘what’ the programme is intended to deliver and ‘how’ the programme will deliver into separate processes with a new gate in between. This means that the ‘what’ is reviewed and approved or rejected before the ‘how’ is designed.
MSP then moves into ‘Deliver the Capabilities’ (i.e. delivering the outcomes). Embed the outcomes includes the management of change in the same way as the benefits realisation process in Praxis.
The idea that the business case is constantly under review, especially at stage or tranche boundaries means that there is an implicit feedback loop in all life cycles. The MSP life cycle makes this explicit by including the ‘Evaluate new information’ process which contains elements of feedback provided by the sponsorship process in Praxis (and PRINCE2).
Thus far, the life cycles shown have all been principally linear. It might be expected that a more adaptive (Agile) approach would be very different. Not necessarily so.
At first sight there is no doubt that the DSDM lifecycle shown above (as described in the Agile Project Management Handbook6) looks very different from the parallel version of the Praxis lifecycle below. Given that appearances are so different, the following comparison goes into greater detail to explain the similarities.
Before the project lifecycle gets underway there is a ‘Pre-project Phase’ that is intended to ensure that “only the right projects are started”. For a stand-alone project kicked-off by a simple mandate, this is likely to be part of the Feasibility phase. Where a project is part of a programme or a portfolio the pre-project work should be performed as part of the programme management or portfolio management processes.
The first phase of the DSDM project lifecycle is Feasibility and this is primarily intended to “establish whether the proposed project is likely to be feasible from a technical perspective and whether it appears to be cost-effective from a business perspective.” This definition is identical in principle to the identification process in Praxis. In fact, DSDM goes on to say that “the effort associated with Feasibility should be just enough to decide whether further investigation is justified or whether the project should be stopped now.”
Praxis refers to the identification phase resulting in an outline business case that takes a view on whether the project is desirable (‘starting the right project’ in DSDM), achievable (‘technically feasible’ in DSDM) and viable (‘cost-effective’ in DSDM).
The DSDM Feasibility phase and the Praxis identification phase are essentially the same thing.
The next phase in DSDM is the Foundations Phase. The management of this phase aligns closely with the definition phase in Praxis. The key thing about applying the phase in agile projects is simply the level of detail in the planning.
The phase is named Foundations in DSDM to emphasise the need to provide a firm foundation for the project, even though much of the detailed understanding of the scope and how to achieve it will not be determined until the Evolutionary Development phase.
The fact that the Foundations phase only plans at a high-level means that with more information gained in the Deployment phase it may be necessary to revisit the Foundations phase. This is the only fundamental adaptation of the standard life cycle to suit greater agility.
DSDM initially states that the Evolutionary Development phase “[builds] on the firm foundations that have been established for the project, the purpose of the Evolutionary Development phase is to evolve the solution.”
Solutions are developed incrementally and deployed in the Deployment phase.
Deployment of a release of a solution does not mean it is the final solution, it just means that it works. There is always the option to iterate further if it adds value to the overall solution.
The DSDM Deployment and Evolutionary Development phases equate to the application of the delivery process and development process in Praxis. Just because a project is agile doesn’t mean that there are not controls, progress reporting, exception plans and so on. It’s just that different tools are employed within the phases. Timeboxes, backlogs, scrum, retrospectives and velocity are all tools and concepts that will be used – but the underlying structure of the phases is the same.
The DSDM process does not explicitly show a closure phase but it does say in its description of the Deployment Phase that “After the last release, the project is formally closed”. There is an implicit use of the Praxis closure phase here.
DSDM then goes on to say that the Post-Project phase “checks how well the expected business benefits have been met.” This is a very significant statement.
Firstly, it implies that the Deployment phase incorporates the benefits realisation phase shown separately in Praxis. Secondly, it reinforces the fact that approaches labelled ‘Agile Project Management’ talk a lot about the value of benefits being central to the purpose of the iterative process. This contradicts the approach of some conventional guides that maintain projects only deliver outputs not benefits. It also supports the Praxis approach which says that benefits realisation is just as likely to be part of a project as it is a programme.
Body of Knowledge 7th Edition, 2019, Association for Project Management, Princes Risborough, Buckinghamshire
Managing Successful Projects with PRINCE2®, 2009, Axelos Ltd., London
Managing Successful Programmes, 2011, Axelos Ltd., London
The Guide to the Project Management Body of Knowledge (PMBoK Guide®) 6th Edition, 2017, Project Management Institute, Newtown Square, Pennsylvania
ISO21500, International Standards Organisation.
Agile Project Management Handbook, Version 2, 2015, Agile Business Consortium, Ashford, Kent