12.2 Managing a Stage Boundary (SB) Process & End Stage Reporting

Managing a Stage Boundary (SB) Process & End Stage Reporting in PRINCE2 7

Practitioner Core Mandate: In long or complex projects, governance can easily fail through gradual inertia. Without structured checkpoints, delivery teams often transition seamlessly from one phase to the next without pausing to verify whether the original business rationale still holds, whether the budget has been eroded, or whether external conditions have made the deliverables obsolete. The Managing a Stage Boundary (SB) process enforces disciplined, periodic decision gates. It equips the Project Board with the objective performance data and forward-looking plans required to assess project health and make conscious, defensible go/no-go decisions.

---

1. Purpose, Timing & Governance Rationale of Managing a Stage Boundary (SB)

The Purpose of Managing a Stage Boundary

The purpose of the Managing a Stage Boundary (SB) process is to enable the Project Manager to provide the Project Board with sufficient information to review the success of the current stage, approve the next Stage Plan, review an updated Project Plan, and confirm continued business justification and acceptability of the risks.

Core Governance Objectives

The SB process ensures that:

• Delivery performance in the concluding stage is systematically audited against its approved Stage Plan.
• The Project Board is assured that all products scheduled for the current stage have been completed, verified, and approved according to their Product Descriptions.
• A realistic, detailed Stage Plan is produced for the upcoming management stage using product-based planning.
• The overall Project Plan is updated with actual cost and duration metrics, providing realistic forecasting for the remainder of the project.
• The Business Case and Benefits Management Approach are formally re-evaluated to confirm that the project remains viable, desirable, and achievable.
• Project risks and active issues are re-assessed to ensure overall risk exposure remains within organizational risk appetite.

                    THE STAGE BOUNDARY DECISION GATEWAY
   
   STAGE N (CURRENT STAGE)                          STAGE N+1 (NEXT STAGE)
   
   ┌────────────────────────────────┐               ┌───────────────────────┐
   │ Controlling a Stage (CS)       │               │ Controlling a Stage   │
   │ & Managing Product Delivery    │               │ (CS)                  │
   └───────────────┬────────────────┘               └───────────────────────┘
                   │                                            ▲
                   ▼                                            │
   ┌────────────────────────────────┐                           │
   │ Managing a Stage Boundary (SB) │                           │
   │ • Plan next stage              │                           │
   │ • Update Project Plan          │                           │
   │ • Update Business Case         │                           │
   │ • Prepare End Stage Report     │                           │
   └───────────────┬────────────────┘                           │
                   │                                            │
                   ▼                                            │
   ┌────────────────────────────────────────────────────────────┴───────────┐
   │ Directing a Project (DP): Authorize a Stage or Exception Plan          │
   │ (Project Board reviews boundary package and commits next-stage funds)  │
   └────────────────────────────────────────────────────────────────────────┘

Strategic Timing: Why SB Occurs Near the End of a Stage

A vital exam principle governs the timing of SB: Managing a Stage Boundary is executed near the end of the current management stage, NOT after the stage has completely finished.

• Preventing Hiatuses: If the Project Manager waited until every single deliverable was handed over before starting SB, the project delivery team would sit idle with no authorized Work Packages while the PM spent two to three weeks planning the next stage and scheduling a Project Board meeting.
• Preventing Premature Drift: Conversely, if the delivery team began working on next-stage deliverables before formal Project Board approval, they would be executing unauthorized work, breaching organizational governance.
• The Overlapping Reality: Therefore, the PM initiates SB activities towards the end of the current stage—typically when the final Work Packages are in testing or review. This allows the PM to assemble the boundary package and secure Project Board authorization just as the current stage concludes, enabling a seamless transition into the next stage.

---

2. Step-by-Step Activities in Managing a Stage Boundary

PRINCE2 7 table 18.1 names six activities in SB (18.4.1 to 18.4.6). Each generates or refines the management products that form the "boundary package". Note that the exception-plan route is a named activity of its own, and that requesting the next stage is the explicit hand-off to the project board:

