Most status reports are written so the project manager can say "I informed you". Nobody reads them. A good status report is written for a different purpose: so a manager can decide in three minutes whether they need to do something. The difference is structure, not length.
Three questions every report must answer
- Are we on track? Schedule, budget and scope — on plan or drifting?
- What has changed? Since last time: deliverables completed, new risks, decisions made.
- What do I need from you? A decision, a resource, an approval — specific, with a date.
The third point is the reason the report gets read at all. A report that asks for nothing is a newsletter.
The one-page structure
| Block | Content | Length |
|---|---|---|
| Overall status | Green / amber / red plus one sentence of reasoning | 1 line |
| Milestones | Next 2–3 dates and whether they hold | 3 lines |
| Budget | Spent / budgeted / free balance | 1 line |
| Completed | Deliverables finished, not activities performed | 3–5 lines |
| Risks and issues | Top 3, each with an owner and a next step | 3 lines |
| Decisions needed | What, from whom, by when | 1–3 lines |
A traffic light that means something
- Green — the deviation fits inside the float; the PM handles it.
- Amber — a solution exists but needs someone else's decision or resource.
- Red — the deadline, budget or scope is no longer achievable without a change.
The most common disease is the watermelon report: green outside, red inside. It comes from organisations where red is punished. If management wants honest reports, the first red has to bring help, not an interrogation.
Report deliverables, not activity
"We worked on the data migration" says nothing. "Data migration: 9 of 12 tables moved, the remaining 3 depend on client approval" says everything. The first is activity, the second is a state.
The same goes for percentages. "80% done" is the most common way to hide that the last 20% will take as long as the first 80. Counting finished deliverables is better: four of eight is a claim that can be checked.
How often?
- To the team — weekly, short, work-supporting.
- To the client or steering group — fortnightly or monthly, decision-oriented.
- To the funder — on their form and their rhythm, usually quarterly.
- Out of cycle — immediately when status turns red. Bad news does not improve with waiting; it just gets more expensive.
Common mistakes
- Too long. Three pages means only the first paragraph gets read — so write that paragraph and stop.
- Good news only. Trust disappears at the exact moment a hidden problem surfaces.
- Numbers without context. "€62,000 spent" says nothing unless it sits next to how much work is done.
- No ask. If the report does not end with a specific question, no answer comes back.
- Hand-assembled data. If producing the report takes half a day, sooner or later it stops being produced.
How Projektiassistent makes reporting fast
When schedule, tasks, budget and risks live in one place, status does not have to be gathered from five files — it is already there. Milestone state, spent and free balance, and the top-priority risks come straight from the project data, while the decision log shows what has been decided since last time. The project manager's work stays where it adds value: interpreting the situation and asking for the right decision.
Summary
A good status report fits on one page, answers three questions — are we on track, what changed, what do I need — reports deliverables, uses an honest traffic light and ends with a specific ask. Above all, producing it must not take longer than reading it.
If you want the project's state available at any moment, start here: projekt2.projektiassistent.ee.