Life cycle

General

A P3 life cycle illustrates the distinct phases that take an initial idea, capture stakeholder requirements, develop a set of objectives and then deliver those objectives.

The goals of life cycle management are to:

• identify the phases of a life cycle that match the context of the work;
• structure governance activities in accordance with the life cycle phases.

Projects and programmes are the primary mechanisms for delivering objectives while portfolios are more focused on co-ordinating and governing delivery of multiple projects and/or programmes. As a result the project and programme life cycles have many similarities and follow the same basic approach.

The simplest life cycle is a project life cycle that is only concerned with developing an output:

 

 

 

It all starts with someone having an idea that is worth investigation. This triggers high level requirements management and assessment of the viability of the idea to create a business case. At the end of the phase there is a gate where a decision made whether or not to proceed to more detailed (and therefore costly) definition of the work.

If the idea is good enough, the work will continue to a detailed definition that produces a full justification for the work. Once again this ends in a gate where a decision is made whether or not to proceed to the delivery phase.

Once the output has been produced it is usually subject to an acceptance process before being formally delivered to its new owner. The life cycle comes to an end with the closure of the project.

All outputs are intended to deliver benefits and this can be shown as an additional phase:

 

 

These basic life cycles can be adjusted to many different contexts, e.g. in circumstances where the work is:

• performed by a contractor on behalf of a client;
• a project that is part of a programme;
• scope can be defined early or scope evolves as the work progresses.

The life cycle is also greatly influenced by the complexity of the scope of work, e.g. where the work:

• includes the achievement of outcomes and benefits;
• is extensive and needs segmentation.

These more complex contexts require more sophisticated life cycles and these are generally referred to as programmes.

The phased structure of life cycles facilitates the creation of governance mechanisms, such as:

• Defined processes – the management of each phase can be described as a process made up of a number of relevant activities.

• Stages and tranches – the delivery phase can be subdivided into packages of work, typically called stages on projects and tranches on programmes.

• Gate reviews – these are conducted at the end of a phase, stage or tranche. The sponsor will consider performance to date and plans for the next phase, stage or tranche before deciding whether the business case remains viable, practical and achievable.

• Post-reviews – learning from experience is a key factor in maturity. Post-project and post-programme reviews document lessons learned for use in the future.

• Benefit reviews – these measure the achievement of benefits against the business case.

The two main approaches to the life cycle phases are serial and parallel. The fundamental difference between these is whether requirements and solutions can be defined up front or can evolve throughout the life cycle.

Two factors influence whether a serial or parallel life cycle will be used.

Firstly, where the deliverables can, or need to be, substantially specified before work starts on delivery, the life cycle will be predominantly serial. Where a specification evolves as work proceeds the life cycle will be parallel.

Secondly, even if the work could be fully specified in advance, it can reduce the overall duration of a project or programme if specification work and delivery are run in parallel. This is often called ‘fast tracking’.

Parallel life cycles facilitate delivery methods such as agile and concurrent engineering.

Development life cycles work in conjunction with the P3 life cycle. These focus on the specific technical context of the work and how it will be performed, as distinct from how the overall project, programme or portfolio will be managed. Commonly quoted development life cycles include waterfall and ‘V’.

 

Project

The scope of a project life cycle can take various forms to suit the context. Some projects will be part of a programme and will only be concerned with delivering outputs (the traditional project life cycle). Some projects will be expected to incorporate the management of change and realisation of benefits (the extended project life cycle). A few applications (e.g. whole life costing) may consider the full product life cycle but this is outside the scope of Praxis.

Where a contractor is working for a client, the contractor’s ‘project’ may simply be the development, handover and closure phases of the client’s project that includes identification, definition and benefits realisation.

A typical serial project life cycle is shown below:

 

 

• Identification – in this phase the initial idea is developed and a project brief is created. A sponsor is appointed and, if possible, a project manager. Sufficient analysis must be performed to enable senior stakeholders, led by the project sponsor, to make two decisions:

• Is the project likely to be desirable, achievable and viable?

• Is it worth investing in the definition phase?

• Definition – in this phase the requirements are assessed in greater detail and the preferred solution specified. The management plans, delivery plans and business case are developed and these have to be approved by the sponsor before progressing to the next phase.

