3.4 Manage by Stages
Key Takeaways
- PRINCE2 breaks a project into management stages; the Project Board authorises one stage at a time and re-asserts control at each stage boundary.
- Management stages (Project Board control/review points) are distinct from technical stages (work phases run by Team Managers); the two must not be conflated.
- At each stage boundary the board reviews the End Stage Report, the next Stage Plan, and updated PID/Business Case/Project Plan before authorising continuation.
What the principle means
Manage by stages is the control architecture of PRINCE2. The project is divided into management stages, and the Project Board authorises one stage at a time. At the end of each stage the board is given a decision point — a stage boundary — at which it reviews progress, re-confirms the business case, and decides whether to authorise the next Stage Plan. The board never signs a blank cheque for the whole project at initiation; it signs a series of stage-by-stage cheques.
This is the mechanism through which several other principles actually bite:
- Continued business justification is re-tested at the stage boundary, not only at start.
- Manage by exception is enabled because each stage has its own tolerances set by the board.
- Directing by the Project Board is exercised concretely at each boundary.
Management stages versus technical stages
The exam will test the distinction between management stages and technical stages, because they are often confused:
| Dimension | Management stage | Technical stage |
|---|---|---|
| Purpose | Control and review point for the Project Board | A work phase producing specific products |
| Decided by | Project Board (authorises each one) | Team Manager (plans the work) |
| Planning unit | A Stage Plan approved by the board | A Team Plan within a Work Package |
| Boundary output | End Stage Report + next Stage Plan | Completed products, quality records |
A management stage may contain one or several technical stages; the two do not have to align. The board cares about the management stage boundary because that is where its decision rights are exercised.
What is produced at a stage boundary
A stage boundary is a controlled event, and a defined set of outputs is produced so the board can take an informed decision:
| Output | Purpose |
|---|---|
| End Stage Report | Reports actual progress for the stage just completed against its Stage Plan |
| Next Stage Plan | The plan for the stage the board is being asked to authorise |
| Updated Project Plan | Rolled forward to reflect actual progress and revised forecasts |
| Updated Business Case | Re-justifies the project on the basis of current costs, benefits, and risks |
| Updated PID (if needed) | Reflects any change to scope, scope baseline, or project controls |
| Lessons captured | New experience recorded to the Project Log for future application |
The board's decision at the boundary is a go/no-go: authorise the next stage, request a revised plan, or move to premature closure. This is the single most important decision moment in the PRINCE2 control cycle.
Application in exam scenarios
At Bloom's Level 4 the exam tests whether you can analyse a scenario and identify either the correct boundary action or a misunderstanding of stages. Typical scenarios:
- A board that authorises stages 2 and 3 together at the end of stage 1. The correct analysis: this breaches manage by stages — the board may only authorise the next stage, not several in advance, because each authorisation must be informed by the End Stage Report of the preceding stage.
- A team that treats the closure of a development phase as a stage boundary. The correct analysis: a development phase is a technical stage, not a management stage; the boundary decision lies with the Project Board, not the Team Manager.
- A question on what the board reviews at the boundary: the End Stage Report, the next Stage Plan, and the updated Business Case — together these let it re-test continued business justification before authorising more spend.
Why the distinction matters in practice
If technical stages were used as the control unit, the board would be reviewing at points chosen by the delivery team — points that may not coincide with the moments where the business case or risk profile materially changes. Management stages are deliberately placed at the points where the board needs to re-assert control, regardless of where the technical work happens to sit.
How many stages, and where to place boundaries
PRINCE2 does not prescribe a fixed number of management stages, but the guidance gives principles for placing them. A stage boundary should sit where the board needs to re-assert control — typically where significant spend is committed, where a major risk is due to materialise, or where the business case is sensitive to new information. A short, low-risk project may need only two stages (initiation plus one delivery stage); a multi-year programme of work may need many more. The common trap is either to use too few stages (so the board loses control between boundaries) or too many (so the overhead of boundary reporting exceeds the value of the control). The exam may present a scenario with a single year-long stage and expect you to identify that the board has surrendered its control architecture.
Project Plan versus Stage Plan
The distinction between the Project Plan (the whole-project view, high level, rolled forward at each boundary) and the Stage Plan (the detailed plan for the next management stage only, approved by the board at the boundary) is central to the principle. The board never approves a detailed plan for the whole project at initiation — that would be a blank cheque. It approves the Project Plan as a coarse roadmap and a Stage Plan as the binding commitment for the next period. A scenario in which a PM presents a fully detailed 18-month plan at initiation and asks the board to approve it all is breaching the principle: the detail belongs in successive Stage Plans, each authorised at its boundary.
Exception path versus stage boundary
If a stage is heading off-track within its tolerances, the PM manages it. If a stage is forecast to breach its tolerances, the PM raises an Exception Report and the board takes a decision through the exception mechanism — without waiting for the stage boundary. The exception path is the principle's safety valve: it means the board is never trapped into inaction between scheduled boundaries. The exam may test whether you can distinguish an exception (triggered by tolerance breach) from a stage boundary (a scheduled control point).
Worked scenario: placing a boundary
A construction project has a design phase (6 months, £2m) and a build phase (18 months, £14m). The PM proposes a single management stage covering both. The correct analysis: this breaches manage by stages because the board would authorise £16m and 24 months at one point with no scheduled re-test. A better structure places a boundary between design and build, so the board reviews the design outputs, re-tests the Business Case against actual design costs, and authorises the build stage separately.
At the end of stage 1, the Project Board authorises stage 2 and, to save time, also pre-authorises stage 3 so the team can continue without returning to the board. Which analysis is correct under PRINCE2?
Which set of outputs is produced at a PRINCE2 stage boundary to enable the Project Board's go/no-go decision on the next stage?