# Highlight Report: [Project name], Stage [N], period ending YYYY-MM-DD

> A highlight report is the regular, short progress report that the
> project manager sends to the project board (or steering group) during a
> stage. It compares progress with the approved stage plan and with the
> tolerances the board delegated, so the board can stay informed without
> meeting, and it flags early anything that may need the board's
> attention. The structure is aligned with the highlight report
> management product described in PRINCE2 7 (PeopleCert, 2023) and works
> for any stage-gated project. Replace every `[bracketed]` value and
> every row marked *Example*.

<!--
Guidance: How to use this template
- Send it on the cadence the board set at stage start (weekly,
  fortnightly or monthly). Keep it to two pages: the board reads many of
  these.
- Report against the approved stage plan and the stage tolerances in
  section 3, not against the original wish list. If the forecast for any
  tolerance shows it will be exceeded, stop: write an exception report
  (project/exception-report) instead of a highlight report with a red
  line in it.
- Base the content on the checkpoint reports from team managers and on
  the risk and issue registers (project/raid-log); do not re-collect
  status by email.
- Write in plain words. Every Amber or Red item needs a cause, an action,
  an owner and a date.
- Common pitfall: a report that lists activity ("held 14 meetings")
  instead of products completed and forecast against tolerance.
-->

## Document control

<!-- Guidance: One report per period. Number reports in sequence so the board can see if one is missing. -->

| Field | Value |
|---|---|
| Document ID | [HR-PROJ-NNN] |
| Project | [Project name] ([project code]) |
| Stage | [Stage number and name] |
| Reporting period | YYYY-MM-DD to YYYY-MM-DD |
| Report number | [N] |
| Version | [1.0] |
| Status | [Draft / Issued] |
| Author | [@project-manager] |
| Distribution | [Project board members, project assurance, project support] |
| Classification | [Internal] |
| Last updated | YYYY-MM-DD |

### Approvals

A highlight report is issued for information; it is not approved. Record
who reviewed it before issue.

| Role | Name | Date |
|---|---|---|
| Project manager (author) | [@project-manager] | YYYY-MM-DD |
| Project assurance (review) | [@assurance] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@author] | Draft from checkpoint reports |
| 1.0 | YYYY-MM-DD | [@author] | Issued to the board |

The worked example is the **Tenant Services Portal** project of
**Brackwell Vale Housing Trust**, a fictional housing association
replacing its tenant self-service website. Stage 3, Build and migrate,
runs 16 weeks from 2027-02-01 to 2027-05-21 with a budget of
520,000 EUR. This is highlight report 4, for week 8.

## 1. Summary

<!-- Guidance: Three to five sentences: overall status, what changed since the last report, the forecast against stage tolerances and anything the board should note or decide. -->

| Item | Value |
|---|---|
| Overall status | [Green / Amber / Red] (previous: [Green / Amber / Red]) |
| Forecast stage end date | YYYY-MM-DD (plan: YYYY-MM-DD) |
| Forecast stage cost | [Amount] (budget: [Amount]) |
| Within stage tolerances? | [Yes / At risk / No: exception report follows] |
| Board action needed | [None / Note / Decision, see section 7] |

*Example:* Overall status Amber (previous Green). Portal build is on plan
and 5 of 9 stage products are complete. Legacy data profiling in work
package WP-07 found more poor-quality tenancy records than the sample
suggested, so forecast stage cost has risen to 548,000 EUR (+28,000 EUR,
+5.4%) and forecast stage end to 2027-05-28 (+1 week). Both are inside
the stage tolerances of +/-8% cost and +/-2 weeks time. The board is
asked to note the data quality risk RSK-014.

## 2. Products completed and in progress

<!-- Guidance: Report products (outputs), not activities. Use the product names from the stage plan so progress can be traced. Include products that were due but not completed and say why. -->

### 2.1 Completed this period

| Product ID | Product | Quality check | Approved by | Date |
|---|---|---|---|---|
| [PRD-NN] | [Product] | [Review, test, inspection] | [@approver] | YYYY-MM-DD |
| PRD-31 *(Example)* | Tenant login with multi-factor option | System test passed, 0 open severity 1 or 2 defects | [@product-owner] | 2027-03-24 |
| PRD-32 *(Example)* | Repairs request form | Accessibility review against WCAG 2.2 AA | [@accessibility-lead] | 2027-03-25 |

### 2.2 Planned for the next period

| Product ID | Product | Due | Owner | Confidence |
|---|---|---|---|---|
| [PRD-NN] | [Product] | YYYY-MM-DD | [@owner] | [High / Medium / Low] |
| PRD-33 *(Example)* | Rent statement and payment page | 2027-04-09 | [@team-manager-web] | High |
| PRD-36 *(Example)* | Cleansed tenancy records, batch 1 | 2027-04-09 | [@team-manager-data] | Low |

### 2.3 Behind plan

| Product ID | Product | Was due | Now forecast | Reason | Recovery action |
|---|---|---|---|---|---|
| [PRD-NN] | [Product] | YYYY-MM-DD | YYYY-MM-DD | [Reason] | [Action] |
| PRD-35 *(Example)* | Data profiling report | 2027-03-19 | 2027-03-26 (done) | Extra profiling of 3 legacy tables | None needed; see RSK-014 for impact |

## 3. Performance against stage tolerances

<!-- Guidance: One row for each tolerance area the board set for the stage. "Forecast" means at stage end, not to date. Use the same units as the stage plan. Add a sustainability line if the board set a target for it. -->

