How to Write a Project Status Report: A Practical Guide
A project status report is a short, regular update that tells stakeholders where the project stands. It answers three questions: are we on track, what got done, and what needs attention. Done well, it takes the project manager thirty minutes to write and saves hours of status meetings and hallway check-ins.
When to Use This
Use a status report for any project that runs longer than three weeks and has more than a couple of stakeholders. Weekly is the standard rhythm for most projects; bi-weekly works for slow-moving ones; daily is for the final week before a critical deadline. Send it on the same day each time, every Friday at 4pm, for example, so people know when to expect it. It is especially important when things are going badly: silence during a troubled project destroys trust faster than bad news does.
How to Fill It Out
Section 1: Overall status (RAG rating). Start with a single colour: Green (on track), Amber (at risk, needs attention), or Red (off track, needs intervention). Then write one sentence explaining the rating. “Amber: design is two days behind, but the buffer absorbs it if testing starts on schedule.” Be honest. A project that has been green for ten weeks and suddenly goes red on week eleven has a reporting problem, not just a project problem.
Section 2: Progress since last report. List what was actually completed, finished items, not activity. “Completed: homepage design approved, payment test account created, supplier shortlist agreed.” Include the milestone progress: “Milestone 2 (design sign-off) is 80% complete, due 15 May.” If nothing meaningful finished, say so plainly and explain why rather than padding the list.
Section 3: Planned for next period. List the specific tasks due before the next report, with owners. “Next week: Tom builds checkout page (due Thursday); Priya runs first payment test (due Friday).” This turns the report into a commitment device, everyone named knows they will be asked about it next week.
Section 4: Issues and risks. List anything blocking progress or threatening the plan, with an owner and a next step for each. “Issue: payment provider’s test environment is down since Tuesday. Owner: Priya. Next step: escalate to provider support today; fallback is manual testing with the sandbox if not resolved by Thursday.” Distinguish issues (problems happening now) from risks (problems that might happen), both belong here, but they need different responses.
Section 5: Budget and schedule snapshot. Give the key numbers: “Budget: £28,400 spent of £60,000 (47%); forecast to finish at £58,000, within budget. Schedule: overall 2 days behind; milestone 2 due 15 May at risk.” Stakeholders will not read a full spreadsheet, but they will read four lines of numbers.
Section 6: Decisions needed. This is the most valuable section. List anything you need from stakeholders, with a deadline. “Decision needed: choose between payment provider A (£900/month) and B (£1,200/month) by Wednesday, build cannot proceed without this.” If a decision has been waiting for two weeks, write “overdue by 10 days” next to it. Nothing moves stalled decisions like seeing them in print.
Common Mistakes
1. Reporting activity instead of progress. “Worked on the design” tells the reader nothing. “Homepage mockup completed and sent for review” tells them everything. Every item should describe a finished outcome or a concrete next step. If you cannot phrase it as an outcome, the work is not far enough along to report.
2. Hiding bad news in jargon. “We are experiencing some challenges with the timeline” means “we are late.” Say “we are four days late on design because the review took two rounds instead of one, and here is the recovery plan.” Stakeholders forgive late projects; they do not forgive surprises. The report that first mentions a problem should never be the one that announces it missed a milestone.
3. Writing it only for the sponsor. The report goes to everyone with a stake: the sponsor, team leads, and anyone affected by delays. If the customer service team needs to prepare for a launch, they need the same information the sponsor gets. One report, one audience list, no secret versions.
4. No decisions-needed section. Many reports describe the situation perfectly and then end, leaving every open decision floating. If you need something from someone, put it in the report with a name and a date. A status report that never asks for anything is a newsletter.
Who Needs to Sign Off
The project manager writes and sends the report, no approval cycle should delay a weekly update. The sponsor should acknowledge it, at least with a reply confirming any decisions. If the report contains an Amber or Red rating, discuss it with the sponsor before sending so they are not blindsided in a group email. For Red status, the sponsor and project manager should agree the recovery plan first.
How Often to Review and Update
Write and send the report on a fixed weekly rhythm, every Friday, for example, regardless of how quiet the week was. “No change since last week” is a valid report. Review the format monthly: if the same issues appear week after week with no progress, escalate rather than copying them forward. Archive every report so there is a record of when problems first appeared and what was decided.
Download the free Project Status Report.