Sign in

Project Lifecycles and PRINCE2 Discussion White Paper

White Paper

Project Lifecycles and PRINCE2 Discussion White Paper

White Paper

  • White Paper
  • Project management
  • Project planning
  • Project progress

Author  Robert Buttrick

March 19, 2019 |

 27 min read

  • White Paper
  • Project management
  • Project planning
  • Project progress

This discussion paper describes PRINCE2®’s project lifecycle, investigates different approaches taken by other organizations to defining and using a project lifecycle and identifies some common features and issues shared by them all. The paper concludes with a discussion on how all project lifecycle approaches could be improved, with particular reference to PRINCE2.

The current PRINCE2 approach to project lifecycles


The project lifecycle is a fundamental aspect of managing projects using PRINCE2. It is rooted in the PRINCE2 principle ‘manage by stages’, but is also key in facilitating the principles of continued business justification and manage by exception.

PRINCE2 breaks down the project into discrete, sequential sections called ‘management stages’. The choice of the number and nature of the management stages for a project depends on:

  • the size, complexity and risk of the project
  • significant decisions and control points required during the project’s lifecycle
  • organizational policies and standards.

Project lifecycles can comprise as many management stages as necessary to contain the risks associated with the project. PRINCE2 states that the lifecycle must contain at least two stages (the ‘initiation stage’ and a ‘delivery stage’) but does not prescribe the names of any other management stages nor the maximum number required.

Managing by stages ensures that proper preparation is done before work starts on each stage of the project by:

  • providing review and decision points, giving the project board the opportunity to assess the project’s viability at defined intervals, rather than letting it proceed in an uncontrolled manner (facilitating the ‘continued business justification’ principle)
  • ensuring that key decisions are made prior to the detailed work needed to implement them
  • enabling clarification regarding the impact of an identified external influence, such as the corporate budget-setting or the finalization of legislation.

As long as the management stage is forecast to remain within tolerance, the project manager has discretion to make adjustments as required. This enables the project board to manage by exception, retaining the level of control it requires while reducing the administrative overhead of being involved.


PRINCE2 uses the ‘starting up a project’ process with the ‘directing a project’ process to trigger and authorize the start of the first project stage. The purpose is to confirm that the potential project is worthwhile and likely to be viable before any work starts on the project.

PRINCE2 uses the ‘managing a stage boundary’ process to move from each subsequent management stage to the next. The purpose of the process is to provide the project board with sufficient information to be able to:

  • review the success of the current management stage
  • approve the next stage plan
  • review the updated project plan
  • confirm the viability of the project (including approving the updated business case, if needed).

The point to notice is that PRINCE2 prescribes sequential management stages. The decision to start a management stage rests on two criteria, which must both be satisfied:

  1. the previous stage must be completed
  2. the next stage must have an approved plan and the project must be confirmed as justified.

Figures 2.1 and 2.2 show two ways in which the lifecycle is depicted in Managing Successful Projects with PRINCE2 (2017 Edition).

Image of Figure 2.1 The PRINCE2 processes showing two ways the lifecycle is depicted in Managing  Successful Projects with PRINCE2

Figure 2.1 The PRINCE2 processes Copyright © AXELOS Limited 2017

Image of Figure 2.2 showing the development path of a Business Case

Figure 2.2 The development path of the business case (Copyright AXELOS 2017)

Both figures include pre-project and post-project periods, but PRINCE2 only has a process for the pre- project activities (starting up a project). The PRINCE2 business case theme includes advice on benefits management going beyond the end of the project.

The pre- and post-project activities happen as a part of organization management, programme management or portfolio management depending on the project’s context.

Commonly found issues

The project lifecycle is a powerful technique for managing risk on projects, not least by making sure that finances do not run out of control by limiting authorization to one management stage at a time. It is also the foundation of the project’s plan. Unfortunately, project lifecycles are not always understood nor used as well as they might be. Consequently, a number of issues commonly arise in their practical use.


