The Teal Book: Part D
The purpose of a life cycle is to provide a phased approach for governing work and underpin the delivery plan. The Government Functional Standard for Project Delivery requires each programme or project has a defined life cycle including gates, decision points and assurance reviews.
Few programmes or projects are wholly predictable, making it difficult to plan in detail from the outset for the full duration of the work. The need for a programme or project should result from a policy, problem or opportunity statement which needs to be explored. Normally a number of options for meeting the need should be investigated before a preferred solution is selected. Government programmes and projects are also often unique, working on problems that have not been addressed before or in circumstances that are very different. This creates uncertainty. Defining a life cycle helps to contain this uncertainty, and manage risk or complexity, by progressing the work in phases. As each phase progresses, confidence in successful delivery should increase as the start of each phase is justified, using the knowledge gained from the preceding work, and a decision is made on whether to continue or terminate the work. Taking this approach enables:
The Project delivery glossary defines a life cycle as:
The life cycle provides a phased structure for governing the work and underpinning the delivery plan from start to finish.
A life cycle defines the phases a programme or project needs to pass through if its objectives are to be achieved and the sponsoring body’s risks managed. It is the highest-level view of a delivery strategy. A life cycle should include:
A life cycle should be tailored to suit the circumstances and context of each programme or project. The number of gates, decision points and phases, types of assurance review, delivery approach and form of the business case should be designed to ensure governance and management is appropriate and proportionate.
A life cycle and its phases form the basis for the business case and delivery plan, spanning the period from before work starts until after the programme or project is completed and the sponsoring body is satisfied that the objectives have either been met or are on track to be met.
The senior responsible owner should ensure that a life cycle is in place and that it is effective with uncertainty being driven down as work progresses from investigating ideas and options through to delivery of the outcomes and realising the required benefits.
Designing the right life cycle is a fundamental accountability for the programme or project manager, supported by their teams. They need to keep the life cycle under constant review to ensure it is robust, that resilient delivery plans can be developed from it and that it provides visibility, control and confidence in the work.
In programme and project delivery, the terms ‘life cycle’ and ‘delivery approach’ are frequently thought of as being different ways to describe the same concept when they actually serve different purposes:
Neither the Government Functional Standard for Project Delivery nor The Teal Book mandates how the development of the outputs and delivery of outcomes should be undertaken. It is for those specialists managing the work to decide the appropriate methods, processes, tools, techniques or applications to be used, so long as they are used in a way which conforms with the requirements of the standard and the guidance in this book.
A phase within a programme or project can include any number of different delivery approaches depending on the types of output or product being created or outcomes being delivered. Understanding the difference between the life cycle and the delivery approach helps avoid misunderstandings and allow for a robust life cycle and appropriate delivery approaches to be defined and used.
The main features of a life cycle include:
The Project delivery glossary defines a gate as:
A decision point, carried out as part of formal governance, at significant points in the life cycle to ensure that the decision to invest as stated in an agreed business case and plans is, and remains, valid.
Gates and decision points in a life cycle look to the future rather than the past and so are concerned with readiness to proceed and authorising the start of a phase, not with completing one. For each gate or decision point it should be clear:
The relationship between these features and how they relate to a gate or decision point is shown in Figure 14.1.
The criteria for authorising the start of a phase should include checking that:
It is a mandatory requirement of the Government Functional Standard for Project Delivery that a programme, project or other related work is covered by a business case or equivalent document, which is the basis for the decision to invest. Such decisions have to be made in accordance with the organisation’s delegated authorities and the Green Book (requires sign in) and its supporting documentation. The business case should be developed over a number of phases and should be updated to reflect changes and reviewed before every gate or decision point to justify continuing the work.
Some significant decisions might not coincide with the start of a phase but are still vital to maintaining control and managing risk. Examples are those that represent commitments such as the letting of a significant contract part-way through a phase. The aims of these decision points and criteria are similar to those for starting a phase.
If decisions to start stages in projects within a programme align with the decision point to start a tranche in a programme, it can be more effective to make those decisions at the same meeting as the start of a project within a tranche of a programme cannot be authorised if that tranche itself has not been authorised.
Phases are periods of time when work is undertaken and are applied differently for programmes and projects:
The phases of a programme are called tranches and include projects and other related work. The Project delivery glossary defines a tranche as:
In the context of project delivery, a tranche is a subdivision of a programme designed to enable an incremental approach to delivery of outputs, outcomes and benefits.
The phases of a project are called stages and include work packages.
The Project delivery glossary defines a stage as:
In the context of project delivery, a stage is a subdivision of a project life cycle.
A programme should have at least one tranche. More tranches are added if, for example, the deployment of new capabilities is phased (incremental release) rather than released at a single point in time. The components of a programme should be defined so that they lead to a significant milestone where a decision is required and ultimately to the outcomes. Each tranche can be run as a sub-programme and a hierarchy of sub-programmes can be used to create a work breakdown structure of a programme. For more information, see 14.8 on the programme life cycle.
A project should have at least 2 stages, such as definition and delivery, although all but the simplest projects generally need more stages. During each stage of a project, the full range of work needed to meet the requirements of that stage should be completed. The parcels of work in a stage are called work packages, each of which is managed using an appropriate delivery approach. Work in any one stage should normally be limited to what is needed at the next gate to minimise the spending of effort and money until it is necessary. For more information, see 14.9 14.8 on the programme life cycle.
Phases can overlap, either by design or through slippage. Rarely do the criteria for starting a new phase depend on the completion of every aspect of a previous phase, even in a regulated context.
When designing the phases for a programme or project life cycle, each of the work components should be defined to be as self-contained as possible in pursuit of the outcomes, minimising dependencies on other components. This helps ensure decision-making is as localised as possible and minimises interdependencies between the work components.
Assurance activities, such as reviews, should be undertaken to provide confidence that the programme or project is likely to achieve its objectives. These activities are usually done by people not directly associated with the work. Such activities can be at any level in the programme or project and can be built into standard processes, such as for technical assurance, quality assurance and commercial assurance. In addition, higher-level assurance reviews have to be before major decisions, such as the start of a new phase, to give the decision makers additional insight and assurance to inform their decisions. For more on assurance see13.4.4 on the governance and management framework for programmes and projects.
Government Major Projects Portfolio and mandatory assurance preceding decision points
Programmes and projects in the Government Major Projects Portfolio are required to have an independent assurance review, under the direction of the National Infrastructure and Service Transformation Authority preceding each decision point supported by Treasury approval process for projects and programmes (requires sign in) (see 13.4.4 on governance and management frameworks).
The features of a programme life cycle are shown in Figure 14.2 and include:
A programme may be phased in one or more tranches and cover the whole life of a solution, not just the development and introduction of a solution (see Part F: Solution delivery). Each tranche comprises work components, including:
Unlike a project, it is not possible to define a reference programme life cycle as there are too many variations, although sponsoring organisations can develop a framework for repeatable life cycles for the types of programme they frequently undertake.
A programme is created as a matter of choice when it is considered more appropriate to manage the work as a programme rather than a project because of factors such as its scale, complexity, extent, diverse locations or other reasons (see Chapter 3: Portfolios, programmes and projects in government). When work is first started, a project management approach could be considered the most appropriate but later, as the investigations proceed, it might be found that the work is more appropriately run as a programme. The very simplest of programmes can follow the structure and characteristics of a project life cycle but usually differs in the phasing, spans of control, roles and work hierarchy. It could also be that a major piece of work is managed as a project at government level, while a supplier might choose to run it as a programme in order to manage the complexity, extent of work. timing, or interfaces.
The primary decision points for a programme usually relate to the decision to start a tranche and these can be influenced significantly by the decisions relating to each of the projects and other work components in that tranche. Some decisions need to be aligned and their decision-making combined in a single meeting or forum to ensure the full context is understood. This influences who should make each decision and the scope of any prior assurance review.
Unlike in a project life cycle, where the stages need to be defined to take account of the delivery approaches used, the tranches in a programme life cycle are more focused on achieving the overall outcomes and benefits as effectively and efficiently as possible. Due to the scale and complexity of many programmes, the means to achieve this often emerges as work proceeds as neither the phasing nor the components of the programme can always be predicted with confidence beyond the current tranche.
It is important to understand and define the criteria for when the programme comes to an end and to reflect this in the life cycle so that the work can be closed in a controlled manner. When first designing the life cycle, this will be based around when the delivery of the scope is completed. The life cycle should be revisited if there is a future decision to terminate the work prematurely.
A project comprises stages, each of which is preceded by a gate when a decision is made on whether to start the stage and commit resources and funding. Each gate (except the first) is preceded by an assurance review to provide the decision makers with relevant advice. Simpler projects have fewer stages (minimum of 2) and higher risk projects can have more stages. The scope can also vary considerably; for example, a project might only include the delivery of outputs when the project is an enabling part of a programme or could be standalone and include trials and an extended period of operation.
The features are shown in the reference project life cycle in Figure 14.3 and include:
In practice, a project’s stages may overlap, and the project life cycle might not always be predictable from the outset unless the project is following a well-established pattern. An advantage of a staged approach is that the design of the life cycle can be changed as the project progresses to reflect new information. If the work is turning out to be more complex or risky than expected, more stages can be introduced to contain this. If the project turns out to be simpler, stages could be merged. A project manager, in consultation with their team and the senior responsible owner, may adapt the project life cycle as work proceeds either through change control or when tailoring and preparing the plan for the next phase.
The reference project life cycle in the Government Functional Standard for Project Delivery includes the features shown in Figure 14.3 and described above (see 14.7 on the features of a life cycle and 14.9.1 on the features of a project life cycle). These show the gates, gate criteria, stages, assurance reviews and types of business case needed in the appropriate places. The reference project life cycle provides the basic building blocks to enable a project manager to tailor it to suit their assigned project. In some cases, the reference life cycle can be adopted broadly as defined in the standard; however, in many cases it would need adapting to suit the circumstances of the project.
The reference project life cycle has five stages, each preceded by a gate. There is also a gate to mark the completion of the project. The stages are:
Within each stage:
The reference life cycle in the Government Functional Standard for Project Delivery also outlines what activities need to happen before a project is started and after it has been completed. These activities are the responsibility of the sponsoring body (see 13.3.2 on the sponsoring body).
Government Major Projects Portfolio and mandatory assurance, approvals and business cases
The reference project life cycle in the Government Functional Standard for Project Delivery shows the mandatory assurance reviews, gates and business case type for programmes and projects in the Government Projects Portfolio , aligned with requirements in The Green Book (requires sign in).
This is when a need or opportunity is first formally recognised when the sponsoring body describes why they want to initiate a project.
The focus is on making sure the objectives of the proposed project are aligned to government policy or the organisation’s strategic objectives, or both, and that it meets a recognised need or opportunity that ought to be addressed now. Checks should be made to make sure there is no other work under way which conflicts with or is addressing the same need. The project set up toolkit can support this.
Activities before formally authorising the project to start include:
Further information and detail can be found at 15.4 on identifying a programme or project.
At the gate before the start of the feasibility stage, the decision makers should have verified there is a real policy need or opportunity which needs addressing now and, if acceptable, approved the project brief and authorised the start of the feasibility stage.
The focus of the feasibility stage is for the project manager and team to examine the project brief, identifying and assessing a long list of possible solutions and delivery strategies. A feasibility study may be conducted to provide a structured assessment of whether a proposal is likely to be achievable and worthwhile in practice. It tests the practicalities of a proposal before significant time, money and resources are committed. For more information on feasibility studies including how to conduct one refer to Guide to feasibility studies in programmes and projects.
Project teams should be prepared to negotiate a modification to the project brief if this adds greater clarity and understanding. There should be constructive challenge of assumptions and a search for a wide range of solutions. Further guidance on generating options and long-listing are included in Part F: Solution delivery and in the Green Book (requires sign in). The project manager should, working with the senior responsible owner and policy makers where appropriate, determine if the intended project is likely to be viable in policy, organisational, commercial, delivery and financial terms. As the early stages of a project are the most influential, the sponsoring body is likely to be involved in the important discussions and decisions and steer the senior responsible owner and team in a preferred direction.
The key activities in the feasibility stage include:
Mega projects and mandatory strategy and delivery plans
Mega projects are required to complete a strategy and delivery plan during feasibility and update it throughout the life cycle and laid as a Command paper in Parliament and published on GOV.UK. See Strategy and delivery plan guidance: mega projects on how these should be prepared, approved and published.
Government Major Projects Portfolio and initial feasibility studies
All programmes and projects expecting to join the Government Major Projects Portfolio are required to conduct an initial feasibility study. This should test whether the proposed programme or project is viable before detailed work begins on the programme business case or strategic outline case.
More on this requirement is set out in HM Treasury’s Treasury approval process for programmes and projects (requires sign in) and in GPD-PN 02/26: GMPP feasibility studies.
At the gate before the start of the appraisal stage, the decision makers should have verified that there is a continuing need and priority for the work, that a viable short list of options has been identified for further investigation and, if acceptable, approved the strategic outline case and associated documentation and authorised the start of the appraisal stage.
The focus in the appraisal stage is on identifying the preferred solution, checking:
The project manager and team should elaborate and assess the short-listed options, and from this, recommend a preferred solution. Where appropriate, the policy makers and subject matter experts need to be engaged to help define and analyse the options and select the preferred solution. Further guidance on option appraisal and short-listing is set out in the Green Book (requires sign in).
The work in this stage sets the direction for the remainder of the project, together with a viable plan which takes account of known risks.
The key activities in this stage include:
At the gate before the start of the definition stage, the decision makers should have verified that the project is still justified, and confirmed the preferred solution for further definition, and, if acceptable, approved the outline business case and associated documentation, and authorised the start of the definition stage.
The focus in the definition stage is on defining the selected solution in sufficient detail so that its delivery can be confidently committed to, checking it meets the sponsoring body’s needs and ensuring relevant stakeholders are engaged and supportive. This includes developing detailed requirements and specifications for the work and finalising a robust plan. Suppliers are invited to tender for solution development, solution delivery, or both, and the preferred bidder is identified, subject to confirmation following full business case approval. By the end of the definition stage, the solution, scope, schedule, costs and benefits should be baselined, and risks better understood, enabling contingency provision to be adjusted as appropriate.
Activities in this stage include:
At the gate before the start of the delivery stage, the decision makers should have verified that the project is still justified, and that the solution has been defined to the extent that they can commit, with confidence, to completing the project. If acceptable, the decision makers should have approved the full business case and associated documentation and authorised the start of the delivery stage. This is the last gate at which the project can be stopped before substantial financial and reputational commitments are made.
The focus is on delivering the outputs and preparing for the changes which are prerequisite to the outcomes being achieved and benefits realised. The delivery stage is when the bulk of the costs relating to the project are spent. It comprises the completion of outstanding detailed design, development, creation, and build of the chosen solution together with appropriate verification and validation activities. The required direction has been set by the sponsoring body and the senior responsible owner; it is now up to the project manager and team to deliver the solution and prepare for the associated organisational and societal changes. This stage can take a long time and the societal and business context can change. The full business case needs to be monitored to ensure the project remains viable, especially when issues arise (either internally or from the external environment) which result in a change to the project. During the delivery stage the project team should start making sure those who will operate or use the new solution are prepared and have the resources and capabilities to start initial operations or services in the next stage.
Activities in the delivery stage include:
At the gate before start of the operation stage, the decision makers should have verified that the outputs are complete enough and people ready so that operations and service can start. They should have also confirmed the full business case is still valid (or, if needed, has been updated) and have authorised the start of the operation stage.
The focus in this stage is to have a period of initial operational working to tune the solution, identify latent issues, ensure the necessary organisational or societal changes happen and that the operational and/or service managers understand and can oversee and use the new solution. Actions should be taken to deal with problems and manage any emerging stakeholder issues and operational risks or issues. As operations and services start in this stage, the realisation of outcomes and benefits the project was set up to create should start to ramp up. In addition, work is carried out to withdraw redundant capabilities and ensure the environments left by the project team are clear, including the disposal or repurposing of redundant data, systems, equipment and facilities and the reassignment of remaining team members.
The key activities in this stage include:
The project is over and the project manager and team should have been stood down. The senior responsible owner’s role also ends, other than where the project is part of a programme for which they are also responsible. It is now up to the sponsoring body (for a self-standing project) or the senior responsible owner (for a wider programme) to make sure things stay on track.
The focus should be on whether the outcomes are being sustained so that the benefits continue to be realised. If the benefits fail to meet expectations, the reasons need to be determined so that appropriate action can be taken.
Activities after the project has been completed include:
Further information and detail can be found at 15.11 on reviewing outcomes and benefits.
It is a requirement of the Government Functional Standard for Project Delivery that a phased approach is taken. While the standard provides a reference life cycle to support this, it does not define the number of phases, their names nor how they should be applied in each case.
Instead, the reference project life cycle provides the basic building blocks to enable a project manager to tailor it to suit their assigned project (see 14.9.2 on using the reference project life cycle). This section provides 2 examples of how the reference life cycle can be tailored to reflect different needs and circumstances.
The extended life cycle is an example covering the full extent of operations and the disposal of the outputs at the end. The phases could be managed as a project (in stages) or programme (in tranches) depending on the context of the work. This type of life cycle is sometimes called a product life cycle, system life cycle or asset life cycle. In military capability programmes and projects CADMID/T model is used (see 10.5.1 for more detail on the life cycle).
This example shows a project life cycle which uses an agile approach as the primary delivery methodology, based off GOV.UK’s Service manual agile delivery phases. The number and types of business case, assurance reviews and project stages can differ from project to project to reflect the context, nature and complexity of the work and the need for appropriate and proportionate governance.
A project life cycle based on agile delivery might be expected to be inherently cyclical or iterative. A life cycle is the basis for the delivery plan and so is governed by time (see 14.6 on life cycles and delivery approaches). This means that a life cycle itself cannot be iterative, although the processes and activities within a phase can be (see Figure 14.6). These processes and activities are managed through delivery approaches and can follow any method that is appropriate to the work (for example, predictive, iterative, incremental or adaptive).
Addition of new key points on:
Page permissions updated for public launch.
First published for closed beta consultation.