PRINCE2 Managing a Stage Boundary

Overview

Draft Managing a Stage Boundary (SB) documents aligned with PRINCE2. Covers End Stage Reports, next Stage Plans, updated Business Case, updated Project Plan, Exception Plans, and Lessons Reports.

Getting Started

Upload the Stage Plan, actuals data, issue and risk registers, and any lessons captured during the stage to the workspace and activate the PRINCE2 Managing a Stage Boundary skill. The agent will help you draft End Stage Reports, plan the next stage, and update the Business Case.

Example Conversation

Below is an example of a typical session preparing end-of-stage documentation for a supply chain digitalization project. The agent drafts the End Stage Report and next Stage Plan.

You: We’re at the end of Stage 2 (Vendor Integration) of our supply chain digitalization project. Stage 2 was planned for 12 weeks and EUR 180K. It actually took 14 weeks and cost EUR 195K — the 2-week overrun was caused by a vendor API change mid-stage that required rework. All 5 planned products were delivered and accepted. I need the End Stage Report and the next Stage Plan for Board review. The Stage Plan and registers are in plans/stage2_plan.md and registers/.

Agent: I’ve reviewed the Stage Plan and registers. Let me clarify for the next Stage Plan:

1. What is Stage 3’s scope — warehouse automation rollout? How many warehouses and what’s the sequence?
2. Has the vendor API issue been resolved, or is there residual risk for Stage 3?
3. What is the proposed Stage 3 budget and duration?

You: Stage 3 is warehouse automation rollout — 3 warehouses in sequence (Hamburg, Leipzig, Stuttgart), each taking about 4 weeks. Total 14 weeks, EUR 220K budget. The vendor API issue is resolved — they’ve committed to a frozen API specification for 6 months with a contractual SLA. One lesson: we need API versioning in all future integrations. We’re requesting +/- 3 week schedule tolerance and +/- EUR 25K cost tolerance.

Agent: I’ve drafted both documents:

End Stage Report (reports/end_stage_2.md):

• Schedule: 14 weeks vs. 12 planned (+2 weeks, 17% overrun) — outside stage tolerance of +/- 1 week but within project tolerance. Cause: vendor API v2.3 → v2.4 migration in Week 7.
• Cost: EUR 195K vs. EUR 180K (+EUR 15K, 8% overrun) — within stage tolerance of +/- EUR 20K. Additional cost: 120 hours rework.
• Products: 5 of 5 delivered and accepted. All quality reviews passed.
• Benefits: Real-time inventory visibility now operational for 2 pilot suppliers — 30% reduction in stock query response time (ahead of target).
• Lessons: (1) Mandate API version pinning in all vendor contracts. (2) Include API change risk buffer in future integration stages. (3) Pair-programming during rework was effective — reduced rework duration by estimated 3 days.

Next Stage Plan (plans/stage3_plan.md):

• 14 weeks, EUR 220K, 3 sequential warehouse rollouts
• Product breakdown: 9 products (3 per warehouse: configuration, training, go-live verification)
• Risk: warehouse staff resistance to new system — mitigation: dedicated change champion per site
• Tolerances requested: +/- 3 weeks, +/- EUR 25K

Document Excerpt

Below is a representative excerpt from an End Stage Report prepared with the skill.

End Stage Report — Stage 2: Vendor Integration (Excerpt)

Project: Supply Chain Digitalization Stage: Stage 2 — Vendor Integration Duration: Weeks 13–26 (planned) / Weeks 13–28 (actual)

2. Performance Against Plan

Schedule Variance Explanation: The vendor (LogiConnect GmbH) released API v2.4 in Week 7, deprecating 3 endpoints used in our integration layer. Rework required 120 person-hours over 2 weeks. The overrun exceeded stage tolerance (+/- 1 week) but remained within project tolerance (+/- 6 weeks). An Exception Report was not required because the Executive provided ad hoc direction to continue (ref: ADH-003, Week 8).

3. Products Delivered

7. Lessons Identified

This excerpt is illustrative. Final content must reflect the specific project’s data and stage performance.