# Exception Report: [Project name], [Stage N or project], YYYY-MM-DD

> An exception report tells the project board (or the next level of
> authority) that a tolerance is forecast to be exceeded, explains why,
> sets out the options with their effect on the plan and the business
> case, and recommends one. The board then decides. It is the core of
> "management by exception": the project manager runs the stage inside
> delegated limits and escalates only when those limits will be broken.
> The structure is aligned with the exception report management product
> described in PRINCE2 7 (PeopleCert, 2023) and works for any project
> with delegated tolerances. Replace every `[bracketed]` value and every
> row marked *Example*.

<!--
Guidance: How to use this template
- Raise it as soon as the forecast shows a breach, not when the breach
  happens. A forecast is enough: the board wants time to choose.
- Send it to whoever set the tolerance. A stage tolerance breach goes to
  the project board; a project tolerance breach goes from the board to
  corporate, programme or portfolio management.
- Give at least two real options, including "do nothing" when it is
  viable, each with cost, time, scope, quality, risk and benefit effects.
- Check every option against the next tolerance level up. An option
  that also breaches project tolerance cannot be approved by the board
  alone.
- If the board accepts the recommendation, the usual next step is an
  exception plan that replaces the current stage plan.
- Common pitfall: a report that describes the problem well but gives
  only one option, or options without numbers.
-->

## Document control

<!-- Guidance: Mark the report urgent if a decision is needed before the next scheduled board review. -->

| Field | Value |
|---|---|
| Document ID | [ER-PROJ-NNN] |
| Project | [Project name] ([project code]) |
| Level of exception | [Work package / Stage / Project] |
| Tolerance(s) affected | [Time / Cost / Scope / Quality / Risk / Benefits / Sustainability] |
| Version | [1.0] |
| Status | [Draft / Submitted / Decided] |
| Author | [@project-manager] |
| Submitted to | [Project board / corporate, programme or portfolio management] |
| Decision needed by | YYYY-MM-DD |
| Linked records | [Issue ID, risk ID, highlight report number] |
| Classification | [Internal] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Project manager (author) | [@project-manager] | Submitted | YYYY-MM-DD |
| Executive (sponsor) | [@executive] | [Option chosen / Rejected / More information] | 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, options costed |
| 1.0 | YYYY-MM-DD | [@author] | Submitted to the board |

The worked example continues the fictional **Brackwell Vale Housing
Trust** Tenant Services Portal (see project/highlight-report). Stage 3,
Build and migrate, has a budget of 520,000 EUR with +/-8% cost tolerance
(41,600 EUR) and a planned end of 2027-05-21 with +/-2 weeks time
tolerance. Project tolerances are +/-5% cost on 1,180,000 EUR
(59,000 EUR) and +4 weeks time.

## 1. Exception title and summary

<!-- Guidance: One sentence naming the tolerance and the size of the forecast breach, then three sentences on cause, options and recommendation. -->

**Title:** [Short title, for example "Stage 3 cost and time forecast to exceed tolerance"]

[Summary]

*Example:* Stage 3 cost is forecast at 571,000 EUR, 51,000 EUR (+9.8%)
over budget against a tolerance of +/-8%, and the stage end is forecast
at 2027-06-11, 3 weeks late against a tolerance of +/-2 weeks. The cause
is the volume of poor-quality legacy tenancy records found in work
package WP-07. Three options are assessed. The project manager
recommends option B: migrate current tenancies only and keep the
historic repairs archive read-only in the old system, which returns the
stage to within tolerance.

## 2. Cause of the exception

<!-- Guidance: What happened, when it was found and why the plan did not foresee it. Facts and evidence, not blame. -->

| Item | Detail |
|---|---|
| Event or trend | [What happened] |
| First detected | YYYY-MM-DD, by [@name or report] |
| Evidence | [Data, checkpoint reports, test results] |
| Why the plan missed it | [Estimating assumption that proved wrong] |
| Related records | [Risk or issue IDs] |

*Example:* Full profiling of the legacy housing system (product PRD-35)
showed that 38% more tenancy and repairs records need manual cleansing
than the 2% sample used for the WP-07 estimate. Risk RSK-014 was raised
in highlight report 4. By week 11 the cleansing burn-down showed the
team clearing records at the planned rate against a much larger
backlog, and the forecast crossed both tolerances.

## 3. Consequences of the deviation

<!-- Guidance: What happens to the stage, the project and the business case if nothing is done. Separate the effect on this stage from the effect on the whole project. -->

| Area | Stage effect | Project effect |
|---|---|---|
| Time | [Effect] | [Effect] |
| Cost | [Effect] | [Effect] |
| Scope | [Effect] | [Effect] |
| Quality | [Effect] | [Effect] |
| Risk | [Effect] | [Effect] |
| Benefits | [Effect] | [Effect] |
| *Example:* Time | +3 weeks, end 2027-06-11 | Go-live slips 3 weeks, within the +4 week project tolerance |
| *Example:* Cost | +51,000 EUR (+9.8%) | Uses 51,000 of the 59,000 EUR project cost tolerance |
| *Example:* Benefits | None | Call reduction benefit starts 3 weeks later |

