Status Report Template That Does Not Hide Trouble
A one-page status report built so a slipping project cannot look green, confidence in the date rather than a colour, what changed, what is blocked and for how long, and the decision needed this week.
About the numbers here. Numbers in a template are placeholders to replace with your own, not measurements.
Markdown. No sign-up, no email.
Most status reports are green until they are red. This one is structured so that the things which predict lateness (ageing blockers, decision latency, cumulative change) appear whether or not anyone volunteers them.
One page. If it takes half a day to produce, it is consuming the capacity that should be removing blockers.
Project: _______________ Reporting period: _______ Prepared by: _______________ For: _______________
1. The headline#
Would I personally bet on the current end date? yes / no / not any more
If no: by how much, and since when did I know? _______________
This replaces a status colour deliberately. "Amber" is a word that lets everyone defer the conversation; a direct answer to a direct question does not. Projects rarely fail through one event: they fail through a series of "we will catch up next sprint" judgements, none of which is ever escalated.
2. Progress#
| This period | |
|---|---|
| Completed and accepted | |
| In progress | |
| Not started, planned for next period |
Measured by accepted work, not effort spent. Effort spent is a measure of activity; accepted work is a measure of progress, and only one of them predicts a delivery date.
Anything claimed "90% done" for more than two weeks: _______________
3. What changed#
| Change | Impact on date | Impact on cost | Approved by |
|---|---|---|---|
Cumulative since baseline: schedule ____, cost ____
The cumulative row is the one that matters and the one nobody volunteers. Fifteen individually reasonable changes have added eleven weeks; each was assessed alone.
4. Blocked#
| What | Blocked since | Waiting on | Chased | Escalate? |
|---|---|---|---|---|
Oldest blocker: ____ days. Average time to get a decision this period: ____
Delay lives in queues rather than in the work. If the team waits a week for decisions, no delivery improvement changes the outcome, and this table is where that becomes visible to the person who can fix it.
5. Risks that moved#
Only the ones that changed. A full register read-out belongs in the risk register, not here.
| Risk | Was | Now | Why | Action |
|---|---|---|---|---|
Overdue mitigations: ____
6. Quality signals#
| Open defects, by severity | |
| Trend, rising or falling as we approach the end | |
| Anything substantial still untested | |
| Non-functional requirements tested? | yes / no |
Defects rising as the end approaches, or a large untested area, are the two most reliable predictors of a late finish. They belong in the report before they are a crisis.
7. Decision needed this week#
| # | Decision | Who decides | By when | Cost of not deciding |
|---|---|---|---|---|
| 1 |
The last column converts a request into a consequence, which is what turns an unread item into a decision.
If there is nothing here, say so explicitly. A report that never asks for anything trains the sponsor to skim it.
8. Next period#
| Commitment | Owner | Confidence |
|---|---|---|
| high / medium / low |
Written for people who will read one page. Anything requiring more detail goes in an appendix nobody is obliged to open, and if the appendix is where the real news is, this report has failed at its only job.