4.1 7 PRINCE2 Processes Overview

4.1 The Process Model at a Glance

PRINCE2 7 (PeopleCert, 2023) defines a process as a structured set of activities designed to accomplish a specific objective. A process takes one or more inputs and turns them into defined outputs. Crucially, each process answers the question "which role decides, and when?" — processes are where the seven principles and seven practices are actually put to work. PRINCE2 7 kept all seven processes from the 6th edition unchanged in name and purpose; the bigger 2023 change was renaming the seven themes to practices and replacing several strategy documents with management approaches.

The seven processes are:

Memorize the sequence SU → DP → IP → CS / MP → SB → CP. SU and IP happen exactly once. DP sits above the whole project at the Project Board level and is invoked at every authorization gate. CS, MP, and SB repeat for each delivery management stage.

Pre-project, Initiation, and Delivery

It helps to group the processes into a timeline. Pre-project is just SU, triggered by the project mandate. The initiation stage is IP (the project's first management stage). Every subsequent delivery stage runs CS, MP, and SB together. The final stage runs CS, MP, and CP. DP overlays all of it.

A PRINCE2 project must have at least two management stages: the initiation stage plus at least one delivery stage. This is required by the Manage by Stages principle — the Project Board cannot commit the whole project blindly, so it authorizes one stage at a time.

Management stages versus technical stages

This distinction is heavily tested. A management stage is the unit the Project Board controls — it ends at a decision point where the board reviews progress and authorizes (or stops) the next stage. A technical stage (also called a delivery step) is defined by the type of work or specialist skill, such as design, build, or test. The two need not align:

• A management stage may contain several technical stages.
• A single technical stage may span more than one management stage (e.g. a long build phase split across two board reviews so the board retains control).

Management stages are about governance and decision points; technical stages are about the nature of the work. The Project Board controls management stages; specialist teams work within technical stages.

What Each Process Delivers

A quick map of each process's headline purpose and its signature management product:

• SU — confirms the project is worthwhile; produces the Project Brief, an outline Business Case, and the initiation stage plan.
• DP — the Project Board exercises overall control and makes go/no-go decisions; it creates no products itself but authorizes initiation, the project, each stage, exceptions, and closure.
• IP — builds firm foundations; produces the Project Initiation Documentation (PID), the detailed Business Case, the management approaches, and the Project Plan.
• CS — the Project Manager's day-to-day engine; authorizes Work Packages and produces Highlight Reports (and Exception Reports when tolerances are forecast to be exceeded).
• MP — the Team Manager builds the products and reports via Checkpoint Reports.
• SB — closes one stage and plans the next; produces the End Stage Report and the next Stage Plan.
• CP — confirms acceptance and produces the End Project Report.

Keep one rule front of mind: the Project Board directs but does not manage. Through manage by exception, the board sets tolerances and lets the Project Manager run the stage, stepping in only at authorization gates or when an exception is escalated.

How Processes Relate to Principles and Practices

A frequent Foundation misconception is that processes, principles, and practices are three separate checklists. They are not. The seven principles are the obligations that make a project a PRINCE2 project; the seven practices (Business Case, Organizing, Plans, Quality, Risk, Issues, Progress) are the aspects of project management that must be addressed continually; and the seven processes are where and when those practices are applied and the principles enforced.

For example, the Manage by Stages principle is enforced by SB and DP at every boundary; the Progress practice is applied through Highlight Reports (CS) and Checkpoint Reports (MP); and the Business Case practice is applied from the outline version in SU to the detailed version in IP and its review in SB.

The two-tier authorization model

Every PRINCE2 project runs on a two-tier control structure that the processes implement:

• The Project Board (directing tier) makes the few high-impact decisions — authorize initiation, authorize the project, authorize each stage, respond to exceptions, and authorize closure — all within DP.
• The Project Manager (managing tier) runs each stage day to day within CS, delegating product creation to Team Managers via Work Packages handled in MP.

This separation is why the processes are arranged as they are. The board is deliberately kept out of day-to-day work so it can stay objective about viability, while the Project Manager is given a clear tolerance envelope and only escalates when that envelope is at risk. Understanding this hierarchy makes most process questions answerable: identify the tier the stem is describing, and the candidate processes narrow to just one or two.