PRINCE2 2017 Process Model and Project Lifecycle
Understand the project as a connected management system: commission and test the idea, establish foundations, authorise delivery stage by stage, control specialist work, review boundaries and close through an explicit acceptance decision.
Executive summary
Seven processes
Starting Up a Project, Directing a Project, Initiating a Project, Controlling a Stage, Managing Product Delivery, Managing a Stage Boundary and Closing a Project cover the required management lifecycle.
Three management perspectives
The board directs, the Project Manager manages stages, and Team Managers coordinate specialist product delivery.
Lifecycle is iterative
Delivery usually repeats the Controlling a Stage–Managing Product Delivery–Managing a Stage Boundary cycle for each authorised management stage.
Purpose survives tailoring
Process names, activities, products and responsibilities can be tailored, but the source says process purposes and objectives must not be compromised.
What a process means in this method
The supplied material describes a process as a structured set of activities designed to accomplish a specific objective. The seven processes collectively provide the management activities required to direct, manage and deliver a project from the first commissioning trigger to formal closure.
The processes are not technical production methods. They do not prescribe how to design a bridge, configure software, manufacture a component or carry out research. Instead they create the management interfaces around specialist work: who authorises it, who plans it, how products are agreed, how progress is reported, when decisions are escalated and how the project moves from one management stage to the next.
This distinction is important when tailoring. A delivery team can use agile, sequential, engineering, procurement or other specialist methods inside the process model. The management system should integrate with those methods rather than replace them.
The seven processes at a glance
| Process | Primary purpose | Typical management perspective |
|---|---|---|
| Starting Up a Project | Check whether the idea is sufficiently worthwhile and viable to justify initiation; create the initial team, brief and initiation plan. | Commissioning authority, Executive and Project Manager before full initiation. |
| Directing a Project | Enable the Project Board to make key decisions, exercise overall control and delegate day-to-day management. | Project Board across the life of the project. |
| Initiating a Project | Establish solid foundations and a common understanding before significant commitment. | Project Manager preparing the PID and management approaches for Board authorisation. |
| Controlling a Stage | Authorise and monitor work, manage issues/risks, report progress and take corrective action within stage tolerance. | Project Manager during a delivery stage. |
| Managing Product Delivery | Control the Project Manager–Team Manager interface for accepting, executing and delivering Work Packages. | Team Manager and specialist delivery teams. |
| Managing a Stage Boundary | Review the current stage, update the overall picture and prepare the next Stage Plan or an Exception Plan. | Project Manager preparing information for Board decision. |
| Closing a Project | Confirm acceptance, handover, evaluate performance, capture lessons and recommend formal closure. | Project Manager preparing closure recommendation; Board authorises closure. |
Pre-project and initiation
The lifecycle begins with a project mandate or equivalent commissioning trigger. Starting Up a Project deliberately remains brief. Its job is not to produce the full management system; it tests whether there is enough justification, authority, role clarity and information to invest in initiation. The mandate is refined into a Project Brief, an outline Business Case is prepared, key roles are appointed and an Initiation Stage Plan is created.
The Project Board then uses Directing a Project to authorise initiation. Once authorised, Initiating a Project develops the detailed Business Case, Project Plan, management approaches, controls, roles and other material assembled into the PID. This is the point at which the organisation gains a common understanding of what will be delivered, why, how, by whom and under what controls before committing to major delivery expenditure.
During initiation, the next management stage is also prepared so the Board can make an informed decision about authorising project delivery. The process model therefore separates “permission to investigate and plan the project properly” from “permission to commit to delivering the project”.
Mandate
A commissioning trigger establishes the initial need or opportunity.
Start up
Appoint key roles, test the outline justification, create the Project Brief and plan initiation.
Authorise initiation
The Project Board decides whether initiation work should proceed.
Initiate
Develop the detailed Business Case, Project Plan, approaches, controls and PID.
Authorise project/stage
The Board decides whether the project and first delivery stage should proceed.
Delivery-stage cycle
Once project delivery is authorised, the Project Manager controls the current management stage through Controlling a Stage. Work is not simply released as an uncontrolled task list. The Project Manager authorises Work Packages, monitors their status, reviews overall stage progress, reports highlights, manages issues and risks, and takes corrective action within delegated stage tolerance.
From the Team Manager’s perspective, the corresponding process is Managing Product Delivery. The team accepts an authorised Work Package, executes the specialist work using the required methods and quality controls, provides progress information and delivers approved products back to the Project Manager.
Near the end of a management stage, Managing a Stage Boundary prepares the information required for the next governance decision. The Project Manager updates the Project Plan and Business Case, reports stage performance, records lessons and creates the next Stage Plan. The Board then uses Directing a Project to authorise the next stage, ask for more work, change direction or stop the project.
This cycle can repeat several times. The method therefore supports progressive commitment: only the current stage is authorised in detail, while the whole project remains governed by the high-level Project Plan and Business Case.
Directing a Project as the governance thread
Directing a Project is not a short phase between initiation and delivery. The source shows it running across the project lifecycle. The Project Board authorises initiation, authorises the project, authorises stages or Exception Plans, provides ad hoc direction when needed and authorises closure.
Manage by exception keeps the Board out of everyday coordination. The Project Manager works within stage tolerance and reports through agreed controls. When a forecast exceeds delegated authority, the issue is escalated for Board decision. Equally, the source notes that the Project Manager does not have to wait for a stage boundary or a crisis to seek advice; ad hoc direction is a legitimate Board activity.
This continuous governance thread provides the interface to the commissioning authority. If project-level tolerance is threatened, the Board escalates upward rather than redefining its own authority.
The Board remains accountable but delegates operational management. Effective governance means being available for authorisations, exceptions and direction—not becoming an alternative project-management team.
Final stage and project closure
The final management stage differs because there is no ordinary next-stage boundary. Closure activities are planned as part of the final Stage Plan. The Project Manager completes remaining delivery work, verifies that products are accepted and ready for operational support, evaluates performance, updates post-project benefit-review arrangements, captures lessons and prepares follow-on recommendations for unresolved matters.
Closing a Project provides the fixed point at which the Project Manager recommends closure and the Project Board decides whether to authorise it. This explicit end matters. Without it, teams may continue spending, unresolved ownership may persist and operational users may assume the project still owns products that should have been handed over.
The source also requires a controlled closure approach for premature termination. Even when continued business justification disappears, useful products should be salvaged where appropriate, risks and issues transferred, records archived and lessons captured.
Management stages and decision architecture
Management stages divide the project into sections of delegated authority. A stage boundary is not merely a reporting milestone. It is a point at which the Project Board can review what happened, inspect the latest Business Case and risks, examine the next Stage Plan and decide whether to commit more resources.
Technical delivery steps may overlap and need not match the management stages. This gives the process model flexibility across industries. For example, design and testing activities may cross a management boundary, provided Work Packages and product status are controlled and the Board can still make a meaningful decision about continued investment.
An exception can create an unplanned management boundary. If a stage is forecast to exceed tolerance and the Board asks for an Exception Plan, approval of that replacement plan marks the revised boundary for the affected stage.
Tailoring the process model
The source allows processes to be tailored up for high-risk or complex work and tailored down for smaller work. Activities can be combined or split, responsibilities can be adapted, management products can be integrated into existing tools and process names can be changed. Tailoring down does not mean abandoning control; it means using the lightest mechanism that still achieves the purpose and objectives.
Process tailoring should remain consistent with role, theme, product and terminology tailoring. If a small project combines Project Manager and Team Manager responsibilities, the Work Package interface may be informal, but there should still be clarity about authorised work, product acceptance and tolerance. If a programme supplies a Business Case or reporting system, the project may reuse it rather than duplicate information.
The test for a tailored process is therefore functional: does it still achieve the source purpose and objectives, preserve the seven principles and provide the required decision information? If yes, the form can vary considerably.
Practical verification checklist
- Identify the commissioning trigger and keep start-up proportionate.
- Separate authority to initiate from authority to undertake full project delivery.
- Use the PID and detailed Business Case as the foundation for project authorisation.
- Control each delivery stage through authorised Work Packages and stage tolerances.
- Maintain the Project Manager–Team Manager interface even when specialist methods differ.
- Use stage boundaries as genuine investment and governance decision points.
- Keep Directing a Project active across the whole lifecycle for authorisations, exceptions and advice.
- Plan final-stage closure work explicitly and obtain formal acceptance/handover evidence.
- Apply closure controls even when the project is stopped prematurely.
- Tailor activities and products without compromising process purposes and objectives.
Common mistakes to avoid
- Treating the seven processes as technical delivery phases.
- Assuming Directing a Project happens only at stage boundaries.
- Beginning major delivery before the project has been properly initiated and authorised.
- Running specialist teams outside the Work Package and reporting interface.
- Treating a stage boundary as an automatic permission to continue.
- Skipping closure because the final product has been delivered.