┌─────────────────────────────────────────────────────────────────────────────┐
│            THE 6 ACTIVITIES IN MANAGING A STAGE BOUNDARY (SB)               │
├─────────────────────────────────────────────────────────────────────────────┤
│ 18.4.1 PREPARE THE NEXT STAGE PLAN:                                         │
│    • Apply the PRINCE2 planning technique to build the next Stage Plan      │
│    • Create Product Descriptions for the next stage; update the PID if      │
│      necessary; recommend stage tolerances across the 7 targets             │
├─────────────────────────────────────────────────────────────────────────────┤
│ 18.4.2 PREPARE THE EXCEPTION PLAN (IF REQUIRED):                            │
│    • Triggered by an exception plan request from Directing a Project        │
│    • Creates the Exception Plan and revised Product Descriptions            │
│    • Output: exception plan approval request back to the project board      │
├─────────────────────────────────────────────────────────────────────────────┤
│ 18.4.3 UPDATE THE PROJECT PLAN:                                             │
│    • Incorporate actuals from the completed stage (cost, time, resources)   │
│    • Revise forecasts, critical path, and budget for remaining stages       │
├─────────────────────────────────────────────────────────────────────────────┤
│ 18.4.4 UPDATE THE BUSINESS CASE:                                            │
│    • Re-assess viability, costs, timeline, benefits, and sustainability     │
│    • Update the Benefits Management Approach if required                    │
├─────────────────────────────────────────────────────────────────────────────┤
│ 18.4.5 EVALUATE THE STAGE:                                                  │
│    • Report stage performance against the approved Stage Plan baselines     │
│    • Review the project log (risk, issue, quality, product registers) and   │
│      the lessons log; use the communication management approach             │
│    • Output: END STAGE REPORT created                                       │
├─────────────────────────────────────────────────────────────────────────────┤
│ 18.4.6 REQUEST THE NEXT STAGE:                                              │
│    • Output: next stage request, which triggers Directing a Project         │
│      (activity 14.4.4 'authorize a stage or exception plan')                │
└─────────────────────────────────────────────────────────────────────────────┘

[!EXAM WATCHPOINT: SB IS NOT A 'REVIEW RISKS' ACTIVITY] Reviewing risk and issue status is real work, but PRINCE2 7 places it inside evaluate the stage (18.4.5) rather than making it a separate activity. Two activities candidates often forget are prepare the exception plan (if required) and request the next stage — and an exception that is forecast mid-stage enters SB through 18.4.2, not through 18.4.1.

2.1 Prepare the Next Stage Plan (18.4.1)

The Project Manager cannot manage a stage without an approved plan. Using the Product-Based Planning technique:

• The PM identifies the specialist products to be created in the upcoming stage.
• Writes or refines Product Descriptions for each deliverable, including specific quality specifications, quality tolerances, and acceptance methods.
• Constructs the Product Breakdown Structure (PBS) and Product Flow Diagram (PFD) for the stage.
• Estimates resource requirements, work effort, durations, and costs.
• Establishes stage-level tolerances across all seven performance targets (Cost, Time, Quality, Scope, Benefits, Risk, and Sustainability) to be recommended to the Project Board.

2.2 Update the Project Plan (18.4.3)

Planning in PRINCE2 is rolling and empirical. The Project Plan must reflect operational reality:

• Replacing Estimates with Actuals: The estimated costs, durations, and resource usage for the stage just ending are replaced with actual expenditures and completion dates.
• Adjusting Future Forecasts: If the current stage experienced delays or cost variances, these empirical trends are factored into the remaining stages.
• Updating the Critical Path: The schedule is recalculated, reflecting changes to milestone dates and final project completion.
• Re-evaluating Project Tolerances: The PM confirms whether the overall project-level tolerances (agreed with the business layer) remain achievable.

2.3 Update the Business Case and Benefits Management Approach (18.4.4)

A project is not a static machine; external markets, organizational strategies, and inflation change over time. The Business Case must be dynamically verified at every boundary:

• Costs & Timeline Re-assessment: The PM feeds the updated costs and schedule from the revised Project Plan into the Business Case's investment appraisal.
• Re-verifying Expected Benefits: The PM consults the Senior User to verify whether expected business benefits are still realistic and achievable.
• Re-evaluating Dis-benefits: Any newly identified negative operational side-effects are quantified.
• Benefits Realization Tracking: If the stage just concluded was scheduled to deliver early operational benefits (common in incremental and agile deliveries), the PM documents what was achieved and updates the Benefits Management Approach.

2.4 Reviewing Risk and Issue Status (part of 18.4.5, Evaluate the Stage)

