What goes in a weekly project status report?
A weekly status report carries seven blocks: overall RAG with a one-line summary, progress since the last report, what is planned next, milestones with baseline and forecast dates, top risks and issues, decisions or actions needed from the reader, and budget if it is reported weekly. One page. Everything else is an appendix.
The seven blocks
A weekly report is a standing format, which is the point. Readers learn where to look, and week-on-week comparison becomes possible because the same fields sit in the same places. Rearranging the layout each week destroys both.
| Block | Contents | Length |
|---|---|---|
| Overall status | RAG colour, direction of travel against last week, one sentence of why | One line |
| Progress this week | What completed, not what was worked on | Three to five bullets |
| Planned next week | What is expected to complete, with owners | Three to five bullets |
| Milestones | Baseline date, forecast date, status | Table, next four to six only |
| Risks and issues | Top items by score or severity, with owner and next action | Three to five rows |
| Decisions and actions needed | What the reader has to do, by when | Explicit list, or "none this week" |
| Budget | Spend to date against plan, forecast at completion | One line or a small table |
Some organisations add a scope-change line and a resourcing line. Both are reasonable additions when they change often enough to be worth a weekly slot.
What each block is for
Overall status. The colour on its own tells the reader very little. The colour plus the direction — amber and improving, or amber and worsening — tells them whether to intervene. The rule that produces the colour matters as much as the colour itself, and it belongs in the reporting standard rather than in the reporter's head.
Progress. The distinction between completed and worked on is the difference between a report and a diary. "Continued integration testing" appears in four consecutive reports and carries no information. "Integration test cycle two closed with 12 open defects, 3 of them severity two" does.
Planned. Reading last week's planned block against this week's progress block is how a reader forms a view on whether forecasts from this project are reliable. That comparison only works if the planned items are specific enough to be either done or not.
Milestones. Two dates, always. A single date column lets a slipping milestone move quietly, week by week, with each report internally consistent. Baseline against forecast makes the drift visible in one glance.
Risks and issues. Not the whole log, which lives in the RAID log. The top few by score, plus anything newly escalated or newly closed. Each with an owner and a next action, because a risk with no action is an announcement.
Decisions and actions needed. The block most often missing, and the one that makes the report do work rather than describe work. If nothing is needed, saying so explicitly is better than leaving the section out, because absence reads as an oversight.
What to leave out
- Effort narrative. How hard the week was is not status. It reads as pre-emptive defence.
- Task-level detail. A reader who wants to know which tickets moved will ask for the board. The report is the level above that.
- Unresolved internal disagreement. Report the position and the decision required, not the argument.
- Colour without a rule. Green because the team feels fine is the habit that makes every RAG dashboard in the organisation worthless.
- Everything that happened. Completeness is not the goal. A report nobody finishes has failed regardless of what it contained.
Weekly report and steering pack are not the same document
The weekly report goes to the working audience: sponsor, workstream leads, key stakeholders. It is short, factual and disposable. The steering pack goes monthly to a governance body and is built around decisions the committee has to take, with the supporting evidence attached. Sending the weekly report to a steering committee usually produces questions the report was never designed to answer; the shape of the governance version is covered in the steering committee report guide.
Distribution and rhythm
The same day, the same time, every week, whether or not there is much to say. A report that arrives when there is news trains the distribution list to read its absence as bad news, which is not a signal anyone intended to send. Same channel too — a report that arrives sometimes as an attachment and sometimes as a link in a chat thread gets lost.
Late reports are worth noticing as a signal in themselves. A status report consistently sent on Tuesday for a Friday period end is usually a project where the numbers are being reconciled after the fact.
Format
One page. The constraint is doing useful work: it forces the writer to decide what matters, and that decision is most of the value the report adds. The Weekly IT Project Status Report (Excel) holds all seven blocks on a single sheet with the RAG dashboard calculated rather than typed, and includes a filled-in example. Where the audience expects slides rather than a sheet, the IT Project Status Report Deck covers the same content in a format that projects, and the one-pager reduces it to a single slide.
Questions
Should the status report include the full RAID log?
No. It carries the top few risks and issues by score or severity, plus anything newly escalated or closed. The full log stays where it lives and is referenced by ID.
What if nothing significant happened this week?
Send it anyway with the same structure. Skipping quiet weeks makes the arrival of a report a signal in itself, which distorts how every future one is read.
Who should receive the weekly report?
The sponsor, workstream leads and stakeholders who act on it. A large distribution list of readers who never respond is a sign the report is being used as coverage rather than communication.
Should the report include a forecast completion date?
If the date is a live question, yes — as a forecast against baseline in the milestone table rather than a separate claim in the narrative.