| Area | Plan or target | Tolerance | Actual to date | Forecast at stage end | Status |
|---|---|---|---|---|---|
| Time | [End date] | [+/- weeks] | [Weeks used] | [Date] | [G / A / R] |
| Cost | [Budget] | [+/- %] | [Spend] | [Amount] | [G / A / R] |
| Scope | [Products in plan] | [Must / should split] | [Products done] | [Products forecast] | [G / A / R] |
| Quality | [Quality criteria] | [Allowed range] | [Result] | [Forecast] | [G / A / R] |
| Risk | [Risk appetite or score limit] | [Limit] | [Highest score] | [Forecast] | [G / A / R] |
| Benefits | [Benefit forecast] | [Range] | [n/a during build] | [Forecast] | [G / A / R] |
| Sustainability | [Target, if set] | [Range] | [Value] | [Forecast] | [G / A / R] |
| Time *(Example)* | End 2027-05-21 | +/- 2 weeks | 8 of 16 weeks | 2027-05-28 (+1 week) | A |
| Cost *(Example)* | 520,000 EUR | +/- 8% (41,600 EUR) | 262,000 EUR (plan to date 255,000 EUR, +2.7%) | 548,000 EUR (+5.4%) | A |
| Scope *(Example)* | 9 products | All must-have | 5 complete | 9 | G |
| Quality *(Example)* | 0 open severity 1 defects at stage end | 0 | 0 | 0 | G |

Explain every Amber and Red line in one or two sentences.

*Example:* Cost and time are Amber because the extra data cleansing in
WP-07 adds an estimated 28,000 EUR and one week. Headroom left in the
cost tolerance is 13,600 EUR (41,600 minus 28,000). If cleansing effort
rises by more than about half again, the forecast will breach tolerance
and the project manager will raise an exception report.

## 4. Risks and issues

<!-- Guidance: Only new, changed or escalated items. Link to the full register rather than copying it. Give the ID, the change and the action. -->

| ID | Type | Description | Change this period | Action and owner | Due |
|---|---|---|---|---|---|
| [RSK-NNN / ISS-NNN] | [Risk / Issue] | [Description] | [New / Score up / Score down / Closed] | [Action, @owner] | YYYY-MM-DD |
| RSK-014 *(Example)* | Risk | Legacy tenancy records need more cleansing than estimated, raising cost and delaying migration | New, probability 4 x impact 4 = 16 | Daily cleansing burn-down, @team-manager-data | 2027-04-02 |
| ISS-009 *(Example)* | Issue | Payment provider sandbox down for 3 days | Closed | Testing caught up in week 8, @team-manager-web | Done |

Full registers: [link to project/raid-log or tool].

## 5. Changes and issues handled within tolerance

<!-- Guidance: Requests for change and off-specifications that the project manager resolved under delegated authority. The board needs to see them even though no decision is needed. -->

| ID | Change | Decided by | Effect on cost and time | Date |
|---|---|---|---|---|
| [CR-NNN] | [Change] | [@project-manager / change authority] | [Effect] | YYYY-MM-DD |
| CR-021 *(Example)* | Add Irish-language labels to login pages | Change authority | +2,400 EUR, no time effect, from change budget | 2027-03-22 |

## 6. Lessons and good news

<!-- Guidance: Short. Anything learned this period that the next stage or other projects should know. Feed the lessons log. -->

- [Lesson or achievement]
- *Example:* Sampling 2% of legacy records under-estimated data quality
  problems. Profile the full data set before estimating migration effort.
- *Example:* The repairs form passed its accessibility review first time
  because the design system components were used unchanged.

## 7. Requests to the board

<!-- Guidance: Usually "none". A highlight report may ask the board to note something or to give advice. Decisions on a forecast breach of tolerance go in an exception report, not here. -->

| # | Request | Type | Needed by |
|---|---|---|---|
| [1] | [Request] | [Note / Advice] | YYYY-MM-DD |
| 1 *(Example)* | Note RSK-014 and the reduced cost tolerance headroom | Note | Next board review |

## 8. Next period

<!-- Guidance: The key products, milestones and decisions coming up, so the board knows what to expect in the next report. -->

| Item | Date | Owner |
|---|---|---|
| [Product or milestone] | YYYY-MM-DD | [@owner] |
| *Example:* Rent statement and payment page complete | 2027-04-09 | [@team-manager-web] |
| *Example:* Cleansing burn-down review with WP-07 team | 2027-04-02 | [@project-manager] |

## 9. Related templates

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

- [Exception report](./exception-report.md), when a forecast breaches tolerance
- [End stage report](./end-stage-report.md), at the stage boundary
- [Work package](./work-package.md), the source of checkpoint reporting
- [RAID log](./raid-log.md) for risks, assumptions, issues and dependencies
- [Steering committee report](./steering-committee-report.md) for a meeting-based governance model
- [Status report](../business/status-report.md) for a lighter, non-staged format

## Glossary

- **Project board:** the group that directs the project, usually an executive (sponsor), a senior user and a senior supplier.
- **Stage:** a section of the project that the board authorises one at a time.
- **Tolerance:** the permitted deviation above or below a plan target (time, cost, scope, quality, risk, benefits, sustainability) before the next level up must be told.
- **Checkpoint report:** a team manager's progress report on a work package to the project manager.
- **Exception:** a situation where a tolerance is forecast to be exceeded.
- **RAG:** Red, Amber, Green status rating. Define what each colour means in the project management approach.

## Standard and licence note

Structure aligned with the highlight 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 and the fictional Brackwell Vale
example are original. The sustainability tolerance line reflects
PeopleCert's public announcement that PRINCE2 7 integrates
sustainability into project performance. 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 project management approach before use.
Template licence: MIT.