Reporting that actually gets read

Most project status reports have the same problem: they’re written for the person writing them, not the person reading them.

They document what happened. They list what’s being worked on. They contain extensive budget tables and milestone logs and risk registers that everyone skims past. And then, buried in paragraph seven, there’s the one sentence the sponsor actually needed to know: that the project is three weeks behind and the team needs a decision about scope.

The purpose of a status report isn’t to show how busy the project manager has been. It’s to give the reader the information they need to make decisions, provide support, or escalate appropriately. Everything else is noise.

Why most reports don’t get read

Senior stakeholders are time-poor and attention-limited. If your status report requires fifteen minutes to extract the two things that matter, most readers will spend thirty seconds on it and move on. You’ve done the work and nobody benefited.

The reports that do get read have three things in common: they’re short, they lead with what matters, and they’re honest.

The one-page principle

A weekly project status report should fit on one page. Not because the project isn’t complex, but because the purpose of the report is to surface what requires attention — and anything requiring attention can be summarised in a sentence.

RAG status — used properly

Red, Amber, Green is the most universally used and most frequently misused tool in project reporting. A few principles that make it work:

RAG should reflect trajectory, not just current state. A project that is currently on schedule but has three unresolved risks that will cause slippage next week should be Amber, not Green. RAG is about where the project is heading, not just where it is today.

Amber is not a comfort zone. In many organisations, projects sit on Amber for months because it’s less alarming than Red but more defensible than Green. Amber should mean “attention required within two weeks or this becomes Red.” If it doesn’t, the rating is meaningless.

Green should mean Green. Some organisations have a culture where everything is Green until it’s catastrophically Red. This is the most dangerous reporting pattern because it means governance bodies never have early warning of problems. If you’re a PMO manager trying to change this culture, start by making it safe to report Amber. Praise the first person who turns a project Amber and uses it to get help.

Separate RAG by dimension. Overall RAG often conceals what’s actually happening. A project can be Green on budget and Red on schedule simultaneously. Report both — it’s more useful than a single blended rating that obscures where the problem actually is.

What to include — and what to cut

Most status reports include too much. Here’s a guide to what earns its place:

• Keep: Overall RAG by dimension, one-paragraph summary, top three risks, decisions needed from the sponsor or steering group, next milestone and whether it’s on track
• Move to an appendix: Full RAID log, detailed financial breakdown, milestone tracker, team resource summary — available if needed, not in the main body
• Remove entirely: Lists of meetings attended, lengthy descriptions of completed work, anything that documents activity rather than status

The decisions-needed section is the most important part

Most status reports don’t have one. This is the single biggest missed opportunity in project reporting.

If a project needs a decision from its sponsor — about scope, budget, a risk, a dependency — and that need isn’t explicit in the status report, the sponsor might read the report and feel informed without realising they need to act. The project then stalls waiting for a decision that the sponsor didn’t know they needed to make.

Every status report should end with a clear list of decisions needed, from whom, and by when. If there are no decisions needed, say so. Either way, it’s explicit.

Portfolio reporting — the PMO level

What applies to project-level reports applies equally to the portfolio dashboard the PMO produces for leadership. Lead with the exceptions. Show the RAG summary. List the decisions needed at portfolio level. Keep it to one page. Attach the detail for anyone who wants to go deeper.

Leadership teams don’t need to know the status of every project. They need to know which projects need their attention, what decision or support is required, and whether the portfolio as a whole is on track. Everything else is background noise.