How long should a project status report be?
A weekly project status report fits on one page. A monthly steering committee pack runs to ten or fifteen slides with an appendix behind it. The page limit is not a style preference: it forces the writer to decide what matters, and that decision is most of the value the report adds.
The lengths that work
| Report | Audience | Length |
|---|---|---|
| Weekly status report | Sponsor, workstream leads, key stakeholders | One page, or one slide |
| Monthly programme report | Programme board, PMO | Two to four pages |
| Steering committee pack | Steering committee | 10-15 slides plus appendix |
| Portfolio summary | Executive, portfolio board | One line per project |
| Go/no-go pack | Decision forum | 10-20 slides, evidence-heavy |
These are conventions rather than rules, but they are stable conventions, and a report that sits well outside them usually has a reason worth examining.
What the page limit is doing
The constraint is not about respecting the reader's time, or not only about that. It is about forcing a decision. On one page, five risks do not fit — three do. That means somebody has to rank them, and the ranking is the analysis. A report with no limit does not require anyone to decide what matters, so it does not contain the decision, and the reader ends up doing the work the writer avoided.
The same applies to milestones. Every milestone on the plan does not fit; the next four to six do. Choosing which ones are near enough to matter is a judgement, and the judgement is the content. This is why status reporting gets harder rather than easier as a project grows.
Where the detail goes
Nothing is being thrown away. It moves to somewhere with a different reading contract.
- The full risk and issue position stays in the RAID log, referenced by ID from the report.
- The full plan stays in the plan. The report carries the milestone view.
- Defect detail stays in the test tracker; the report carries counts by severity and the trend.
- Financial detail stays in the budget tracker; the report carries spend against plan and forecast at completion.
- Anything a reader might ask for goes in an appendix that is attached but not presented.
The appendix is the pressure valve that makes a short front section possible. It also has a rule: nothing in the appendix that the main section depends on. If the reader has to turn to slide 24 to understand slide 4, the report is fifteen pages long and pretending otherwise.
Why reports grow
Length is almost never a decision. It accumulates.
- A stakeholder asks a question once, and the answer becomes a permanent section.
- An earlier report was challenged, and detail gets added defensively so the challenge cannot recur.
- The report is written by assembling contributions from workstreams, and nobody is willing to cut anyone else's slide.
- Nothing is ever removed, because removing a section invites the question of why it was there.
- The report starts being used as an audit record rather than a communication.
A short annual pass over the standing sections — which of these did anyone act on — usually removes a third of the document without anyone missing it.
The relationship between length and being read
A long report is not read more thoroughly than a short one. It is read less thoroughly, and selectively, which means the reader chooses what to focus on rather than the writer. On a one-page report the writer controls the emphasis. On a twelve-page one, whichever paragraph happens to catch the eye becomes the message, and it may not be the one that mattered.
Consistency of length matters as well. A report that is normally one page and arrives at four gets attention before it is read, which is occasionally useful and usually not the intent.
Steering packs
Governance packs run longer because the audience is being asked to decide rather than to stay informed, and decisions need evidence attached. Even so, most of the length belongs behind the decision slides rather than in front of them. The structure is covered in the steering committee report guide and most packs settle at ten to fifteen slides in front with an appendix behind them.
Practical formats
One page in Excel or Word, one slide in PowerPoint. Both work; the choice usually comes down to how the report is consumed. If it is read alone in an inbox, a page is better. If it is presented on a screen with people in the room, a slide is better, because a page projected is unreadable from the back.
The Weekly IT Project Status Report (Excel) is built to the one-page constraint with the dashboard calculated from the underlying data, and the Project Status Report One-Pager does the same job as a single slide. Where a fuller weekly deck is expected, the IT Project Status Report Deck runs to 17 slides with the detail sections designed to sit behind the summary rather than in front of it.
Questions
Is one page realistic for a large programme?
For the programme summary, yes. Large programmes usually run a one-page summary supported by workstream reports of one page each, rather than a single long document.
What goes in the appendix?
Anything a reader might ask for but does not need to reach a view: full risk log extracts, detailed financials, test results, plan detail. Nothing the main section depends on.
Should the report be an email or an attachment?
Whichever is consistent. Many teams put the summary in the email body and attach the report, so the RAG and the decisions needed are visible without opening anything.
How long should a monthly report be?
Two to four pages, or a short deck. It covers a longer period, so trend and forecast take more space than the weekly report gives them.