Project Status Report Template: One Page, Every Week

What belongs in a weekly project status report — RAG status, milestones, risks, budget — how to define RAG honestly, and why the layout should never change.

A status report has one job: to let someone who is not in your project decide whether they need to do anything. Most reports fail at that job by describing activity instead of position.

Activity is what the team did. Position is where the project now stands relative to where it said it would be. Only the second one is decision-relevant.

The six sections

1. Overall RAG, plus a rating each for scope, schedule, budget and risk. A single overall colour hides too much — a project can be green on schedule and red on budget, and that combination calls for a different conversation than either alone. Add one line explaining every amber and red, in consequence terms. Not "integration testing is delayed" but "integration testing is two weeks late, which moves go-live from 12 to 26 September unless a second test environment is added."

2. Progress since the last report. Milestones completed, milestones missed with revised dates. Three to five bullets. This section builds credibility; it is not the place to demonstrate effort.

3. Planned for the next period. What will be finished before the next report, and what could stop it.

4. Top risks and issues. Three to five, drawn from the RAID log rather than rewritten, each with an owner and what is being done. If everything appears here, the reader cannot tell what deserves attention.

5. Milestones. Baseline date, forecast date, status. The gap between baseline and forecast is the single most informative number in the whole report, and it is the one most often quietly removed once it grows.

6. Budget. Approved, spent to date, forecast at completion, variance. A variance without an explanation is a question you will be asked anyway, so answer it in the report.

Defining RAG so it keeps meaning something

Left undefined, amber drifts into meaning "slightly worried" and stops carrying information. Write the definitions into the template itself:

• Green — on track. No intervention needed.
• Amber — at risk, and a recovery plan already exists. The project manager is handling it and is telling you so you are not surprised.
• Red — off track. A decision is needed from someone above the project manager, and here is what that decision is.

The word that does the work in the amber definition is already. Amber without a recovery plan is red with better manners.

There is also a discipline in the transitions. If the status changed since last week, say so and say why. Steering groups notice colour changes far more than they notice content, and an unexplained shift from green to red destroys more trust than the underlying problem does.

Watermelon reporting

Green on the outside, red on the inside. It happens for understandable reasons — a sponsor who reacts badly to amber, an organisation where red invites an audit rather than help — but it always surfaces, usually at the worst possible moment.

The practical defence is to make amber cheap. A project manager who can raise amber, get help and return to green without a post-mortem will report honestly. One who cannot, will not, and no template fixes that.

Keep the layout still

Committees read faster when nothing moves. Same sections, same order, same position on the page, every week. Two things follow from that: readers stop spending attention on navigation, and trends become visible — the milestone that has slipped by two weeks in each of the last three reports is obvious when the rows line up and invisible when the layout changes.

Distribute at the same time each week as well. A report that arrives on Tuesday, then Thursday, then Monday gets read once and then ignored.

Status report or steering committee pack?

They are not the same document and should not be merged.

A status report informs. It goes out weekly to the project team, the sponsor and interested stakeholders, and it needs no response.

A steering committee pack asks. It goes out 48 hours before a meeting, leads with the decisions required, and includes financials and escalations in more depth. If your steerco pack contains no decisions, the meeting is a briefing and is probably not needed.

Most projects need the weekly one-pager and a fuller pack monthly. Writing the pack is easier when the weekly report already exists, because the trend data is sitting there.

Building it

One page. If the reader has to scroll, the important line will be missed. Build it in Excel rather than a document if you want the milestone and budget sections to update themselves from the underlying plan — that removes the transcription errors that creep in when someone retypes dates each week under time pressure.