At a stage boundary, the project risk landscape shifts dramatically:

• Closing Expired Risks: Threats and opportunities that applied solely to the finishing stage (e.g., procurement negotiations, specialized foundation excavation) are formally closed.
• Assessing Emerging Risks: New uncertainties associated with the upcoming stage's technology, suppliers, or environment are identified and logged in the Risk Register.
• Evaluating Total Risk Exposure: The PM calculates the aggregate risk exposure and compares it against the organization's approved risk appetite and Risk Budget.
• Reviewing Open Issues: Outstanding Requests for Change (RFCs), off-specifications, and problems/concerns in the Issue Register are reviewed to ensure their resolution paths are accounted for in the next Stage Plan.

2.5 Evaluate the Stage: Preparing the End Stage Report (18.4.5)

The End Stage Report is the definitive performance retrospective produced by the Project Manager for the Project Board. It provides an objective summary of stage delivery:

┌─────────────────────────────────────────────────────────────────────────────┐
│                    COMPONENTS OF AN END STAGE REPORT                        │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. STAGE PERFORMANCE SUMMARY: Actuals vs. baselines for the 7 targets       │
│    (Cost, Time, Quality, Scope, Benefits, Risk, and Sustainability)         │
│ 2. PRODUCT STATUS ACCOUNT: List of all products completed, approved, or     │
│    granted concessions; status of any off-specifications                    │
│ 3. QUALITY AUDIT SUMMARY: Results of quality reviews, inspections, & tests  │
│ 4. BENEFITS REALIZED: Measurement of any operational gains delivered        │
│ 5. RISK & ISSUE HIGHLIGHTS: Summary of major materialized issues and risks  │
│ 6. LESSONS REVIEW: Key operational lessons identified during stage delivery │
└─────────────────────────────────────────────────────────────────────────────┘

2.6 Lessons at the Boundary, then Request the Next Stage (18.4.6)

Learning from experience is a core PRINCE2 principle. Rather than waiting until the very end of the project to capture learnings:

• The Project Manager reviews what went well, what went poorly, and what unexpected anomalies occurred during the stage.
• Updates the Lessons Log with actionable insights.
• If a significant lesson has organizational value beyond the project (or needs immediate dissemination to other projects), the PM can draft an interim Lessons Report for distribution to the business layer.

---

3. The Stage Boundary Governance Package & The Project Board Decision Gate

Once the activities of SB are complete, the Project Manager packages these management products into a comprehensive Stage Boundary Package and formally requests a Project Board decision.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     THE COMPLETE STAGE BOUNDARY PACKAGE                     │
├─────────────────────────────────────────────────────────────────────────────┤
│ • The End Stage Report (performance retrospective of the finishing stage)   │
│ • The next Stage Plan (detailed operational roadmap for the upcoming stage) │
│ • The updated Project Plan (empirical forecast for total project lifecycle) │
│ • The updated Business Case (re-assessed viability, ROI, and justification) │
│ • Updated Risk & Issue Registers (current risk exposure and issue status)   │
│ • Updated Lessons Report / Lessons Log (captured operational learnings)     │
└─────────────────────────────────────────────────────────────────────────────┘

The Board's Deliberation under Directing a Project (DP)

The Project Board reviews the boundary package under the process Directing a Project (DP)—specifically the activity Authorize a Stage or Exception Plan. The Board conducts an End Stage Assessment where it evaluates three critical questions:

1. Was the concluding stage executed successfully according to its plan and tolerances?
2. Does the project continue to have robust business justification (is it still viable, desirable, and achievable)?
3. Is the proposed Stage Plan for the next stage realistic, achievable, and supported by acceptable risk levels?

Possible Project Board Outcomes:

• Authorize the Next Stage: The Board formally approves the next Stage Plan, re-baselines stage tolerances across the seven targets, and commits the financial capital and resources required for execution.
• Request Plan Modifications: If the Board finds the Stage Plan unrealistic, the risk exposure excessive, or quality specifications inadequate, it instructs the PM to revise the Stage Plan.
• Premature Project Closure: If market changes, cost escalations, or strategic realignments have destroyed business justification (the project is no longer viable), the Project Board does not authorize the next stage. Instead, it instructs the PM to bring the project to an orderly, controlled halt by initiating the Closing a Project (CP) process.

