How to write a project status report people read

Project status reports have a reputation problem. They arrive every week, they look the same every week, and most readers skim the first line and close them. That is not always the reader’s fault. Many status reports are written to prove that work is happening rather than to tell anyone what they need to know.

A useful status report does three jobs. It tells the sponsor whether the project is on course. It asks for the decisions only they can make. And it warns them early about what could go wrong. Everything else is optional.

Write for the sponsor, not the team

The project team already knows what happened this week. The report is for the people who don’t: the sponsor, the steering group, the heads of the teams lending people to the project. They want to know, in under two minutes, whether to worry and whether they are needed.

That changes what goes in. A list of tasks completed is useful to the team and mostly noise to a sponsor. A sentence saying “Testing is a week behind because the vendor delivered the build late; launch date holds if the fixes land by Friday” is what they came for.

Lead with the status, in words

Most status reports use a colour: green, amber, red. The colour is useful as a signal, but on its own it hides the reasoning. Two project managers can rate the same situation differently, and a project can sit at amber for months without anyone asking what amber means.

Pair the colour with a one-sentence reason, and write down what each colour means for this project:

Status	Meaning on this project
Green	On track for the agreed date and budget; no help needed
Amber	At risk, but the team has a plan that doesn’t need the sponsor
Red	Will miss the date or budget without a decision from the sponsor

With that table agreed, “Red” stops being an alarm and becomes a request. It also makes it harder to keep a project at amber out of politeness.

A structure that holds up week after week

Keep the same sections in the same order, so regular readers know where to look:

1. Status and reason. The colour and one sentence on why.
2. Decisions needed. What you need, from whom, by when. If nothing, say “None this week”.
3. Progress against milestones. The next three or four milestones with their planned and forecast dates.
4. Risks and issues. The few that matter now, each with an owner and a next step.
5. Budget. Spent to date against plan, if the readers track it.
6. Next period. Two or three lines on what should be true by the next report.

Putting decisions second is deliberate. It is the section most likely to get something done, and the one most often buried at the end. If you would rather not lay it out from scratch, a project status report template can be adapted to these six sections.

Make milestone dates honest

The milestone table is where status reports quietly lose credibility. A date that moves every week, with no note, teaches readers to stop trusting the dates.

• Keep the original date visible alongside the current forecast.
• Note each change once, with the reason, in the week it happens.
• Forecast, don’t hope. If the team doesn’t believe a date, the report shouldn’t show it.

For example, a row reading “User testing: planned 14 March, forecast 21 March (vendor build late)” tells a sponsor more than a cell that silently changed from one date to the other.

Write risks so someone can act on them

“Resourcing” is not a risk. It is a topic. A risk worth reporting says what might happen, what would cause it and what is being done:

If the data team stays on the year-end close until mid-April, the migration will slip by two weeks. We have asked for one analyst to be released from 1 April; decision needed from the finance director.

Limit the list to the risks that could change the date, the cost or the scope. A register of forty items belongs in the project file, not the weekly report.

Keep the numbers and the words apart

Status reports often carry figures that change every week: budget spent, tickets closed, test cases passed. When those figures are typed in by hand, they drift out of step with the source, and the commentary around them goes stale with them.

Treat the figures as data and the commentary as judgement. Pull the numbers from one tracker or spreadsheet, and write the sentences so they still make sense if a figure moves slightly. Writing commentary for numbers that change covers the habit in more detail, and the weekly layout in KPI report templates that stay current adapts well to a project.

Cut what nobody reads

A status report gets shorter as it gets better. Some things to remove:

• long lists of completed tasks
• the same risk copied unchanged for six weeks with no new action
• background the readers already know
• charts that need a paragraph to explain

If a section has said the same thing for a month, either something should change or the section should go. Longer reflections, such as trends across the quarter and lessons learned, belong in a separate quarterly project update for the steering group rather than in every weekly report.

A quick test before you send

Read the report as the sponsor would, in the time they will give it. Ask:

1. Do I know within ten seconds whether to worry?
2. Is it clear what is being asked of me, and by when?
3. Would I notice if a date had moved?

If the answer to any of these is no, the report isn’t finished. If all three are yes, it is probably the most useful page your sponsor reads that week.