## 4. Options

<!-- Guidance: Each option with its full effect. Include doing nothing if it is a real option. State clearly which tolerances each option keeps or breaks, at stage and project level. -->

| Option | Description | Stage cost | Change vs budget | Stage end | Scope effect | Within stage tolerance? | Within project tolerance? |
|---|---|---|---|---|---|---|---|
| [A] | [Option] | [Amount] | [Amount, %] | YYYY-MM-DD | [Effect] | [Yes / No] | [Yes / No] |
| A *(Example)* | Continue as planned, add two cleansing contractors | 571,000 EUR | +51,000 EUR (+9.8%) | 2027-06-11 | None | No | Yes, but leaves 8,000 EUR cost headroom |
| B *(Example)* | Migrate current tenancies only. Keep historic repairs (before 2022) read-only in the legacy system | 534,000 EUR | +14,000 EUR (+2.7%) | 2027-05-28 | Historic repairs not in the new portal | Yes | Yes |
| C *(Example)* | Pause migration, re-profile, re-plan the stage | 558,000 EUR | +38,000 EUR (+7.3%) | 2027-07-02 | None | No (time +6 weeks) | No (time beyond +4 weeks) |

### 4.1 Effect on risks and the business case

<!-- Guidance: For each option, the new or changed risks and the effect on the benefits and the business case. Use the project's own business case figures. -->

| Option | New or changed risks | Business case effect |
|---|---|---|
| [A] | [Risks] | [Still viable? Payback change] |
| A *(Example)* | Contractor onboarding delay; little cost headroom for stage 4 | Viable, payback a few weeks later |
| B *(Example)* | Staff must use two systems for old repairs history; legacy licence kept read-only for 2 years at 6,000 EUR a year | Viable; part of the legacy licence saving is delayed |
| C *(Example)* | Supplier team released and hard to recall | Needs corporate approval; benefits 6 weeks later |

## 5. Recommendation

<!-- Guidance: Name one option and give the reasons. Say what the board must decide, and what happens next if it agrees. -->

**Recommended option:** [Option and reasons]

**Decision requested:** [Approve option, approve exception plan preparation, change tolerances]

*Example:* Option B. It keeps both stage and project within tolerance,
protects the go-live date for current tenants, and the business case
stays viable. Historic repairs are consulted for fewer than 1 in 50
calls according to the contact centre's sample, which the senior user
should confirm. The board is asked to approve option B and to ask the
project manager to produce an exception plan for stage 3 with a revised
budget of 534,000 EUR and end date 2027-05-28, the 14,000 EUR coming
from the project risk budget.

## 6. Lessons

<!-- Guidance: What could have warned the project earlier. Add the lesson to the lessons log now; do not wait for the stage end. -->

- [Lesson]
- *Example:* Estimate migration effort from full data profiling, not a
  sample, and make profiling a product of the stage before.

## 7. Board decision record

<!-- Guidance: Fill after the board decides, so the report and decision stay together. Record any conditions. -->

| Item | Value |
|---|---|
| Decision | [Option chosen / Rejected / Referred upward / More information needed] |
| Conditions | [Conditions] |
| Next document | [Exception plan / Revised stage plan / Premature closure] |
| Decided by | [@executive], YYYY-MM-DD |

```mermaid
flowchart TD
    A["Forecast shows tolerance breach"] --> B["Project manager writes exception report"]
    B --> C{"Within the board's own tolerance?"}
    C -- Yes --> D{"Board decision"}
    C -- No --> E["Board escalates to corporate, programme or portfolio management"]
    D -- "Approve option" --> F["Exception plan replaces stage plan"]
    D -- "Ask for more information" --> B
    D -- "Close early" --> G["Premature closure"]
    E --> D
```

## 8. Related templates

<!-- Guidance: Link the documents this report draws on and leads to. -->

- [Highlight report](./highlight-report.md), where the risk was first reported
- [Work package](./work-package.md), whose tolerance the team manager escalated
- [End stage report](./end-stage-report.md), which records the exception at the stage boundary
- [Change control](./change-control.md) for changes that cause an exception
- [RAID log](./raid-log.md) and [Decision log](../business/decision-log.md)
- [Business case](../business/business-case.md) to recheck viability

## Glossary

- **Tolerance:** the permitted deviation from a plan target before the next level of authority must be told.
- **Exception:** a forecast that a tolerance will be exceeded.
- **Exception plan:** a plan that replaces the current stage or project plan after the board accepts an option.
- **Project risk budget:** money set aside to fund responses to risks; the board controls how it is used.
- **Premature closure:** stopping the project in a controlled way before its planned end.

## Standard and licence note

Structure aligned with the exception report management product and the
"manage by exception" principle of PRINCE2 7 (*Managing Successful
Projects with PRINCE2*, 7th edition, PeopleCert, 2023). PRINCE2 is cited
by name only: no text, tables or figures from the publication are
reproduced, and the headings, wording, decision flow 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 governance rules before use. Template licence: MIT.