# End Stage Report: [Project name], Stage [N] [stage name]

> An end stage report closes one management stage. The project manager
> tells the project board what the stage delivered against its plan,
> how the project stands as a whole, whether the business case is still
> viable, and asks for authority to start the next stage on the basis of
> a new stage plan. It is the main input to the board's stage-gate
> decision. The structure is aligned with the end stage report management
> product and the stage boundary process described in PRINCE2 7
> (PeopleCert, 2023), and it fits any stage-gated or phase-gated project.
> Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Write it near the end of the stage, together with the next stage plan
  and the updated business case and project plan. The board decides on
  all of them at once.
- Compare against the stage plan the board approved, or the exception
  plan if one replaced it. Show both if an exception happened.
- Be candid about what was not delivered and why: the board needs it to
  set tolerances for the next stage.
- For the last stage, use the project closure report
  (project/project-closure-report) instead.
- Common pitfall: asking for the next stage without restating whether
  the project is still worth doing. The business case review in section
  4 is the reason the gate exists.
-->

## Document control

<!-- Guidance: Name the stage and the plan version you report against. -->

| Field | Value |
|---|---|
| Document ID | [ESR-PROJ-NN] |
| Project | [Project name] ([project code]) |
| Stage closing | [Stage number and name] |
| Plan reported against | [Stage plan v1.0 / Exception plan v1.0] |
| Next stage requested | [Stage number and name] |
| Version | [1.0] |
| Status | [Draft / Submitted / Approved] |
| Author | [@project-manager] |
| Board review date | YYYY-MM-DD |
| Classification | [Internal] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Executive (sponsor) | [@executive] | [Authorise next stage / Do not authorise / Close project] | YYYY-MM-DD |
| Senior user | [@senior-user] | [Agree / Disagree] | YYYY-MM-DD |
| Senior supplier | [@senior-supplier] | [Agree / Disagree] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@author] | Draft |
| 1.0 | YYYY-MM-DD | [@author] | Submitted with stage 4 plan |

The worked example continues the fictional **Brackwell Vale Housing
Trust** Tenant Services Portal. Stage 3, Build and migrate, was
re-planned after exception report ER-TSP-001 (option B approved): budget
534,000 EUR, end 2027-05-28. The project budget is 1,090,000 EUR for
four stages plus a 90,000 EUR risk budget, 1,180,000 EUR in total.

## 1. Stage summary

<!-- Guidance: Three to five sentences: what the stage set out to do, what it delivered, the final position against tolerances, and what the board is asked to decide. -->

[Summary]

*Example:* Stage 3 built the new portal and migrated current tenancy
data. All 9 planned products are complete, with historic repairs before
2022 left read-only in the legacy system as approved in the exception.
The stage ended on 2027-05-28 as re-planned, at 531,500 EUR, 2,500 EUR
(0.5%) below the exception plan budget of 534,000 EUR. The business case
remains viable. The board is asked to authorise stage 4, Rollout, at
210,000 EUR over 10 weeks.

## 2. Performance against the stage plan

<!-- Guidance: Show the original plan, the plan in force (after any exception) and the actual. Comment on any variance outside the board's comfort even if it stayed within tolerance. -->

| Area | Original stage plan | Plan in force | Actual | Variance vs plan in force |
|---|---|---|---|---|
| Time | [Date] | [Date] | [Date] | [Weeks] |
| Cost | [Amount] | [Amount] | [Amount] | [Amount, %] |
| Scope | [Products] | [Products] | [Products] | [Difference] |
| Quality | [Criteria] | [Criteria] | [Result] | [Difference] |
| *Example:* Time | 2027-05-21 | 2027-05-28 | 2027-05-28 | 0 |
| *Example:* Cost | 520,000 EUR | 534,000 EUR | 531,500 EUR | -2,500 EUR (-0.5%) |
| *Example:* Scope | 9 products, full history | 9 products, current tenancies only | 9 products | None |
| *Example:* Quality | 0 open severity 1 defects | Same | 0 open severity 1, 4 severity 3 | Accepted by senior user |

Against the original budget, the stage cost 11,500 EUR (2.2%) more,
funded by 14,000 EUR drawn from the risk budget.

## 3. Products delivered

<!-- Guidance: List each product with its quality check and acceptance. Name products handed over early (before project closure) and anything with concessions or off-specifications. -->

| Product ID | Product | Status | Quality evidence | Accepted by |
|---|---|---|---|---|
| [PRD-NN] | [Product] | [Approved / Approved with concession / Not delivered] | [Evidence] | [@approver] |
| PRD-31 *(Example)* | Tenant login with multi-factor option | Approved | System and security test reports | [@product-owner] |
| PRD-36 *(Example)* | Cleansed tenancy records | Approved | Reconciliation: 18,500 of 18,500 current tenancies matched | [@data-owner] |
| PRD-39 *(Example)* | Portal accessibility statement | Approved with concession | 4 minor issues to fix in stage 4 | [@senior-user] |

Off-specifications and concessions: [List, with IDs and who accepted them.]

## 4. Business case review

<!-- Guidance: Restate the costs, timescale, benefits and main risks as now forecast and say whether the project is still desirable, viable and achievable. Link the updated business case. -->

