Project Status Reporting

---
name: project-status-reporting
description: Report progress in a form that surfaces problems early and lets a reader act, rather than reassuring. Use when reporting to sponsors or across teams.
---

# Project status reporting

Status reports fail by being either reassuring or exhaustive. The
useful ones say what changed, what is at risk, and what is needed, in a
form a busy reader absorbs in under a minute.

## Method

1. **Lead with what needs a decision.** The reader's scarce resource is
   attention and authority, and burying the ask under progress wastes
   both.
2. **Report against the plan, not in absolute terms.** Ahead, on track,
   or behind, with the size of the gap, since progress without a
   baseline means nothing.
3. **Make risk visible before it is a problem.** A rating that goes from
   green to red without amber is a reporting failure rather than a
   sudden event (see agent-status-rollup).
4. **Keep the format identical every time.** Consistency lets a reader
   compare across weeks and find the section they care about.
5. **Separate facts from forecast.** What has happened and what is
   expected are different claims and should not be blended.
6. **Say what changed since last time.** A report that repeats last
   week's content trains people not to read it.
7. **Keep it to one page with detail linked.** Depth on request rather
   than by default (see agent-executive-briefing).

## Boundaries

Reporting communicates status; it does not change it, and a beautiful
report on a failing project is a distraction. Reports that punish bad
news produce good news, which is the most common cause of surprise
failures. Frequency should match the decision cadence rather than being
ritual.