The way project lifecycles are depicted graphically varies from organization to organization; even PRINCE2 uses two approaches. There is no commonly accepted way of depicting a project lifecycle and so each organization designs graphics which it believes tell the right story from their perspective. Many of these graphical representations are, however, ambiguous as to when the project starts, when it ends and when intermediate stages start and end. In many cases, such as shown in Figures 2.1 and 2.2, the period before and after a project starts are depicted using the same symbols as the project stages, thereby giving no visual clue to the reader as to the precise start point or end point for a project.

graphic image or ambiguous process flows lifecycle


Some people mistakenly equate project lifecycles with delivery methods. For example, it is not unusual to hear people incorrectly refer to PRINCE2’s lifecycle as a ‘waterfall’ method. A project lifecycle and a delivery method serve different purposes:

  • Project lifecycles are concerned with decisions to invest funds and resources, one stage at a time, in order to contain risk and solve a business problem or exploit an opportunity. Project lifecycles, being the root of the project plan, are governed by time and cannot be iterative, but activities within a project lifecycle stage can be iterative.
  • Delivery methods (or processes) are concerned with how to develop a specialist product within a project.

A single project can include any number of different delivery methods (including iterative and incremental approaches), depending on the types of product being created.

The confusion between lifecycles and delivery methods probably stems from software developers creating project lifecycles for software development projects which mirrored their development approach. For example, if they were using a waterfall approach, the management stages of the project could have the same names as the waterfall steps. Unfortunately, many people in the software industry still hold this viewpoint, despite the subsequent adoption of iterative and recursive development methods.


In many projects, the activities which happen around the end and start of stages require:

  • An assessment of the quality and completeness of the products developed so far and whether they are likely to meet the business need. This involves a backward-facing review of what has been created to date and its quality. It needs to be conducted by people who are specialists in the types of product being created.
  • A decision, sometimes called a ‘gate decision’, to start the next stage. This is forward-looking and requires the executive or project board to make a commitment based on the business need, context and risk, taking into account advice from specialists on the suitability of the specialist product(s).

The format of the former is usually defined in the development methodology that is being used. For example, for system engineering these could be the system requirements review, preliminary design review, critical design review etc. In the industry, these are often referred to under the general term ‘assurance reviews’ as they provide assurance to the executive and project board. In agile scrum they are called ‘retrospectives’.

Assurance reviews and gate decisions are usually conducted by different people and, being separate, do not have to happen together. However, a review should provide decision-makers with information which is pertinent to their decision.

It can become confusing when those involved in a project refer to both assurance reviews and gate decisions as ‘gates’, ‘quality gates’, ‘stage gates’ or any number of other permutations. The ambiguous ways that project lifecycles are often depicted adds to the confusion as sometimes it is not possible to distinguish between assurance reviews and gate decisions within a project lifecycle.


Despite PRINCE2’s ‘sequential stages rule’, in some real-life projects the next stage of a project may start before the current stage is completed. Project managers and project boards often give the following arguments: ‘If we don’t start work on the next stage now, our entire project will slip’ or ‘The remaining activities are not too much of a problem, so let’s carry on’. External pressure may also be an influence: ‘We need to show our client we are keeping to the schedule, so let’s get on with the next stage and catch up on the remaining work as soon as we can’. In real-life projects, the project board may deem it a low risk to proceed with one stage before the previous one is completed, but PRINCE2 only authorizes the next stage to start if the previous stage has been completed. Therefore, in the cases above, the next stage of the project proceeds with no formal authority.

These examples lead to questions such as:

  • If a stage has not been authorized, where does the money to pay for it come from?
  • Couldn’t you keep within the rules by creating an exception plan?

If financial control on the project was rigorous enough to not permit spend (time sheets or actual procurement) on an unauthorized management stage, then the stage would not be able to proceed. Many organizations get around this because financial controls are weak, allowing funds from one stage to be spent on another. Or they simply may not have staged funding at all and use annual departmental cost centre budgets, for example.

