What Should Be in a Project Status Report?

The sections that earn their place, the ones that do not, and how to write a status report that gets read rather than filed.

A project status report is a short, regular summary of where a project stands against its plan, budget and risks, written for people who are not involved in the day-to-day work. Its purpose is to let a reader who has not thought about your project since last week form an accurate picture in about three minutes, and to surface anything that needs a decision.

If a reader finishes your report and cannot say whether the project is in trouble, the report has failed regardless of how much it contained.

The sections that earn their place

1. Overall status, with a RAG rating — plus separate ratings for scope, schedule, budget and risk. One line explaining any amber or red, in consequence terms. If the status changed since last week, say so and say why.
2. What changed — completed milestones, missed milestones with revised dates, and decisions taken. Short. This section builds credibility; it is not there to fill space.
3. What is next — what will be done before the next report, and what could stop it.
4. Top risks and issues — no more than five, drawn from the RAID log rather than rewritten. Each with owner, impact and what is being done.
5. Decisions or help needed — the single most valuable section and the one most often missing. State what you need, from whom, and by when.
6. Budget — spent to date, forecast at completion, variance. A variance without an explanation is a question you will be asked anyway.

That is one page. Detail belongs in appendices, available if asked.

What to leave out

A list of everything the team did. Activity is not progress, and a reader cannot tell the difference between forty tasks that mattered and forty that did not.

Risks that never change. The same five risks copied forward for eleven weeks teach the reader to skip the section.

Percentages without a basis. “65% complete” means nothing unless the reader knows what it is 65% of. Milestones are harder to fake and easier to interpret.

Anything the reader cannot act on and does not need to know. Every line that is not decision- relevant reduces the chance the next one is read.

Getting RAG right

RAG ratings fail in two directions. The first is watermelon reporting — green outside, red inside — which is discovered eventually and costs more credibility than an early amber ever would. The second is permanent amber, which conveys nothing.

Agree definitions once and hold to them. A workable set:

• Green — on track against the current baseline; no help needed.
• Amber — a plausible plan exists to recover, but there is something the reader should know about.
• Red — the current baseline will not be met, or recovery requires a decision the project cannot take alone.

Under those definitions, red is an ask, not a confession. Projects that never go red are usually projects whose reports have stopped carrying information.

Frequency and timing

Weekly for an active delivery project; fortnightly once it is stable; monthly only for portfolio-level reporting. Send it on the same day at the same time — reports that arrive unpredictably are read unpredictably.

Circulate a steering committee pack 48 hours ahead. Reports handed out in the room are read in the room, which means the first ten minutes are silent and the decisions are made without preparation. The steering committee report guide covers that longer format.

Writing so it lands

Lead with the ask. Executives read the first third of any document.

Explain in consequence terms. Not “integration testing is delayed” but “integration testing is two weeks late, which moves go-live from 12 September to 26 September unless we add a second test environment”.

Keep the format identical every time. Readers get faster when the layout does not move, and consistency makes trends visible across weeks — which is where the real signal lives.

Never surprise your sponsor in writing. If the report contains bad news, the sponsor should have heard it from you first. A report is a record, not a delivery mechanism for difficult conversations.