Manage by stages

The fourth principle states that a PRINCE2 project is planned, monitored and controlled on a stage-by-stage basis. Management stages are sections of the project that the project manager manages on behalf of the project board, with a decision point at the end of each. At that decision point the board reviews what has been achieved, checks the business case and the plans for the next stage, and decides whether to continue. Manage by stages gives senior management control points without requiring them to manage the detail, and it gives everyone a realistic planning horizon.

The planning horizon problem

Nobody can plan a long project in detail at the start. The further ahead you plan, the less accurate the plan becomes, because requirements change, risks materialize, suppliers perform differently than expected and assumptions turn out to be wrong. A plan with daily tasks for the next three years is not more controlled than a high-level plan; it is less honest. PRINCE2 deals with this by planning at two levels. The project plan covers the whole project at a high level and is used by the board. Each stage plan covers one management stage in enough detail for day-to-day control by the project manager. The next stage plan is produced near the end of the current stage, when much more is known.

Minimum stages and stage boundaries

Every PRINCE2 project has at least two management stages: an initiation stage, in which the project is planned and set up, and one or more delivery stages. Starting up a project happens before the initiation stage and is not a management stage itself. The end of each management stage is a stage boundary. In the managing a stage boundary process, the project manager prepares the end stage report, updates the project plan and business case, reviews risks and issues, records lessons and produces the plan for the next stage. In the directing a project process, the board reviews all of this and authorizes the next stage, or asks for changes, or decides to close the project.

Management stages versus technical stages

A common source of confusion is the difference between management stages and technical stages. Technical stages are groupings of specialist work by type: design, build, test, deploy. Management stages are groupings of work by decision point, chosen so that the board can review progress and commit resources one section at a time. The two often do not line up. A management stage might cover the end of design and the start of build. Technical work can overlap management stages, and that is normal.

How long should a stage be?

PRINCE2 does not fix stage length. The right length depends on several factors, and choosing it is one of the most important tailoring decisions at initiation.

• Planning horizon: how far ahead can the work be planned with reasonable confidence?
• Risk: higher risk calls for shorter stages so the board can intervene sooner.
• Key decision points: natural points where the board must commit significant money, sign a contract or choose between options.
• Technical milestones: the end of a design, the completion of a pilot or a regulatory approval.
• Board capacity: very short stages create frequent board decisions, which can overload senior people.
• Funding cycles: stages may align with budget approvals or fiscal years.

Observe that the stage boundaries are placed before the big financial commitment, not after it. A board that only reviews progress after money is committed has lost the main benefit of the principle.

Stages and tolerance

Manage by stages works hand in hand with manage by exception. The board sets tolerances for each stage. If a stage is forecast to exceed its tolerance, the project manager raises an exception report, and the board may ask for an exception plan, which replaces the current stage plan. An exception plan is produced in the managing a stage boundary process, and the board approves it in the same way as a new stage plan. In this sense stage boundaries can happen early, when an exception forces a new decision.

Manage by stages in agile delivery

In agile delivery, work is organized in short timeboxes such as sprints of one to four weeks. These are not the same as PRINCE2 management stages. A management stage typically contains several sprints or releases, and the stage boundary is where the board reviews the cumulative product, the backlog and the business case. Some organizations align management stages with releases. The principle is satisfied as long as there are planned decision points at which the board reviews progress and justification and authorizes the next commitment.

Why stages give control

Stages give the board three kinds of control. First, commitment control: the board commits resources one stage at a time, so it is never committed to more than one stage of spending without a fresh decision. Second, information control: the end stage report and updated business case give the board a clear, regular picture. Third, change control: the next stage plan can incorporate changes, lessons and new risks, rather than following a plan written months earlier.

Stages also help the project manager. A stage plan that has been approved by the board is a clear mandate. Within it, and within tolerances, the project manager can act without asking permission. That clarity is one reason why well-run PRINCE2 projects often feel calmer than projects without clear decision points.

Failure modes

The end stage report and the board decision

The end stage report is the board's main input at a stage boundary. A good report is short and decision-focused. It compares the stage's performance against its plan and tolerances, summarizes products completed and approved, reviews the business case and the main risks, notes lessons, and sets out the request for the next stage. Alongside it, the board receives the next stage plan and the updated project plan and business case. The board then has three main options: authorize the next stage, ask for changes before authorizing, or prematurely close the project.

A board that simply signs the authorization without reading the updated business case is not applying the principle. The value of a stage boundary lies in the decision. Some organizations require the executive to record, in a sentence or two, why the project remains justified before the next stage is authorized. That small discipline makes the decision visible and auditable.

Stage boundaries and organizational gates

Many organizations have their own approval gates, often tied to funding. A capital project may need approval at concept, design, procurement and construction. A technology project may need approval before architecture sign-off and before go-live. PRINCE2 stage boundaries can be aligned with these gates, so that the board's decision and the organization's approval happen together. Where gates and stages do not align, the tailoring record should explain how they relate, so nobody is confused about who must approve what.

Initiation as a stage

The initiation stage deserves special mention because it is often rushed. During initiation the project manager produces the project initiation documentation: the business case, project plan, risk, quality, configuration and communication management approaches, the project controls and the tailoring decisions. Initiation is itself a management stage, with its own plan and tolerances, and it ends with a board decision to authorize the project and the first delivery stage. Skipping or compressing initiation saves a little time at the start and often costs much more later, because the project starts delivery without agreed products, tolerances or controls.