Change control can be used to move the outstanding work to the next stage and hence complete the previous stage, but the effort and time required for reallocating the funds, changing the plans and gaining agreement might not be proportionate to the benefits. PRINCE2 should not impose non-value-added bureaucracy.

How others deal with project lifecycles

The PRINCE2 method includes the most detailed approach to managing stage boundaries, whereas other authoritative publications deal with project lifecycles in different ways and at different levels of detail.

4.1 BSI

The British Standard BS 6079-1:2010 (Principles and guidelines for the management of projects) defines a phased approach, with each stage representing a period of time when work is done, followed by a decision point called a ‘gate’ at which authorization is given to start the next stage. Criteria are set on which a go/no go decision is based. Decision-makers are defined, as are those who should be consulted and the nature of any preceding assurance review.

Figure 4.1 depicts the BS 6079-1:2010 project lifecycle. The pre- and post-project activities are depicted as circles, whereas the stages are depicted as hexagonal arrows, thereby making a visual difference between the two. Decision points to start a stage are shown as entry gates. The arrows depicting the stages dovetail, suggesting that the next stage can start before the previous is completed.

Image of Figure 4.1  diagram from British standard BS 6079-1:2010 showing the relationship between its project lifecycle and integration and support activities

Figure 4.1 Diagram from BS 6079-1:2010 showing the relationship between its project lifecycle and integration and support activities (© Copyright BSI 2017)


The UK Government’s Project Delivery Standard (2018) takes the same approach as the British Standard, except, like PRINCE2, it uses the term ‘stage’ instead of ‘phase’.

Figure 4.2 shows the depiction in the main body of the document, indicating the decision points/gates prior to each stage and at project completion, and the assurance reviews. The part of the diagram, marked ‘Project stages’ demonstrates that gates are entry points to stages and that stages may overlap. Figure 4.3 shows another diagram depicting the project lifecycle from the standard’s annex. It uses the same symbols and colours as those shown in Figure 4.2, except each stage is shown as an arrow.

Image of Figure 4.2 diagram showing The UK Governments example project lifecycle

Figure 4.2 Diagram showing the UK Government’s example project lifecycle © Copyright Crown copyright 2018

Image of Figure 4.3 UK Governments Project Delivery Standard detailed depiction

Figure 4.3 UK Government’s Project Delivery Standard detailed depiction © Copyright Crown copyright 2018

4.3 APM

The Association for Project Management (APM) Body of Knowledge, 6th edition, takes the same approach as PRINCE2 in treating the decision point (it uses the term ‘gate review’) as happening at the end of a stage. Figure 4.4 shows the APM’s depiction of a linear project lifecycle. The term ‘linear’ has been used to differentiate it from other lifecycle models such as spiral. In this depiction, none of the phases in the project lifecycle overlap and not every phase, including the first one (‘Concept’), has a gate review preceding it. It could be inferred that ‘Concept’ happens prior to the project starting and so is not a phase of the project at all. Two phases (‘Operation’ and ‘Benefits realisation’) are shown as coincident, inferring that the project team is stood down before any operations start. It clearly shows that there should be benefits reviews after project closure, but indicates no reviews on the operations or sustainability of any business changes.

Image of Figure 4.4 showing APMs example of linear-project lifecycle

Figure 4.4 Diagram showing APM’s example of a linear project lifecycle © Association for Project Management 2012

4.4 PMI

The 2017 edition of the Project Management Body of Knowledge (PMBOK) by the Project Management Institute (PMI) includes, for the first time, clauses detailing a project lifecycle’s characteristics (please refer to A Guide to the Project Management Body of Knowledge, 6th edition for the lifecycle diagram). In previous editions, many readers erroneously assumed the PMBOK’s Process Groups (Initiating, Planning, Monitoring, Executing and Closing) were a lifecycle. Figure 1-5 within the publication clearly shows they are different.