---

4. Managing a Stage Boundary vs. Closing a Project (CP): The Final Stage Rule

A critical, heavily-tested distinction on the PRINCE2 Practitioner exam is the Final Stage Rule:

[!CRITICAL EXAM RULE] The Final Stage Exclusion: The process Managing a Stage Boundary (SB) is executed near the end of every management stage EXCEPT the final management stage. In the final stage of a project, SB is completely bypassed; instead, the Project Manager initiates the Closing a Project (CP) process.

                   INTERMEDIATE STAGES VS. FINAL STAGE LIFECYCLE

   INTERMEDIATE STAGE:                                FINAL STAGE:

   ┌──────────────────────────────┐                   ┌──────────────────────────────┐
   │ Controlling a Stage (CS)     │                   │ Controlling a Stage (CS)     │
   └──────────────┬───────────────┘                   └──────────────┬───────────────┘
                  │ Near end of stage                                │ Final products finished
                  ▼                                                  ▼
   ┌──────────────────────────────┐                   ┌──────────────────────────────┐
   │ Managing a Stage Boundary    │                   │ Closing a Project (CP)       │
   │ (SB)                         │                   │ • Handover & operational sign│
   │ • Produce NEXT Stage Plan    │                   │ • End Project Report         │
   │ • Update Project Plan/BC     │                   │ • Post-project benefits plan │
   └──────────────┬───────────────┘                   └──────────────┬───────────────┘
                  │                                                  │
                  ▼                                                  ▼
   ┌──────────────────────────────┐                   ┌──────────────────────────────┐
   │ Directing a Project (DP):    │                   │ Directing a Project (DP):    │
   │ Authorize Next Stage         │                   │ Authorize Project Closure    │
   └──────────────────────────────┘                   └──────────────────────────────┘

Why SB is Bypassed in the Final Stage:

1. No Next Stage to Plan: The core operational activity of SB is creating the next Stage Plan. In the final stage, there is no subsequent delivery stage.
2. Handover & Operational Acceptance: The final stage requires unique close-out mechanisms—transferring deliverables to operational custodians, securing final customer acceptance, and archiving project records—which are governed exclusively by Closing a Project (CP).
3. Decommissioning vs. Re-baselining: At intermediate boundaries, baselines are updated for further work; at closure, baselines are locked and final variance reports (End Project Report) are generated.

Comparative Matrix: Managing a Stage Boundary (SB) vs. Closing a Project (CP)

---

5. Practical Scenario Evaluations

Scenario A: The "Silent Rollover" Governance Failure

On a major civil infrastructure project, Stage 2 (environmental clearance and site excavation) finishes on schedule. The Project Manager assumes that because work is progressing well and within budget, scheduling a formal Project Board meeting will only cause administrative delay. The PM informally instructs the civil engineering contractors to begin Stage 3 (foundation piling) and sends a brief email to the Project Executive stating: 'Stage 2 is complete; we have commenced Stage 3.'

Practitioner Evaluation:

• Governance Flaw: Catastrophic breach of the Manage by Stages principle. A Project Manager has zero authority to transition a project into a new stage without explicit Project Board authorization.
• Consequences: The contractor is executing unauthorized work without approved stage tolerances, without an authorized Stage Plan, and without formal financial commitment. If an underground water main is ruptured during unauthorized piling, the PM and contractor bear severe liability, and the Project Board cannot be held accountable for uncommitted capital.
• Correct PRINCE2 Action: The PM must execute Managing a Stage Boundary near the end of Stage 2. The PM must prepare the Stage 3 Plan, update the Project Plan and Business Case, compile the End Stage Report, and submit the package to the Project Board under Directing a Project. Only after the Board formally signs off 'Authorize a Stage or Exception Plan' can Stage 3 work commence.

Scenario B: The Escalating Cost Tolerance and Business Case Erosion

During Stage 3 of a commercial aircraft components manufacturing project, high raw material inflation causes the cost of Stage 3 to exceed its budget by 10% (within the stage cost tolerance of ±12%). However, during SB, the PM calculates that raw material prices will remain elevated, increasing the forecasted cost of Stages 4 and 5 by 35%. This future cost spike reduces the project's projected 5-year return on investment (ROI) from a positive $4M to a net loss of $1.5M. The PM submits the Stage 4 Plan to the Project Board but decides not to update the Business Case, arguing that the Business Case should remain fixed until project closure.

