Overview
A program status report has one job: give stakeholders the information they need to make decisions or remove blockers, in under 3 minutes. The failure mode is burying the lead - putting good news first and hiding the red items in paragraph 4. The format here front-loads risk and decisions needed, then provides supporting detail. Stakeholders who need detail can read further; those who only need the headline get it immediately.
Workflow
Step 1: Gather inputs
Ask the user for:
- Program name and reporting period (e.g., "Week of March 3")
- Overall RAG status (Red / Amber / Green) - if they are not sure, work through it in Step 2
- Key accomplishments since last report (what shipped, what was decided)
- Current blockers (what is slowing or stopping the program)
- Decisions needed from stakeholders (specific asks, not general concerns)
- Upcoming milestones (next 2-3 checkpoints and dates)
- Any risks that surfaced or changed this period
If the user provides a narrative or notes, extract these fields from their input before generating the report.
Step 2: Determine the RAG status
If the user is unsure of the overall status, use this rubric:
Green: Program is on track. No unresolved blockers. Milestones will be met as planned.
Amber: Program is at risk. One or more of:
- A milestone is at risk but there is a recovery plan
- A dependency is unresolved but expected to resolve within 1 sprint
- Scope reduction is being discussed but not yet decided
Red: Program is off track. One or more of:
- A milestone will be missed with no recovery plan
- A dependency is unresolved with no clear path forward
- Scope or date change is required and has not been approved
- A critical team or resource issue has no mitigation
Amber should be used before a problem becomes Red - it is an early warning, not a failure state. Do not use Green if anything requires stakeholder action.
Step 3: Write the report
Use this template exactly:
PROGRAM STATUS - [your program]
Period: [week / sprint / date range]
Updated: [date]
Owner: [your name]
STATUS: [GREEN / AMBER / RED]
[One sentence explaining the status. If Amber or Red, name the specific issue.]
---
DECISIONS NEEDED
[If none, write "None this period."]
1. [Decision needed from whom, by when, and what happens if it is not made]
2. [Next decision if any]
BLOCKERS
[If none, write "No active blockers."]
1. [Blocker description] - Owner: [name] - Target resolution: [date]
2. [Next blocker if any]
---
ACCOMPLISHMENTS (this period)
- [What shipped, what was accepted, what was decided]
- [Keep to 3-5 bullets max. Not every ticket - program-level progress only]
UPCOMING MILESTONES
| Milestone | Target Date | Status |
|-----------|------------|--------|
| [name] | [date] | On track / At risk / Delayed |
| [name] | [date] | [status] |
---
RISKS (new or changed)
[If none, write "No new risks this period."]
- [Risk]: [likelihood] / [impact] - Mitigation: [action and owner]
NOTES / CONTEXT
[Optional: 2-3 sentences of context that stakeholders need. Skip if nothing material.]
Step 4: Apply the three-minute rule
After writing the report, verify:
- A stakeholder can read the STATUS line and DECISIONS NEEDED section in 30 seconds and know if action is required from them
- The report is 1 page max when pasted into Slack, email, or a wiki
- Accomplishments section is 3-5 bullets - not a sprint changelog
- If anything in the Blockers or Decisions section is more than 2 lines, it is too long - link to a separate doc
Step 5: Calibrate frequency and audience
Recommend the right distribution based on program phase:
- Weekly: standard for active programs with external dependencies or stakeholder decisions pending
- Bi-weekly: appropriate for programs in steady-state delivery with no active escalations
- Daily: only when a program is Red and actively in recovery mode
Audience guidance:
- Executives / leadership: STATUS + DECISIONS NEEDED only. They do not need the milestone table.
- Peer teams / dependencies: BLOCKERS + UPCOMING MILESTONES. They need to know what you need from them.
- Full team: Full report including accomplishments and notes.
Anti-Patterns
1. Green-washing - everything is always green
Bad: Status is Green every week until the release is 2 weeks late.
Good: Use Amber early. Amber means "we have a plan but it needs attention" - that is valuable signal, not failure.
2. Accomplishments section as a ticket dump
Bad: 15 bullets listing every closed Jira ticket.
Good: 3-5 program-level progress statements. "Core checkout flow accepted by QA" not "JIRA-1234, JIRA-1235, JIRA-1236 closed."
3. Vague blockers
Bad: "We're blocked on infrastructure."
Good: "Waiting on cloud team to provision staging environment. Owner: [name]. Target: [date]. If not resolved by [date], release date is at risk."
4. Decisions buried at the bottom
Bad: Status report where the decision needed from leadership is in paragraph 6.
Good: DECISIONS NEEDED is the second section - immediately after the RAG status line.
5. No cadence - status reports only when things go wrong
Bad: Stakeholders only hear from you when there is a crisis.
Good: Regular cadence trains stakeholders to expect updates and creates a paper trail. It also normalizes Amber status before it becomes Red.
Quality Checklist