In many respects the PMBOK now follows similar principles to PRINCE2, BS6079-1:2010 and the UK project delivery functional standard. The project comprises stages, with start and end points, which are chosen to reflect the risk and context for the project. However, the PMBOK only covers the project manager’s role, whereas the other publications take a more holistic view and include the project sponsor (executive) and delivery team as an integral part of project management. As a result, the process model supporting the lifecycle is different. The PMBOK’s knowledge areas take on the same purpose as PRINCE2 themes, BS6079-1:2010 supporting activities and the UK Government standard’s supporting practices. The PMBOK prescribes that every phase should have a decision point (called a ‘phase-gate’) to start a new stage, but the diagram shows a stage (‘starting the project’) with no such decision point. This can be interpreted in two ways: either a phase-gate symbol is missing or ‘starting the project’ is pre-project work like in PRINCE2’s ‘starting up a project’. In other words, the start point for a project is unclear in this depiction.

4.5 ISO

The ISO 21500:2012 Guidance on project management simply says a project lifecycle comprises phases, which are divided by decision points, which facilitate project governance. It includes no diagram to depict the project lifecycle, nor does it define any detailed characteristics for a project lifecycle.


Robert G. Cooper’s approach in his product innovation and development method1 and my Project Workout2 both cover gating and date back to the 1990s. The former is concerned with product development and is the source of the term ‘Stage-Gate®’. The latter extended the approach to any type of project and is the source for the approaches adopted in BS 6079-1:2010 and in the UK Government’s project delivery functional standard, as described in sections 4.1 and 4.2 of this paper.

1 Cooper, R. G. (2008) The Stage-Gate Idea-to-Launch Process-Update, What’s New and NexGen Systems. Journal of Product and Innovation Management. Volume 25, No 3.
2 Buttrick, R. (2019) The Project Workout. Routledge. Fifth edition.

Key elements of a project lifecycle


All the project lifecycles described in section 4 of this paper were designed by skilled and competent practitioners, each bringing their own perspective on what is important. Taking them together, a project lifecycle should have:

  1. management stages: periods of time when work is carried out
  2. a defined start point to each stage (decision point or gate)
  3. a defined end point for each stage
  4. assurance reviews prior to making a go/no go decision to start a stage that the project is likely to meet its objectives (often in the form of a review)
  5. activities before a project is authorized to start, in order to ensure a controlled start
  6. activities after the project is completed to review whether the solution is working as expected, business changes (outcomes) are sustainable and the benefits are being realized.

Each of these is discussed below.


Most projects, irrespective of size and complexity, naturally move through a series of distinct phases from conception to completion. This applies as much for sequential development (for example analyze, design, build, test) as for iterative and agile development, where phases can represent releases or sprints.

Generally, the early stage(s) of a project comprise investigative work that determines what must happen in the later implementation stages.

All the publications advocate a staged (or phased) approach, where the stages make up the project lifecycle. None of them prescribe names for stages (although some give examples with named stages) and none of them prescribe a set number of stages (but PRINCE2, the UK government standard and BS6079- 1:2010 set a minimum of two stages).

All the publications leave the choice of scope of a stage to the project manager. The APM Body of Knowledge and BS 6079-1:2010 make it clear that this can extend to managing change and realizing benefits.


Although the use of stages is similar in all the authoritative sources, the application of decision-making between stages differs. The term ‘gate’ and its derivatives is widely used. Gating can be considered in three ways:

  • entry gate, where the decision is made to start the next stage
  • exit gate, where a decision is made to accept that the previous stage has been completed
  • exit and entry gates, where a decision is made to both approve the completion of the previous stage and authorize the start of the next phase.

PRINCE2 and the APM Body of Knowledge use the ‘exit and entry’ approach, whilst BS 6079-1:2001, the UK Government project delivery functional standard and the PMBOK define the start of a phase and end of a phase as separate and therefore enabling an ‘entry gate’ approach. The pros and cons of the approaches are given in the table below.




Allows a new stage to start at any point if it meets the defined criteria. 

Aligns with senior managements focus and commitment on the future. 

Reduces the bureaucracy of proceeding with the next stage if the previous one has not been completed.

