Managing a Stage Boundary Process in PRINCE2 2017

Executive summary

Purpose of the stage boundary

Managing a Stage Boundary enables the Project Manager to give the Project Board enough information to review the success of the current management stage, approve the next Stage Plan, review the updated Project Plan and confirm continued business justification and acceptable risk.

This is one of the main controls behind manage by stages. A boundary is a deliberate decision point, not an automatic transition. The organisation commits resources to the next stage only after reviewing what has been learned and what the future now looks like.

The process normally occurs near the end of each management stage except the final stage, because the final stage proceeds into project closure rather than another ordinary stage. It also occurs after the Initiation Stage to support authorisation of the first delivery stage and can be triggered to produce an Exception Plan.

Confirm current-stage completion and performance

Before asking for more authority, confirm that the products planned for the current stage have been completed and approved or that any exceptions are explicitly understood. Product and quality records should support this statement. A stage should not be presented as complete simply because its planned end date has arrived.

The Project Manager also evaluates actual time, cost, effort and other performance against the Stage Plan. This information becomes a source for improved future estimates and lessons. Significant issues, risks and changes should be reflected in the stage-end narrative and in the updated project-level information.

If the stage cannot be completed within tolerance, the Project Manager should already have escalated the forecast through an Exception Report. The stage-boundary process can then be used to prepare the revised plan requested by the Board.

Activity 1 — plan the next management stage

The next Stage Plan is prepared near the end of the current stage, except before closure. The source recommends active consultation with the Project Board, Project Assurance, Team Managers and other stakeholders so the plan uses current specialist and governance knowledge.

Review the PID while planning. Check whether customer quality expectations, acceptance criteria, project approach, management approaches, controls, roles or team structure have changed. Lessons from the completed stage should influence estimates, Work Package design, reporting frequency and risk responses.

The stage plan should stay within the realistic planning horizon and align with the updated Project Plan. It provides the detailed baseline and tolerance information the Project Manager will use if the Board authorises the stage.

Activity 2 — update the Project Plan

The Project Plan is the Board’s main overall progress baseline. At the boundary, update it with actual performance from the completed stage and revise forecasts for remaining work using the next Stage Plan and current project information.

This update prevents the Board from making a decision against the original optimistic forecast when the project now knows more. Forecast completion dates, costs, resources, milestones and product timing should reflect reality rather than preserve historical commitments for appearance.

A change in Project Plan does not automatically mean failure. Progressive planning expects increased accuracy. The governance question is whether the revised overall forecast remains within project tolerance and still supports the Business Case.

Activity 3 — update the Business Case

The Business Case is updated at each stage boundary and checked against the principle of continued business justification. The Project Manager develops the update in consultation with the Executive, who remains accountable for the Business Case.

Use the new plan and risk information. Costs may have changed, benefit timing may move, a dis-benefit may be clearer, a major risk may have materialised or an external condition may have altered the need. These changes can affect desirability, viability and achievability.

Do not treat sunk cost as justification to continue. The question is whether further investment remains justified from this point forward. A decision to stop an unjustified project can protect more value than continuing merely because previous stages were expensive.

Activity 4 — report management-stage end

The End Stage Report is prepared as close as practical to the stage end. It summarises performance, product/quality status, issues and risks, lessons, and whether the project is still likely to meet the Project Plan and Business Case.

Together with the next Stage Plan and updated project information, it should give the Board enough evidence to make a continuation decision. The source notes that the report can be useful to the wider project-management team, not only the Board, because it consolidates what was learned and the current state.

A good End Stage Report distinguishes actuals from forecasts and facts from unresolved assumptions. It should not hide variance through newly revised baselines; explain what changed and why.

Activity 5 — produce an Exception Plan

If a stage or the project is forecast to deviate beyond agreed tolerance, the existing plan no longer represents authorised performance. The Project Manager first escalates through an Exception Report. If the Board directs replanning, the Project Manager produces an Exception Plan.

A stage-level Exception Plan normally covers from the current point to the end of the affected management stage and replaces the Stage Plan. In more extreme circumstances a project-level Exception Plan can replace the Project Plan and may need approval above the Board.

Although an Exception Plan may be prepared before the originally planned stage end, its approval marks a revised management-stage boundary. The stage may become longer or shorter. This is important because the Board is explicitly granting a new baseline and authority rather than allowing the Project Manager to reforecast unilaterally.

Lessons, follow-on actions and PID updates

The boundary is a natural point to capture lessons while the experience is fresh. Some lessons should be applied immediately to the next Stage Plan; others may be recorded for later organisational use. The Project Manager may prepare a Lessons Report where the project scale justifies it.

Relevant elements of the PID should be updated when circumstances change, including management approaches, roles, controls, customer expectations or project definition. The Benefits Management Approach may also need adjustment if benefit measurement timing or ownership changes.

Follow-on action recommendations should be recorded where work or decisions need to be carried forward. The objective is to prevent unresolved knowledge from disappearing as one stage team hands over to the next.

Board decision outcomes

After receiving the boundary information, the Board may authorise the next stage, request changes or further information, direct an Exception Plan, seek authority above the project, or stop the project. The method deliberately allows termination when the Business Case no longer justifies continuation.

If the next stage is authorised, its Stage Plan and tolerances become the Project Manager’s new day-to-day baseline. The cycle returns to Controlling a Stage and Managing Product Delivery. If closure is the next step after the final stage, the Closing a Project process takes over rather than using a routine boundary.

This recurring decision architecture is the heart of progressive commitment: learn, update, justify, plan, authorise, then deliver.

Practical verification checklist

• Confirm planned stage products and approvals before reporting completion.
• Prepare the next Stage Plan using current estimates and lessons.
• Update the Project Plan with stage actuals and revised forecasts.
• Update the Business Case in consultation with the Executive.
• Review risk exposure and relevant PID/management-approach changes.
• Prepare an honest End Stage Report with facts, variance and forecasts.
• Record lessons and follow-on actions.
• Produce an Exception Plan only when requested in response to an exception.
• Treat approval of an Exception Plan as a new authorised baseline.
• Do not assume the next stage starts until the Project Board authorises it.

Common mistakes to avoid

• Treating a stage boundary as an automatic calendar milestone.
• Planning the next stage without using lessons and actual performance from the current stage.
• Updating the Project Plan but leaving the Business Case based on old assumptions.
• Rebaselining a stage without first escalating the forecast exception.
• Presenting a stage as complete when key product approvals are missing.
• Continuing because of sunk cost even after justification has disappeared.

Related KEVOS handbook pages