• Delivery – this phase may be further broken down into stages. At the end of each stage the continuing justification for the project is be reviewed.

• Handover and closure – the project outputs are handed over and accepted by the sponsor, client or users as required.

• Benefits realisation – where appropriate, a project may include a benefits realisation phase. This is typically done where there is a non-complex, one-to-one relationship between an output and the benefit.

The full product life cycle also includes:

• Operation – continuing support and maintenance;

• Termination – closure at the end of the product’s useful life.

In a parallel project life cycle, most of the phases overlap and there may be multiple handovers of interim deliverables prior to closure of the project.

 

 

The significant characteristic of a parallel lifecycle is the feedback between phases. The delivery of the initial work to be defined influences the next piece of definition. Similarly, the experience of handover, benefits realisation and operation may all feed back into prior phases to create a series of iterations.

Rather than show a parallel life cycle in chronological terms, it can be illustrated as an iteration that is repeated as often as necessary to deliver the output after which the project is closed.

 

 

The idea of iterative or parallel working is taken to its logical conclusion in the agile methods commonly used in IT systems development.

Programme

A typical programme life cycle is shown below:

 

 

• Identification –the vision and outline business case for the programme are created in this phase. A sponsor is appointed to oversee the phase and provide a mechanism for approvals. The expected benefits are outlined and a programme brief is prepared. Sufficient analysis must be performed to enable the main stakeholders, led by the programme sponsor, to make two decisions:

• Is the programme likely to be viable?

• Is it definitely worth investing in the definition phase?

• Definition – the vision is developed into a detailed description of the end state of the programme, often referred to as a blueprint. The management plans, delivery plans and business case are developed so that the sponsor and key stakeholders can make an informed decision whether to proceed with the programme.

• Delivery – this phase is usually broken into groups of projects called tranches that each deliver beneficial change in their own right. A review at the end of each tranche assesses the continuing justification for the programme.

• Benefits realisation – as new outputs are delivered by projects, transformation work has to be done to ensure new ways of working become embedded in business-as-usual. Benefits will be measured and compared to the baseline in the business case. This phase is segmented to reflect the fact that the change management necessary to realise benefits is not constant and will fluctuate in level.

• Closure – closure of the last projects, closure of budgets and demobilising the programme management and delivery teams.

The realisation of benefits will usually continue after the closure of the programme. Some members of the programme team (typically the programme sponsor and business change managers) will continue in their roles to ensure that benefits are realised as required by the business case.

Programme life cycles are inherently parallel. Although the definition phase will produce sufficient detail to authorise delivery, each tranche and project will instigate further detailed definition. As each project delivers outputs, benefits realisation will run in parallel with the programme delivery phase.

Portfolio

Unlike projects and programmes, portfolios are less likely to have a defined start and finish. Portfolio management is a more continual cycle co-ordinating projects and programmes. It may, however, be constrained by a strategic planning cycle that reviews strategy over a defined period. If an organisation has, for example, a three-year strategic planning cycle, then the portfolio cycle will have compatible time constraints.

 

 

The aim of the portfolio is to co-ordinate projects and programmes.

• Initiation – This is a one-off phase that represents the point at which the host organisation decides to set up a portfolio. It is where the infrastructure is created that enables the portfolio cycle to operate.

The portfolio life cycle is inherently parallel. At any point in time the emphasis may be on one phase or another, but aspects of all will be undertaken simultaneously.

• Definition – the projects, programmes and change to business-as-usual required to meet portfolio objectives are identified and evaluated in a selection process that maximises the effectiveness and efficiency of the portfolio.

• In the Praxis process model these four parallel phases are combined within the portfolio management process.

  Categorisation – the projects and programmes may be organised into ‘sub-portfolios’ or groups that share certain characteristics, such as alignment with particular strategic objectives.

• Prioritisation – priorities can be set by strategic objective, return on investment or any other chosen metric. On the assumption that no organisation has sufficient resource to do everything it wants, the prioritisation process forms the basis of the next phase.

• Balancing – the portfolio must be balanced in terms of risk, resource usage, cash flow and impact across the business.

Portfolio management incorporates the overall governance of projects and programmes within the host organisation. The portfolio management team may be responsible not only for co-ordinating the projects and programmes to deliver strategic objectives, but also for improving the maturity of project, programme and portfolio management.