Is not concerned about the previous stage being completed, and so there is a danger that the quality and completeness of work to date is not taken into account.


Ensures all work in a stage is completed adequately.

Is not concerned about whether the next stage should start or not.

Exit and Entry

start unless everything within the previous one has been completed or, if uncompleted, moved to the new stage through change control.

Imposes a rule which may be difficult to adhere to in some circumstances. Can limit the overall approach, for example deliberately starting a new stage (such as a trial) when sufficient outputs are ready even if all work is not planned to be completed.

Recommendations from the discussion paper


Based on the above analysis, the following criteria could be used to design or verify the adequacy of a project lifecycle:

  1. A project should comprise at least two management stages, a ‘justify, set up and plan’ stage and a subsequent ‘doing’ stage. The names and scope of the management stages should reflect the purpose of the stage.
  2. The number of management stages should be appropriate and proportionate to the project being undertaken and the risk involved.
  3. Criteria should be set which should be met before a management stage is authorized to start. This should include, but not be limited to the following criteria:
    • work aligns with strategy and is still needed
    • the business case is acceptable
    • risks have been identified and are acceptable or can be mitigated
    • the solution is (or likely to be) acceptable
    • there are funds and resources to complete the work and support any outcomes
    • there is a plan for the next stage and an outline plan for the remainder of the work.

    The executive or project board may apply other criteria they believe necessary for good governance. This could include requiring the previous stage to be 100% complete where this is vital for control purposes.
  4. There should be an explicit decision point (gate) for each management stage, including the ‘start a project’ stage. The following elements should be clear:
    • criteria for a ‘go’ decision (see point 3)
    • the decision-maker(s)
    • who should be consulted
    • the type of assurance review (if any) required prior to making a decision.

    The names of gates should reflect either their purpose, key management product used or the name of the stage they are the decision point for. Gates should be represented by milestones in the schedule plan.
  5. There should be explicit recognition that a management stage has been completed and this should be represented by a milestone in the schedule plan.
  6. There should be explicit recognition that the products created within a management stage are fit for purpose.
  7. There should be guidance on what pre-project activities are required in order to start a project effectively.
  8. There should be guidance on what post-project activities are needed in order to determine the success of the project.


If a consistent depiction of a project lifecycle is used throughout any document (or on web sites), the scope for misunderstandings is limited. For example, PRINCE2 could use similar depictions of project lifecycles to those used on the UK government’s project delivery functional standard and in BS079-1:2010.

  • The depiction of a project lifecycle should be consistent throughout any printed or online material and clearly show the difference between the different elements defined in the criteria above.
  • The exit point from a stage and the entry point to the next stage should be separately defined, with the entry point being called a ‘gate’.
  • Names of gates or stages should not be prescribed in PRINCE2, leaving it to practitioners to use the most appropriate ones in their circumstances and context. Examples could be given in an appendix, such as those in Section 7 to this discussion paper.

Image of Figure 6.1 showing recommended depiction of a project lifecycle

Figure 6.1 Recommended depiction of a project lifecycle


Naming of processes, products or any part of a project lifecycle needs to be unambiguous if misunderstandings are to be avoided. For example, if the PRINCE2 ‘starting up a project’ was renamed, confusion with ‘initiating a project’ could be avoided. In plain English the words ‘starting’ and ‘initiating’ mean the same thing. Further, as some languages do not have more than one word for ‘start’, changing the PRINCE2 process name could aid translation. Managing Successful Programmes uses ‘identifying a programme’ and the same approach could be adopted for PRINCE2, thereby ensuring not only consistency between these two key AXELOS products, but also removing the ambiguity in PRINCE2 itself. It should be noted that the UK project delivery standard and BS6079-1:2010 use the words ‘identifying a project’ and ‘preparing for a project’ respectively (see Figures 4.1 and 4.2), thereby avoiding the starting versus initiating dilemma.

On a related point, naming a management stage as ‘initiation’ and a process as ‘initiating a project’ could lead people to erroneously believe a process and a management stage are the same. By avoiding such close use of the term, that misperception can be avoided.


