Status Reports That Work: RAG, Weekly, One Page

The status report is the artifact that lets stakeholders trust the project without attending every meeting. Done well, the weekly report replaces ten ad-hoc DMs and three "quick syncs". Done poorly, it becomes shelfware that nobody reads. This chapter shows the one-page format and the discipline that keeps it useful.

When does a written status report start paying back?

Three signals.

More than 5 stakeholders care. Below five, you can DM each of them. Above five, the same answer needs to be sent asynchronously to many - the stakeholder map from chapter 4 tells you who.

Project longer than 6 weeks. Below that, the kickoff doc and demo cadence cover comms. Above it, weekly status surfaces drift before the demo reveals it.

Stakeholders not in your daily rhythm. Sponsor, partner team, customer success - people who do not see your standups. The status report is their window.

If the project is short, small-team, internal, weekly status is overhead. A Slack thread does the job.

What is the cost of skipping or doing status badly?

Three failure modes.

Sponsor surprised at demo. "I didn't realise you were behind." The PM thought it was obvious; nobody documented it. Trust erodes.

Decisions stuck in standups. "We need an answer from Legal"

• noted in standup, never escalated, blocks the team for two weeks. The status report's "decisions needed" section would have caught it.

Status drift. Always-Green status. When something does go wrong, the jump from Green to Red is shocking. With Amber as a real option, drift is visible.

What does the minimal status report look like?

# Status: {{ Project Name }} — Week of 2026-06-18

## Headline
🟡 **Amber** — Refund flow on track for July 8 launch; Stripe
SDK delay creates 1-week risk. Mitigation in progress.

## What shipped this week
- Refund button live behind feature flag (100% internal, 5% prod)
- Refund email template approved by Design and Legal
- API endpoint passes performance gate at 1K req/s

## Top 3 risks
1. **Stripe SDK v3 release slipped to July 12** (Amber)
   Owner: Bob. Mitigation: building adapter on v2; will switch
   at GA. Status: 60% complete.
2. **QA env flaky 2 days last week** (Amber)
   Owner: Carol with Infra team. Mitigation: dedicated test pod
   shipped Wednesday. Status: monitoring.
3. **Customer support runbook needs Legal sign-off** (Green)
   Owner: PM. Status: review scheduled Tuesday.

## Decisions needed
- Confirm launch communication template by Wednesday
- Approve allocating Designer 50% to launch QA in week of July 1

## Next week
- Ramp refund flow to 25% of users
- Customer support training session
- Final dry-run of rollback process

---
On track for: July 8 launch
Confidence: 75% (was 85% last week)

The template is < 1 page intentionally. The headline is the elevator pitch; if the sponsor stops reading there, they still have the answer.

What does the RAG decision rule look like?

flowchart TB
    Q1{Will we hit<br/>committed date<br/>and scope?}
    Q1 -->|Yes, no concerns| Green[🟢 Green]
    Q1 -->|Yes, with risks named| Amber[🟡 Amber]
    Q1 -->|No, intervention needed| Red[🔴 Red]
    style Green fill:#dcfce7
    style Amber fill:#fef3c7
    style Red fill:#fee2e2

The decision is binary on date+scope, three-state on confidence. Green means no current concerns; Amber means named concern with mitigation; Red means the team cannot hit the target without help (more time, less scope, more people).

The discipline: never go Green when you mean Amber. The most common mistake is wanting to "look good" with Green and then explaining at launch why the date slipped.

How does status report scale to multi-team?

flowchart TB
    TeamA[Team A status] --> Program[Program status<br/>1 page rollup]
    TeamB[Team B status] --> Program
    TeamC[Team C status] --> Program
    Program --> Exec[Executive status<br/>3 lines]

Each team sends their own status; the program lead rolls up to a one-page program report; that compresses to 3 lines for the executive monthly review. Compression is brutal: the executive gets the worst RAG across the program plus the top 3 risks overall.

What failure modes does the status report introduce?

• Always Green. RAG never moves until launch slips. Mitigation: define explicit triggers - 1 day slip = Amber, 1 week slip = Red. Force the change.
• Same boilerplate every week. "Things are going well, no blockers." Nobody reads after week 3. Mitigation: at least one new fact per week or the project doesn't need a report.
• Status as wish list. "Will probably ship by July 15" with no basis. Mitigation: every claim has a source - a shipping milestone, a demo, a metric.
• Risks rotating without resolution. Same top 3 risks appear week after week, no closure. Mitigation: each risk has owner + mitigation + due date; if no progress in 2 weeks, escalate.

When is a written status report overkill?

Two cases.

Async-first team with public Slack. If everything is in public channels and the sponsor reads daily, a weekly report duplicates. Move to monthly summary.

Internal-tools team. A platform team with continuous flow (Kanban) reports throughput and cycle time monthly, not project status weekly.

The report earns its 30 minutes when stakeholders are not in your daily channel and the project has a defined end-state.

Where should you go from here?

Next chapter: decision logs and ADRs - the artifact that records why the project made the choices visible in the status report. After that, case studies put every artifact you've learned into action on real project shapes.