A status report is supposed to do two things: tell the sponsor what’s happening, and force the project manager to look at the project honestly. Most status reports do the first thing badly and the second thing not at all. The fix isn’t a better template — it’s a stricter cadence, a written-not-spoken default, and an operational definition of what each colour code means.
Why weekly
We’ve tried daily, weekly, biweekly, and “as needed.” Weekly wins for one reason: it’s the smallest unit of time over which a project’s state actually changes meaningfully. Daily reports are noise (nothing has changed since yesterday in 90% of cases, so you start padding). Biweekly reports are too long an interval to catch slippage early. “As needed” means “when it’s already on fire.”
Weekly forces the same question every Friday: what changed this week, and does the plan still work? If the answer is “nothing changed,” the report is one line and that’s fine — the discipline is in the asking, not the writing.
Why written
Verbal status updates in a meeting feel efficient. They aren’t. Three failure modes:
- The room hears what the speaker emphasises. A risk mentioned in passing gets forgotten. A risk written down stays written.
- Asynchronous review beats synchronous review. A sponsor reading the status on Saturday morning, coffee in hand, catches things they’d miss in a 30-minute meeting wedged between two other meetings.
- Written reports compound. Twenty weekly written reports form an audit trail you can read end-to-end. Twenty weekly meetings form a folder of half-remembered conversations.
Meetings are for deciding things, not reporting things. We send the written status 24 hours before the weekly call so the call can be about decisions and unblocking, not the report itself.
The format
One page. Five sections. No exceptions.
- Headline. One sentence: where is this project right now? “On track for May 12 close” or “Plan slipping by two weeks; new close target May 26” — that level of plainness.
- What we shipped this week. A bulleted list of done things, with one observable per item. “Permits filed” is bad; “Permits filed and confirmed received by the city clerk” is good.
- What we’re shipping next week. Same format. Concrete, observable, dated.
- Risks fired or changed. What moved on the register. If nothing moved, write “no register changes” — but don’t omit the section.
- What we need from you. Decisions, signatures, introductions, money. Specific people, specific dates, specific items.
That’s the whole format. We’ve maintained the same five-section template across every engagement for years and have not yet hit a project that needed a sixth section.
What the colour codes actually mean
The status headline gets a colour: green, yellow, or red. Most projects use these casually. We’ve operationalised them with three rules nobody is allowed to bend:
- GREEN — no plan changes needed; risks are tracked and triggers haven’t fired. Not “things feel good.” Not “we’re working hard.” Specifically: no change to the schedule, the budget, or the deliverable set is required this week.
- YELLOW — we’re proposing a plan change. Something happened — a risk fired, scope shifted, a vendor missed — and we want a decision on a specific adjustment. Yellow always comes with a proposed action and the cost/schedule implication of acting vs. not acting.
- RED — the project as currently planned will not succeed and we need a re-plan, not an adjustment. This is rare. It means the success criterion is no longer reachable from where we are, and we’re asking the sponsor whether to re-baseline, descope, or stop.
The rule that makes this work: a project cannot be green for the first time after being yellow without an explicit “what changed” entry in the status. You can’t quietly flip back to green by hoping. The transition has to be named.
When the status is short
Sometimes the honest weekly status is two sentences. “On track. No register changes. Continuing build per plan.” We send it anyway. The cadence is the point; the length isn’t. A one-line green report is a successful artifact — it means the project is healthy enough that there’s nothing to say. Padding it would be worse.
Sponsors who feel that a one-line report is “not enough” usually feel that way because they’ve been trained by years of bloated status reports to expect length as a proxy for diligence. We re-train them by being consistent: short when honest, long when honest, never long when nothing happened.
What we don’t do
- No RAG dashboards. A spreadsheet with 30 sub-projects all coloured green is a snapshot of nothing. Either each sub-project gets its own honest status, or we roll them all up to the one engagement-level status.
- No “percentage complete” numbers. They’re guessable from the schedule and not informative beyond it. They give the illusion of progress in flat weeks.
- No status meeting that is the status. If the meeting is the report, the report doesn’t exist when the meeting ends. The written report is the durable artifact; the meeting is the discussion of it.
The aim across all of this is the same one we hold for every Run-phase practice: no surprises that should have been seen. The weekly written status is the surface on which “should have been seen” is operationalised. If a surprise lands without warning, the question is always: which week’s status should have flagged this? Usually we can name it — and the lesson goes into the close-phase Lessons Learned.