For many projects, whilst benefits can accrue during the last stage, the bulk of the benefits are usually realized after the project has closed. If the success of a project is determined by the benefits actually realized, this would have to be tested in the period following project closure. The quality of the output and sustainability of any business changes could also be assessed and corrective action taken if needed. In the case of PRINCE2, this would require the addition of a new PRINCE2 process covering the post-project activities, which mirrors the pre-project ‘starting up a project’ process. This would ensure a complete and consistent coverage between the lifecycle and process views of a project. Figure 6.2 shows the relationship between the current PRINCE2 processes and the lifecycle. A suggested post-project process has been added in grey.

Image of Figure 6.2 Mapping of the current PRINCE2 processes to the project lifecycle

Figure 6.2 Mapping of the current PRINCE2 processes to the project lifecycle

Example project lifecycles

The following are examples to illustrate different project lifecycles for different situations. They also show how using a standard way of depicting the lifecycle makes them quicker to understand and compare.


A project lifecycle should have the number of stages needed to manage the overall risk of the project. The project can comprise the ‘investigative’ stages and the ‘doing’ stages resulting in outcomes and initial benefits realization, as shown in Figure 7.1.

Image of Figure 7.1 Example of a full project lifecycle

Figure 7.1 Example of a full project lifecycle

Alternatively, the project lifecycle can just comprise the investigative stages, such as for a feasibility study, policy development, research or bid, as shown in the example in Figure 7.2.

Image of Figure 7.2 Example of a feasibility project lifecycle

Figure 7.2 Example of a feasibility project lifecycle


From a contractor’s viewpoint, their project could start after a successful bid, as shown in Figure 7.3. There can be any number of stages, which may or may not be primarily based on a technical delivery model and their naming need not reflect the names of the specialist technical activities.

Image of Figure 7.3 Example of a contractors project lifecycle following successful bid

Figure 7.3 Example of a contractor’s project lifecycle, following a successful bid


PRINCE2 requires at least one investigative stage, which includes the activities from the ‘initiating a project’ process, but can also include specialist work and deliverables. The investigative period of the project may have more than one stage as shown in the example in Figure 7.1. For example, the information learned from the investigative work might lead to the progressive development (and confidence in) the business case. In this case, a project brief, including an outline business case, can be defined in starting up a project (pre-project), an initial business case during the first stage of the project (including initiating a project) and a full business case by the end of the second investigative stage. This is shown in Figure 7.4. The UK government’s lifecycle, shown in Figure 4.3, follows a similar approach but has three investigative stages.

Image of Figure 7.4 showing example of investigative stages in a project lifecycle shown in relation to PRINCE2 processes

Figure 7.4 An example of the investigative stages in a project lifecycle shown in relation to the PRINCE2 processes


The plan for a simple project may be very simple, such as on a product checklist or a diagram on a whiteboard in the work room, which can be photographed from time to time. A simple project may only need two stages, the first including initiating the project and the second for undertaking the planned work and closing the project. Figure 8.9 shows a typical two stage project and the alignment to the PRINCE2 processes used.

Image of Figure 7.5 showing typical project lifecycle and processes for simple projects

Figure 7.5 A typical project lifecycle and processes for a simple project


There are many agile techniques and approaches. Agile delivery typically looks at how much can be produced in a fixed timeframe such as a sprint or a release (or how much value can be delivered). This is often shown at the start in the form of a burn chart that can then be tracked. The lifecycle for a project using an agile delivery approach can have as many stages as needed. For example, the first stage could be a ‘foundation’ stage which sets the overall architecture and parameters for the project as shown in Figure 7.6. This could be followed by any number of releases, each delivering a set of features and comprising a set number of sprints. Sprints might deliver into a staging environment for testing and integration, with deployment to operations happening in the next stage in parallel with the next sprints. The sprints and deployment work can be considered as work packages.

Image of Figure 7.6 showing typical project lifecycle using an agile approach

Figure 7.6 An example project lifecycle using an agile approach