| Item | At initiation | Now forecast | Comment |
|---|---|---|---|
| Total project cost | [Amount] | [Amount] | [Comment] |
| Go-live | [Date] | [Date] | [Comment] |
| Annual net benefit | [Amount] | [Amount] | [Comment] |
| Payback | [Years] | [Years] | [Comment] |
| *Example:* Project cost excluding risk budget | 1,090,000 EUR | 1,096,000 EUR | Actuals 886,000 EUR for stages 1 to 3 plus stage 4 plan 210,000 EUR |
| *Example:* Annual net benefit | 255,500 EUR | 249,500 EUR | Read-only legacy licence kept 2 years at 6,000 EUR a year |

**Conclusion:** [Still justified / Justified with changes / No longer justified]

*Example:* Still justified. Actuals to date are 58,000 EUR (stage 1),
296,500 EUR (stage 2) and 531,500 EUR (stage 3), 886,000 EUR in total.
The risk budget has 76,000 EUR left.

## 5. Benefits achieved so far

<!-- Guidance: Most benefits come after the project, but record any measured early. Point to the benefits management approach for the rest. -->

| Benefit | Measure | Baseline | Achieved | Next review |
|---|---|---|---|---|
| [Benefit] | [Measure] | [Value] | [Value] | YYYY-MM-DD |
| *Example:* Calls moved to self-service | Share of repairs reported online | 9% | Not yet live | 3 months after go-live |

See [Benefits realization plan](./benefits-realization-plan.md).

## 6. Team performance and lessons

<!-- Guidance: What worked, what did not and what the next stage should do differently. Credit people by role. Copy each lesson to the lessons log. -->

| ID | Lesson | Type | Action for the next stage |
|---|---|---|---|
| [LL-NN] | [Lesson] | [Keep / Change] | [Action] |
| LL-07 *(Example)* | Sampling under-estimated data quality problems | Change | Profile full data before any future migration estimate |
| LL-08 *(Example)* | Daily burn-down of cleansing gave early warning | Keep | Use the same burn-down for rollout support tickets |

## 7. Issues and risks carried forward

<!-- Guidance: Open issues and risks that the next stage inherits, with owners. Do not hide them in the register. -->

| ID | Description | Score or priority | Owner | Plan in next stage |
|---|---|---|---|---|
| [ID] | [Description] | [Score] | [@owner] | [Plan] |
| RSK-019 *(Example)* | Tenants without email cannot self-register | 3 x 4 = 12 | [@senior-user] | Assisted registration at local offices |

## 8. Next stage request

<!-- Guidance: Summarise the next stage plan: objectives, products, dates, budget and proposed tolerances. Attach or link the full plan. Also say whether the project plan or approach documents changed. -->

| Item | Value |
|---|---|
| Next stage | [Number and name] |
| Products | [Main products] |
| Start and end | YYYY-MM-DD to YYYY-MM-DD |
| Budget | [Amount] |
| Proposed tolerances | [Time, cost, scope, quality, risk, sustainability] |
| Plan document | [Link] |
| *Example:* Next stage | 4, Rollout |
| *Example:* Start and end | 2027-05-31 to 2027-08-06 (10 weeks) |
| *Example:* Budget | 210,000 EUR |
| *Example:* Proposed tolerances | Cost +/-5% (10,500 EUR), time +/-1 week |

```mermaid
flowchart LR
    A["Stage 3 closes"] --> B["End stage report"]
    A --> C["Next stage plan"]
    A --> D["Updated business case and project plan"]
    B --> E{"Board stage-gate decision"}
    C --> E
    D --> E
    E -- Authorise --> F["Stage 4 starts"]
    E -- "Do not authorise" --> G["Premature closure"]
```

## 9. Related templates

<!-- Guidance: Link the documents submitted with this report. -->

- [Highlight report](./highlight-report.md) and [Exception report](./exception-report.md) for the stage history
- [Project closure report](./project-closure-report.md) for the final stage
- [Lessons learned](./lessons-learned.md)
- [Business case](../business/business-case.md)
- [Project schedule](./project-schedule.md) for the next stage plan

## Glossary

- **Stage boundary:** the point between two stages where the board decides whether to continue.
- **Exception plan:** a plan that replaces a stage plan after the board accepts an option in an exception report.
- **Concession:** acceptance of a product that does not fully meet its specification.
- **Off-specification:** something that should be provided but is not, or that does not meet its specification.
- **Risk budget:** money set aside for risk responses, controlled by the board.

## Standard and licence note

Structure aligned with the end stage report management product and the
"manage by stages" principle of PRINCE2 7 (*Managing Successful Projects
with PRINCE2*, 7th edition, PeopleCert, 2023), including the stage
boundary process. PRINCE2 is cited by name only: no text, tables or
figures from the publication are reproduced, and the headings, wording
and the fictional Brackwell Vale example are original. Official text:
PeopleCert, purchase or licensed access:
https://www.peoplecert.org/prince2. PRINCE2 is a registered trademark of
PeopleCert. Check the current edition and your organisation's stage-gate
rules before use. Template licence: MIT.