The seven processes and the project journey

The processes describe the journey through a PRINCE2 project: who does what, and when, from the first idea to formal closure. Where the practices describe aspects that run throughout, the processes put them into time order. PRINCE2 7 has seven processes, and each has a purpose, objectives, a context, and activities carried out by particular roles. This lesson walks through the journey, explains what each process is for, and shows how a stage boundary decision works. PRIN-140 and PRIN-141 cover the processes in detail.

The seven processes

Pre-project: starting up a project

Every project begins with a request, sometimes called a project mandate, from whoever has authority to commission it. Starting up a project is a short pre-project process that prevents poorly conceived projects from being initiated. The executive and project manager are appointed, the rest of the project management team is designed, lessons from previous projects are captured, an outline business case is prepared, the project approach is chosen, and the project brief and initiation stage plan are assembled. The project board then decides, in directing a project, whether to authorize initiation.

Directing a project

Directing a project runs from the end of starting up a project until project closure. It describes the project board's decisions: authorizing initiation, authorizing the project, authorizing each stage or exception plan, giving ad hoc direction, and authorizing closure. The board does not manage the project day to day; it manages by exception, receiving regular highlight reports and making decisions at stage boundaries or when exceptions arise. This is one of the clearest differences between PRINCE2 and approaches where a sponsor is involved only informally.

The initiation stage: initiating a project

Initiating a project establishes solid foundations so the organization understands the work before committing to a significant spend. The project manager, with the team, agrees the approaches for managing risk, quality, issues and communication, sets up project controls, creates the project plan, refines the business case and assembles the project initiation documentation (PID). The PID is the reference for how the project will be managed, including tailoring decisions. At the end of initiation, the project manager uses managing a stage boundary to plan the first delivery stage, and the board decides whether to authorize the project.

Delivery stages: controlling a stage and managing product delivery

In each delivery stage, the project manager uses controlling a stage to authorize work packages, review progress, capture and examine issues and risks, take corrective action within tolerance, report highlights to the board and escalate exceptions. Team managers use managing product delivery to accept work packages, execute the work, ensure products meet quality criteria and deliver completed products back. The interface between them is the work package: an agreed set of information about one or more products to be delivered, including tolerances, reporting arrangements and constraints.

Managing a stage boundary

Toward the end of each stage, the project manager uses managing a stage boundary to prepare for the board's decision. This means reviewing performance of the current stage, planning the next stage, updating the project plan and business case, reporting lessons, and preparing an end stage report. If an exception has occurred, the same process is used to produce an exception plan. The board then decides, in directing a project, whether to authorize the next stage, ask for changes or close the project prematurely.

Had the forecast cost been 6.8 million, outside project tolerance, the board would not have the authority to approve it alone: it would refer the matter to corporate, programme or business management, which set project tolerances.

The final stage: closing a project

Closing a project provides a fixed point at which acceptance of the project product is confirmed, objectives are reviewed, the products are handed over to operations, follow-on actions are recorded and lessons are passed on. The project manager prepares the end project report and confirms that a benefits review plan is in place for benefits expected after closure. The board then authorizes closure in directing a project. Premature closure follows the same process in a shortened form: whatever has been produced is secured and handed over, and lessons explain why the project stopped.

Tailoring the processes

On a small project, processes can be combined or simplified. Starting up and initiating might happen in a single short workshop; there might be only one delivery stage; highlight reports might be a weekly email. On a large project, the processes might be supported by a project office, formal gateway reviews and detailed work packages with external suppliers. What must remain is the logic: a deliberate start, a board that directs by exception, staged authorization and a controlled close.

In Canadian organizations, the stage boundaries of a PRINCE2 project often line up with existing approval points, such as Treasury Board or ministerial approvals for large federal investments, provincial capital approval gates or a board of directors' capital committee. Planning these external approvals into the stage plans avoids surprises when the next stage depends on a decision the project board cannot make alone.

Following one project through the processes

It helps to picture a single project moving through the model. Imagine a city deciding to replace its parking meters with a mobile payment service. A council resolution provides the project mandate. In starting up a project, the city appoints its director of transportation as executive and a project manager, captures lessons from a neighbouring city's similar project and prepares a project brief. The project board authorizes initiation. In initiating a project, the project manager agrees approaches to risk, quality, issues and communication, builds a project plan with three delivery stages (procurement, pilot and city-wide rollout) and refines the business case. The board authorizes the project and the procurement stage.

During procurement, the project manager uses controlling a stage to assign work packages to the procurement team, which uses managing product delivery to produce the request for proposals and evaluation report. Near the end of the stage, managing a stage boundary produces an end stage report and a pilot stage plan, and the board authorizes the pilot. When the pilot reveals that older phones cannot run the app, an issue is raised; if fixing it would exceed stage tolerance, the project manager sends an exception report and, if asked, an exception plan. After the rollout, closing a project confirms acceptance by the parking operations team, hands over the service and records follow-on actions, and the board authorizes closure, with a benefits review planned for a year later.

Walking through a familiar example like this, step by step, is one of the best ways to fix the process model in memory and to prepare for Practitioner questions that ask what should happen next.

Notice in that example how control passes between levels. The board never manages the procurement team directly; it authorizes stages and responds to exceptions. The project manager never builds products; it authorizes work packages and monitors them. Team managers never decide whether the project should continue; they deliver products within agreed tolerances. Keeping these boundaries clear is the essence of the PRINCE2 process model.

A useful revision exercise is to draw the process model from memory, mark where each report is produced and who receives it, and then check your drawing against the manual.