The project lifecycle from a contractor’s or supplier’s perspective can be varied to suit the complexity and context of the work. One example has already been shown in Figure 7.3. Figure 7.7 shows three more examples to illustrate some further possibilities.

Example 1 is where the project is solely for the bid and is suitable for a ‘major bid’ situation, where the costs can be very high and the timescales long. The decision to start each stage represents a further step in the bid process, requiring commitment and more funding. If it is won, the ‘handover’ stage is where the bid team transition their knowledge to the delivery team on a follow-on project. Such a project would most likely part be of a programme.

Example 2 is simpler with the pre-project work (starting up a project) aiming to be pre-qualified. If pre- qualified, the bid stage starts (initiating a project). If won, the delivery team is mobilized and delivery undertaken. Example 3 is the simplest, with qualification and bidding happening pre-project. If won, the subsequent delivery stages follow. This example also includes a warranty stage within the project, rather than after the project is completed.

Image of Figure 7.7 showing typical project lifecycle from a supplier perspective

Figure 7.7 Some possible project lifecycles from a supplier perspective


The number and length of stages for projects within a programme is influenced by the programme plan. The programme manager might even define a set of standard management stages that all projects within the programme comply with. In the example in Figure 7.8, there are three projects. Project 2 depends on the output from the initial investigation in project 1; project 3 depends on the output of the detailed investigation in project 2. This shows that the choice of project lifecycle for a project within a programme depends on the strategy and approach taken. A project within a programme might start part way through as the investigative and initial design might have been undertaken in a separate project. This could be followed by a number of detailed design and build projects, all within one programme and under one overall business case.

Image of Figure 7.8 showing typical project lifecycle of projects within a programme are influenced by the programmes delivery strategy

Figure 7.8 Showing how the lifecycles of projects within a programme are influenced by the programme’s delivery strategy


If used correctly, project lifecycles are the basis of one of the most powerful governance concepts in project management. This discussion paper has looked at how project lifecycles are approached in numerous influential publications. It has shown that although there is some convergence in the way they are intended to be used, there are a number of differences which have practical implications. Section 6 provides a number of recommendations; if followed, they would add consistency and remove ambiguity from the way project lifecycles are defined. In addition, the adoption of a common way of depicting lifecycles would in itself help avoid some of the pitfalls that many practitioners fall into when defining and using project lifecycles.


Association for Project Management (2012) APM Body of Knowledge. 6th edition.

AXELOS (2012) Best Management Practice portfolio: common glossary of terms and definitions.

AXELOS (2017) Managing Successful Projects with PRINCE2. TSO, London. Sixth edition.

British Standards Institution (2010) BS 6079-1:2010 Principles and guidelines for the management of projects.

Buttrick, R. (2019) The Project Workout. Routledge. Fifth edition.

Cooper, R. G. (2008) The Stage-Gate Idea-to-Launch Process-Update, What’s New and NexGen Systems. Journal of Product and Innovation Management. Volume 25, No 3.

HM Government (2018) Government Functional Standard: GovS 002: Project delivery: Portfolio, programme and project management.

International Organization for Standardization (2012) ISO 21500:2012 Guidance on project management. International Organization for Standardization (2017) ISO 21505:2017 Project, programme and portfolio management — Guidance on governance.

Project Management Institute (2017) A Guide to the Project Management Body of Knowledge. 6th edition.

About the author

Robert Buttrick is an international authority on business-led, programme and project management. He has a successful track record for building project management capability in a wide variety of blue-chip companies, most recently as BT’s Programme and Project Management Method director. He wrote The Project Workout and is an active contributor to project management methods, best practice, professional journals and conferences. Robert received a distinguished service certificate from the British Standards Institution for services to national and international project management standards. He is also a chartered engineer, a member of the Chartered Institute of Marketing and an honorary fellow of the Association for Project Management. He currently works as a consultant and is a visiting teaching fellow at the University of Warwick.

Author Robert Buttrick

Project Lifecycles and PRINCE2