Status Report vs Highlight Report: What's the Difference?
A highlight report is a PRINCE2 artefact: the project manager reports to the project board at a frequency set in the stage plan, against agreed tolerances. A status report is the generic equivalent, sent to whoever asked for it on whatever cadence suits. The contents overlap heavily. What differs is the audience, the formality, and what happens when tolerances are breached.
Side by side
In most organisations the two words describe the same weekly page. The difference only becomes real where PRINCE2 is being followed properly, because there the highlight report has a defined recipient, a defined trigger for escalation and a defined relationship to the stage plan.
| Aspect | Status report | Highlight report |
|---|---|---|
| Origin | General delivery practice, no single definition | PRINCE2 management product |
| Author | Project manager or PMO | Project manager |
| Audience | Whoever asked: team, stakeholders, sponsor, vendor | The project board |
| Cadence | Weekly or fortnightly, set by convention | Frequency agreed in the stage plan |
| Period covered | Since the last report | The reporting period within the current stage |
| Tolerances | Not usually a formal concept | Reports progress against agreed tolerances |
| Escalation | Ad hoc, often inside the report itself | Via a separate exception report when tolerance is forecast to be exceeded |
| Typical contents | RAG, progress, milestones, risks, issues, next period | Products completed, work planned, tolerance status, issues and risks, lessons |
| Format | Whatever the audience will read | Defined in the project's communication management approach |
| Length | One page, ideally | One to two pages |
When you need a status report
You need a status report on any project where more than a handful of people have a stake in the outcome and nobody has time to ask. Its job is to remove the need for individual chasing. If three people email you in a week asking how it is going, the report is either not being sent, not being read, or not answering the question.
A useful one is short and consistent. Same sections in the same order every week, so a reader can find what they came for without reading the rest. Overall status, movement since last time, what completed, what is planned, what needs attention, and anything requiring a decision. The last one is the section most often missing and the one most likely to make the report worth sending.
Consistency of format matters more than richness. A one-page layout that never changes gets read; a report that expands whenever there is bad news teaches people to skim. If you want the sections and the habits that destroy credibility, what should be in a project status report covers both, and the weekly status report in Excel ships with a filled-in example so the shape is visible before you start.
When you need a highlight report
You need a highlight report where PRINCE2 is the method in use, or where the governance model has borrowed its structure. The difference from a generic status report is not cosmetic. A highlight report is addressed to a body with defined decision rights, covers a defined stage, and reports against tolerances that were agreed when the stage was authorised.
That last point changes how it is written. The report is not asking the board to decide anything by default — it is confirming that the project remains within the limits it was given. Decisions escalate through a different route: if the project manager forecasts that time, cost, scope, quality, benefit or risk tolerance will be exceeded, that goes up as an exception report, not as an amber box on the weekly.
Highlight reports also carry things a generic status report often drops: products completed against the stage plan, requests for change and off-specification items, and lessons noted during the period. The vocabulary matters less than the discipline of separating routine reporting from escalation, which is one of the harder habits to establish. Programme governance covers how those reporting lines get designed in the first place.
When you need both
Larger programmes usually run a layered set, and calling them different things is the least confusing option. A weekly status report goes to the delivery community and the wider stakeholder group. A formal report goes to the board at its own cadence, structured for a decision-making forum. A monthly pack goes to the steering committee with financials and portfolio context attached.
The rule that keeps this from becoming a reporting industry is that all of them derive from the same underlying record. One RAID log, one milestone list, one budget position, three views. If the numbers in the weekly and the numbers in the board pack are assembled separately, they will disagree in public eventually. Our programme governance pack is built around that single-source approach; the SteerCo deck handles the committee-facing view.
Where a project has an external supplier, there is usually a fourth report against the contract. Keep it separate. Contractual reporting has different consequences and a different reader, and merging it into the internal status report tends to make both more cautious than they need to be.
The overlap
The overlap is most of the document. Both report progress since the last period. Both list what is planned next. Both summarise risks and issues. Both carry a status indicator of some kind. If you took a good weekly status report and a well-written highlight report from the same project, the factual content would be nearly identical.
The honest position is that the label matters far less than three things: whether the report has a named recipient who is expected to act on it, whether it is consistent enough to be comparable week to week, and whether bad news arrives in it early rather than late. A project running PRINCE2 badly will produce highlight reports that are worse than a competent weekly one-pager. A project with no formal method that reports clearly every Friday will be better governed than one that files the correct artefact reluctantly.
If your organisation uses both terms and nobody can explain the difference, the practical fix is to name each report by its audience rather than its methodology — "board report", "team update", "SteerCo pack" — and define the cadence and contents of each once. The steering committee report guide covers the highest-stakes version of that.
Questions
Is a highlight report just a status report with a different name?
In most organisations, effectively yes. In a project genuinely following PRINCE2, it has a defined audience, a defined period tied to a stage, and a formal relationship to tolerances and exception reporting.
How often should a highlight report be sent?
The frequency is agreed in the stage plan when the board authorises the stage, rather than being fixed by convention. Fortnightly and monthly are both common, depending on stage length and risk.
Does a status report need a RAG rating?
Not necessarily, but it needs some consistent overall indicator. What matters is that the criteria for each colour are written down, otherwise the rating tracks the author's mood rather than the project.
Where do escalations go in PRINCE2?
Into an exception report, raised when a tolerance is forecast to be breached. The highlight report confirms the project is within tolerance; it is not the escalation mechanism itself.
Can one report serve both the team and the board?
It can on a small project. Once the board needs financials and decision requests the team does not need, splitting the views is usually less work than writing one report that satisfies neither.