This guide to the PRINCE2 processes is one in a series of four study guides designed to prepare students for attending a PRINCE2 Foundation course. The other three – PRINCE2 principles, PRINCE2 practices, and People – are available to download as ebooks.
These articles have all been updated to they are based upon the 7th edition of PRINCE2 which was released in 2023. We recommend you read all four articles.
Read on to learn all about the seven PRINCE2 processes and prepare yourself for the PRINCE2 Foundation exam.
In PRINCE2, a process describes which project management team role is responsible for taking decisions and when. Processes are where the principles and practices of PRINCE2 are applied. The 7 processes in PRINCE2 are:
Starting up a project
The purpose is to ensure the prerequisites for initiation are in place by answering the question: “is the project viable and worthwhile?”
- There is a business justification for initiating the project (documented in an outline business case).
- All the necessary authorities exist for initiating the project.
- Sufficient information is available in the project brief to define and confirm the project scope.
- Alternative approaches have been evaluated and the best one agreed.
- Individuals are appointed to work in the initiation stage or perform significant project management roles during the project.
- The work required for the initiation stage is planned and documented in a stage plan.
- Time is not wasted initiating a project based on unsound assumptions.
The process is concerned with preventing poorly conceived projects from ever being initiated as well as progressing viable projects for approval. The process aims to do the minimum necessary to decide whether it is worthwhile to initiate the project. This process provides just enough information (in the form of a project brief) to enable the project board to take a decision to initiate the project.
The trigger for the project is a project mandate from the responsible authority that is commissioning the project (the business). It is expected that the project mandate provides the terms of reference for the project and sufficient information to at least identify the prospective executive of the project.
This process is a pre-project process and should be as short as possible – just long enough to provide sufficient information to the project board so it can authorise (or not) the initiation stage.
In this process, the project executive appoints key members of the project management team and creates an outline business case, which is used to understand how the project will contribute towards the business objectives and how the project will be funded. The project executive is responsible for securing the funding for the project.
The 2 main outputs of this process are a project brief, which ensures that the project has an agreed and well-defined starting point, and an initiation stage plan which covers the work required during the first management stage (the initiation stage). When writing the project brief and initiation stage plan the project manager must review any lessons from previous projects which can usefully be applied on this project.
One part of the project brief is the project product description which describes the project’s major products or outcomes. Another part is the project approach which describes the options for delivering the solution e.g. whether the work will be outsourced or done in-house. It also contains the outline business case containing the business justification.
Directing a project
To enable the project board to make key decisions and exercise overall control while delegating day-to-day management of the project to the project manager. In this way, the project board becomes accountable for the project’s success.
To ensure that:
- There is authority to initiate the project, deliver the project product, and close the project.
- Appropriate management direction and control are provided during the project.
- The project remains viable.
- The business layer has a connection to the project.
- Plans for realizing the post-project benefits are managed and reviewed.
This process starts after the starting up a project process has completed and is triggered by a request to initiate the project.
The process is performed by the project board who manage by exception – it monitors via reports and controls through a small number of decision points. There is no need for regular ‘progress meetings’ with the project manager.
The project board acts as a communication interface from the project to the business layer and provides unified direction and guidance to the project manager. It takes all the ‘big decisions’ about the project to ensure it always remains aligned with the business layer’s strategy.
The project board should provide a single view, otherwise the project manager may act on wrong priorities which increases the risk of project failure. If a single viewpoint is unavailable, the project executive makes the final decision. This means the project board is not a democracy.
The project board is responsible for project assurance, but the project board members may appoint persons to perform project assurance on their behalf. The project board provides ongoing advice and guidance throughout the project to the project manager.
This process contains 5 activities:
Ensures that the project investment is worthwhile and informs all stakeholders and the impacted sites that the project is being initiated. It does this by approving the project brief, and initiation stage plan.
Authorize the project
Approves the project initiation documentation (PID) if the firm foundations for the project are in place. Notifies the business and other interested parties that the project has been authorized.
Give ongoing direction
Reviews highlight, issue and exception reports from the project manager and takes decisions about project issues, risks, and changes.
Authorize a stage or exception plan
Reviews the performance of the current stage and approves the next stage plan (or exception plan) if the business justification still exists and commits the required resources. It also reviews and approves the end stage report. Decides whether to approve the plan or request revisions to the plan. May also instruct the project manager to initiate premature closure of the project. Communicates the status of the project to the business and keep other interested parties informed about project progress.
Authorize project closure
Reviews and approves the end project report if it is satisfied that there is nothing more the project to do. Reviews and gains approval for the updated benefits management approach ensuring that it addresses the expected post-project benefits and transfers responsibility for it to the business.
The project board does not itself create any management products. Instead, it reviews and approves those created by the project manager.
Initiating a project
This process is about laying down the firm foundations for the project to succeed. This is done by enabling the business to understand the work required to deliver the project product before committing to a significant expenditure or resources.
To ensure there is a common understanding of: why the project is needed, the expected benefits and risks; the timescales and costs; the scope; the major products; quality requirements and standards; how issues and risks will be identified and managed; how progress will be monitored and controlled; who will make decisions and when; how baselines will be controlled; who needs information, the format, and timing; and how the project applies business policies, methods, and guidance.
All this information forms the project initiation documentation (PID).
This process starts after the project board takes the decision to authorize initiation.
Compile the information needed for the project board to authorize the project. This is done in the form of the project initiation documentation.
The project initiation documentation contains:
- Elements from the project brief (project definition and project approach).
- Full business case – (derived from the outline version) containing details of timescales, costs, benefits and risks.
- Project management team structure and role descriptions
- Management approaches – procedures, techniques, and standards to be applied and the responsibilities for: change management, benefits management, commercial management, communication management, data management, issue management, quality management, risk management, and sustainability management.
- Project plan – describing how and when the project’s objectives will be achieved. It shows the major products, activities, resources, and people required on the project; provides a baseline against which to monitor the project’s progress.
- Tailoring of PRINCE2 – a summary of how PRINCE2 is tailored for the project.
The project manager also sets up the project log containing lessons log, issue register, product register, quality register, risk register, and daily log. The project log will be updated regularly throughout the project and gives a snapshot of the status of risks, quality, products, issues, and lessons.
The project initiation documentation.
Controlling a stage
To assign work to teams, monitor that work, manage issues, report progress to the project board, and take corrective actions to ensure the stage remains within the tolerances set by the project board.
To ensure that:
- The project management team focuses on delivery within tolerances and progress is monitored to avoid uncontrolled change.
- Risks and issues are controlled.
- The business case is kept under review.
- The agreed products for the stage meet the agreed quality expectations and are accepted.
- The project manager acts as a facilitator rather than a controller by giving freedom to team managers (when possible) using tolerances to minimize escalations.
- The project manager avoids unnecessary escalations and gains freedom to act and learn by discussing their tolerances with the project board.
This process can be triggered by the authorization of a stage plan or exception plan, by receiving advice or instructions from the project board, by a new issue or risk, or by receiving a completed work package from a team manager.
The process covers the day-to-day management of a stage by the project manager whilst, at the same time, the project board manages by exception (hence no need for regular progress meetings).
The project manager authorizes work to teams via work package descriptions. A team executes a work package in the managing product delivery process and ensures that specialist products are approved before handing the products back to the project manager or users.
When authorizing a work package, the project manager should update the project log to reflect the content of the authorized work packages and the planned quality management activities.
Once the work is under way, the team manager sends regular checkpoint reports to the project manager. The project manager collects and reviews progress information from these reports and assesses the estimated time and effort to complete any remaining work.
The project manager sends regular highlight reports to the project board. The project manager takes corrective action only for risks and issues that are within stage tolerances. NOTE: This process is linked to the progress theme, in which the concept of tolerances is explained.
Whilst the stage plan is updated during the stage, to keep it current with stage actuals, the project plan and business case are NOT updated during this process. Instead, they are updated within the managing a stage boundary process at the end of the stage.
When taking corrective action, the project manager should update the product register records of the affected products to record whether any changes are required, or new products are required.
The project manager reviews the stage status at regular intervals and reviews the status of issues and risks. The impacts of any project issues and risks on the project plan and business case are evaluated. Before deciding on a course of action, each issue or risk is registered in the project log and assessed for its impact.
NOTE: In complex projects where some planning work is delivered by using work packages, the project manager could use the controlling a stage and managing product delivery processes during the initiation stage.
Work package descriptions for the team manager(s). Highlight reports, exception reports, issue reports, lessons reports for the project board.
Managing product delivery
To control the link between the project manager and a team manager by agreeing the requirements for acceptance, execution, reporting, and delivery of specialist products. The team manager coordinates an area of work to deliver one or more of the specialist products that form the project product.
To ensure that:
- Work on products allocated to the team is authorized and agreed.
- Team managers and members are clear about what to produce, and the effort, cost, and timescales required.
- Planned products are delivered to quality expectations and within tolerances.
- Accurate progress information is provided to the project manager at an agreed frequency.
This process is triggered by the project manager authorising a work package.
This process is performed by team managers who can be internal or external to the business organization. The process is seen from the team manager’s perspective, whereas the controlling a stage process is seen from the project manager’s perspective. If the external suppliers do not use PRINCE2, this provides a statement of the required working relationship between the team manager and the project manager.
Work should only be started once the project manager has authorised a work package. When a work package is accepted by a team manager, they also agree to the tolerances within it. The team manager makes a (optional) team plan, which the project manager and/or senior supplier authorises. Note: It may not be possible or appropriate for a project manager to authorise a team plan for commercial reasons, in which case agreement about delivery dates and costs will suffice.
Team managers provides the project manager with accurate progress information via checkpoint reports at the frequency agreed in the work package description. For projects using an iterative-incremental delivery method such as agile, the checkpoint report may be based on a ‘pull’ system, whereby the project manager looks at progress charts such as Kanban boards or burn-down charts being maintained by the team manager and development teams.
Once a product has been shown to meet its quality specifications through the quality methods specified in the product description, the team manager obtains approval for completed products from the authorities identified in the product description.
NOTE: If a team manager forecasts a deviation beyond work package tolerances an issue is raised to the project manager. The team manager undertakes a review of the risks against the team plan and advise the project manager of their impact. If the work package description allows the team manager to directly log the risks, the team manager should update the project log. The team manager should then perform any corrective actions required by the project manager.
Checkpoint reports for the project manager. Specialist products to be used by the users within the business organization.
Managing a stage boundary
To provide the project board with sufficient information to be able to:
- review the success of the current stage.
- approve the next stage plan.
- review the updated project plan.
- confirm continued business justification and acceptability of the risks.
- Assure the project board that all products in the current stage plan have been completed and approved.
- Prepare the next stage plan or exception plan.
- Review and, if necessary, update the PID.
- Provide information for the project board to assess the project’s continuing viability.
- Record information or lessons that can help later stages or other projects.
- Request authorization to start the next stage.
It is triggered by the stage boundary approaching, or an exception plan request from the project board. It overlaps with the other processes active at the time.
Towards the end of every stage (except the final stage) the project manager performs this process and starts planning for the next stage by creating a stage plan.
The ‘manage by exception’ principle means that the project board only meets with the project manager at the end of a stage (an end stage assessment). At this point the project manager must provide the necessary information for the project board to make an informed decision about continuing with the project.
This requires the project manager to update the project management team structure required for the next stage, project log, project initiation documentation, business case, and project plan. The project plan is updated by incorporating the actual progress from the stage just finishing, and revised time and cost forecasts for the remainder of the project.
An exception plan is created when the project board asks the project manager to create a new plan, based on recommendations made in an exception report. In an exception situation, the other activities of the process remain the same as at the normal end of stage.
As the project executive is responsible for the business case, the project manager should consult them when reviewing and updating the business case in preparation for the project board’s approval. The business case must reflect the environment external to the project changes and must be reviewed and amended to keep it relevant to the project.
The project manager also assesses the project’s risks using the project log to ascertain the aggregated risk exposure for the project and identify the current key risks that affect the business case.
The benefits management approach is updated with the results from any benefits reviews undertaken during the stage.
A lessons report may also be created in this process. The project product description and quality management approach might need to be revised, based on quality activities during the stage just finishing.
Next stage plan (or exception plan). End stage report which allows the project board to review progress. Updated versions of the business case, project plan, benefits management approach within the project initiation documentation.
Closing a project
To provide a fixed point at which it is recognized that the objectives (or their approved changes), as written in the project initiation documentation, have been achieved, and acceptance of the project product is confirmed.
Where a project is being closed prematurely, this process ensures the project closes in an orderly way.
- Check user acceptance of the project product.
- Ensure the business can support the products after project closure.
- Review project performance against its baselines.
- Assess any benefits already realized and update the benefits management approach to with any post-project benefit reviews.
- Ensure all open issues and risks have been addressed with follow-on action recommendations.
- Ensure the project is closed in an orderly way.
This process is triggered towards the end of the final stage, when all the work has nearly been completed. It is also triggered when the project board instruct the project manager to prematurely close the project.
Closure activities should be planned and resourced when the stage plan for the final stage is created. This process is NOT a separate stage performed at the end of the project but is a process performed towards the end of the final delivery stage (the controlling a stage and managing product delivery processes are still being performed at this time).
A clear end to a project is always better than a long slow drift into operational use where the boundary between the project and business-as-usual becomes blurred. It is a recognition that the original objectives have been met and project has nothing more to contribute and project costs should no longer be incurred.
Closing a project is when responsibility for ongoing operations and product maintenance has been confirmed by the agreed owners and the project management team can be disbanded. It also provides an opportunity to ensure that all unachieved goals and objectives are identified, so they can be addressed in the future.
The objective of evaluating the project is to assess how successful it has been, or the reasons for early closure. By analysing the actual progress metrics for this project against the original baseline PID, and the totality of issues, risks and changes, important lessons can be learned. A lessons report captures the lessons learned from the project which can help improve the management of future projects. Information from the project log is also reviewed by the project manager when preparing an end project report.
Finally, the project manager briefs the project board with a summary of the performance of the project, highlighting where there were concessions for any off-specifications, and requests authority to close the project from the project board.
After the project board authorizes project closure in the directing a project process, the project is now history and the specialist products which were delivered by the project will now be used by users as part of their everyday business-as-usual activities of the business organization.
Lessons report summarizing lessons learned on the project. End project report summarizing achievements on the project compared with the objectives in the project initiation documentation.
Updates to project log, project plan, benefits management approach.
If you have read this article as part of the preparation for a PRINCE2 course, please ensure you follow the remaining instructions given to you by your trainer.
By now, if you have learned the definitions provided in bold in this article and the other two in the series, you should be well-placed to pass the PRINCE2 Foundation exam with flying colours. Good luck with your exam.