Practitioner Evaluation:

• Governance Flaw: Total violation of the Continued Business Justification principle and failure to execute the SB activity Update the Business Case.
• Consequences: The Project Board is misled into approving Stage 4 based on obsolete financial assumptions. The organization will invest millions into delivering a product that destroys enterprise capital.
• Correct PRINCE2 Action: In SB, the PM must update the Project Plan with realistic future cost forecasts and immediately recalculate the Business Case. The PM must present the revised negative ROI in the End Stage Report. When the Project Board convenes, the Project Executive must recognize that business justification has ceased. The Board must decide whether strategic non-financial benefits justify the financial loss; if not, the Board must direct premature closure of the project under Closing a Project.

Scenario C: Attempting Stage Boundary Formalities in the Final Stage

A defense communications project is completing Stage 5, which is the final management stage defined in the Project Plan. The final encrypted radios have passed all user trials. The Project Manager initiates the Managing a Stage Boundary process, drafting an End Stage Report and attempting to create a 'Stage 6 Plan' to cover decommissioning, operational handover, and final contractor payments.

Practitioner Evaluation:

• Governance Flaw: Failure to understand the Final Stage Rule. The PM is executing SB in the final management stage.
• Consequences: Creating a 'Stage 6 Plan' adds an unnecessary, unauthorized management stage. Project close-out activities are not a separate delivery stage; they must be managed within the final stage under the Closing a Project (CP) process.
• Correct PRINCE2 Action: The PM must cease SB activities. Because this is the final stage, the PM must invoke Closing a Project (CP). Handover of the radios to the military unit, customer sign-off, compiling the End Project Report, and drafting the post-project Benefits Management Approach are all conducted under CP, leading to the Project Board authorizing project closure.

---

6. Responsibilities in SB: The RACI Chart and Practice Application

Table 18.2 — RACI for managing a stage boundary

Key: A Accountable · R Responsible · C Consulted · I Informed. The business layer does not appear in this table.

Reading the chart

SB is the most uniform RACI chart in the method: project executive Accountable, project manager Responsible, everyone else Consulted, for five of six activities. Only request the next stage differs, where the team manager and project support drop to Informed — they have nothing to contribute to a request that is purely a hand-off to the project board.

The exam point is the uniformity itself. The project manager prepares the entire boundary package — next stage plan, exception plan if one was requested, updated project plan, updated business case, and end stage report — and none of it takes effect until the project board authorizes it in DP. An option in which the project manager starts the next stage on the strength of having finished the stage plan is wrong.

How the practices are applied in SB (table 18.3)

Business case is re-verified and updated, along with the benefits management approach; plans builds the next stage plan or the exception plan using the PRINCE2 planning technique and creates the next stage's product descriptions; quality confirms via the quality register that the stage's quality activities passed; risk and issues review the registers and reassess aggregated exposure; progress produces the end stage report against the seven performance targets and sets the recommended tolerances for the next stage; organizing confirms whether the project management team needs to change for the coming stage.

---

7. Practitioner Exam Pitfalls & Governance Traps

• Trap 1: Executing SB in the Final Management Stage: Never select an answer suggesting the PM runs Managing a Stage Boundary in the final stage. The final stage transitions exclusively into Closing a Project (CP).
• Trap 2: Producing the Next Stage Plan After the Current Stage Ends: SB activities must occur near the end of the current stage, not after it. Waiting until the stage finishes forces the delivery team into an unauthorized hiatus or unapproved delivery.
• Trap 3: Believing the Project Manager Authorizes the Next Stage: The PM drafts the Stage Plan and compiles the boundary package, but only the Project Board can authorize the next stage under Directing a Project.
• Trap 4: Treating the End Stage Report as a Simple Milestone Checklist: The End Stage Report must systematically evaluate performance across all seven project performance targets (Cost, Time, Quality, Scope, Benefits, Risk, and Sustainability), review the product register and quality register, and document captured lessons.
• Trap 5: Forgetting to Update the Overall Project Plan at Stage Boundaries: An exam scenario where the PM produces a brilliant next Stage Plan but leaves the overall Project Plan untouched is a classic governance failure. The Project Plan must be updated with actuals from the finished stage and revised forecasts for all remaining stages.