How to write a weekly project status report in five minutes

Most project managers spend between two and four hours a week producing a status report, and most sponsors spend under ninety seconds reading it. That gap is the clearest waste in delivery management, and it is entirely fixable.

The five-minute report is not a shorter report. It is the same report, produced from data you already maintain, with your judgement added on top.

Table of contents

• Why weekly reports take so long
• What a sponsor actually reads
• The five-block structure
• An honest RAG rule
• Make the report a by-product
• The five-minute routine
• Mistakes that destroy credibility
• Frequently asked questions

Why weekly reports take so long

Almost none of the time goes on writing. It goes on reconciliation: chasing four people for updates, checking whether the plan in the spreadsheet matches the plan in the tool, working out whether last week's amber is still amber, and reformatting everything into a template that a previous sponsor liked in 2019.

If your report is assembled from separate sources every week, the cost is permanent. If it is generated from a single delivery record, the cost is a review.

What a sponsor actually reads

In order:

1. Is it on track? One word, and whether that word changed since last time.
2. What do you need from me? Decisions, money, people, escalations.
3. What is the biggest risk? Not the list of twelve. The one that matters.
4. What happened, and what happens next? Two short lists.

Everything else is supporting evidence. Milestone tables, burn charts and RAID extracts belong below that, or in an appendix, because they answer follow-up questions rather than the first question.

The five-block structure

Use the same five blocks every week, in the same order. Consistency is what makes a report readable in ninety seconds.

• Status — RAG, plus the direction of travel and the single sentence that explains it.
• Decisions needed — each with an owner and a date by which it is needed. If this block is empty, say so explicitly.
• Top risks and issues — the two or three that could change the outcome, each with the mitigation and whether it is being managed or not.
• Progress this period — completed milestones and material deliverables, not a task dump.
• Next period — what will be true by the next report, phrased so it can be checked.

Resist the urge to add a sixth block. Every addition reduces the chance the first four get read.

An honest RAG rule

RAG is worthless if it is a mood. Write the rule down once and apply it mechanically:

• Green — delivering to the current baseline, with no open issue that requires a decision above you.
• Amber — a milestone is at risk, or a risk is unmanaged, and you have a plan to recover within this reporting period.
• Red — the baseline cannot be met without a decision from the sponsor, or an issue is unmanaged and the impact is material.

Two consequences follow. The first is that green becomes believable. The second is that amber stops being a place to hide, which is what it is on most projects. A useful discipline: an item can only sit at amber for two consecutive reports before it goes red or green.

For the underlying model of what should push a project's rating, see the project governance guide.

Make the report a by-product

The structural fix is to hold the plan, RAID log, decisions and milestones in one place, so the report is a view of that data rather than a separate artefact.

When that is true:

• Milestone status, dates and variance come straight from the plan.
• Top risks come from the RAID log with their real mitigation status.
• The progress list is whatever completed since the last report, automatically.
• Your only job is the narrative, which is the part that needs a human.

In Pocket PMO this is what a snapshot does: it freezes the delivery data at a point in time, drafts the narrative from it, and waits for you to approve before anyone sees it. A frozen snapshot is also defensible later, which a rebuilt spreadsheet never is.

The five-minute routine

Same slot every week, ideally the morning of the day the report is due:

• Minute one — check the delivery signals and confirm the RAG against the rule.
• Minutes two and three — read the drafted narrative, correct anything the data cannot know, delete anything that is padding.
• Minute four — write the decisions-needed block yourself. This is the only block that is genuinely yours, and it is the one that gets you unblocked.
• Minute five — approve and send.

If a week takes longer than that, the cause is almost always missing data rather than a hard report. Fix the data.

Mistakes that destroy credibility

• Reporting green until the week the milestone is missed. Sponsors remember this permanently.
• A risk list that never changes, which tells the reader nobody is managing it.
• Reporting activity instead of outcome, so nobody can tell whether the project moved.
• Changing the format every month, forcing the reader to relearn where the answer is.
• Burying a request for a decision in paragraph six.

Related reading

• Efficient project reporting with customisable templates
• Project status reporting: boost visibility and decisions
• PMO dashboard: real-time portfolio visibility

Frequently asked questions

How long should a weekly status report be?

One page, or one screen on a phone. If a sponsor has to scroll twice before finding the status, the report is too long.

Should the report include every risk?

No. Include the two or three that could change the outcome, and leave the full log available for anyone who wants the detail.

How do I stop amber becoming permanent?

Set a rule that an item cannot stay amber for more than two consecutive reports. It either recovers to green or escalates to red with a decision attached.

Can AI write the status report for me?

It can draft the factual sections from your delivery data and propose the narrative, which removes most of the work. The judgement, the decisions requested and the final approval should stay with you.