When to use
Use this for the recurring update that tells stakeholders whether the project is on track, what moved since last time, what is stuck, and what you need from them. Reach for it on your reporting cadence, or any time health changes materially (green to red) between cadences.
Not for: pitching a new feature or arguing roadmap direction (that is product-management). Not for authoring the standing reporting template or governance process itself (that is operations). This is a concrete, this-period update on one project's delivery.
Method
- Set overall RAG health with a rule, not a mood. Green = on plan; Amber = at risk, recoverable with action; Red = will miss a committed milestone without intervention. Decision point: if any critical-path milestone is threatened, the project is at least Amber regardless of overall vibe.
- State progress against the plan: milestones hit since last update, and next milestone with its date and confidence (see
proj-plan-schedule).
- List blockers — only things actively stopping progress — each with an owner and what unblocks it (pull from
proj-raid-log).
- Make asks explicit and actionable: who, what, by when. Decision point: an ask with no named person and date is noise — either assign it or drop it.
- Note changes to scope, date, or budget and point to the
proj-change-control record.
- Keep it skimmable: health and asks at the top, detail below. Decision point: if a busy sponsor reads only the first three lines, do they know the state and what you need? If not, rewrite the top.
- Send on cadence even when green — silence reads as trouble.
Example
Health: AMBER. Since last week: API milestone hit (day 8, on time). Next: integration by day 16, confidence medium. Blocker: waiting on auth service from Platform, owner Lee, unblocks integration — need it by day 12. Ask: Sponsor to escalate auth priority with Platform lead by Thu. Scope: unchanged. Budget: on track.
Pitfalls
- Watermelon status. Green outside, red inside. Tie RAG to committed milestones, not optimism.
- Activity as progress. "The team worked hard" is not a milestone. Report against the plan's checkpoints.
- Blockers with no owner. Listing a problem nobody owns changes nothing. Name who and what unblocks it.
- Vague asks. "Need more support" is unactionable. Specify person, action, and deadline.
Output format
# Status: <project> <date> HEALTH: 🟢/🟡/🔴
SUMMARY: <2 lines: state + top ask>
ASKS: <who> — <what> — by <when>
PROGRESS: hit=<milestones> | next=<milestone> <date> conf=<H/M/L>
BLOCKERS: <blocker> — owner <name> — unblocks by <date>
CHANGES: scope/date/budget → <ref to change-control or "none">
1---2name: proj-status-update3description: Write a project status update with RAG health, progress against plan, blockers, and specific asks.4---56## When to use78Use this for the recurring update that tells stakeholders whether the project is on track, what moved since last time, what is stuck, and what you need from them. Reach for it on your reporting cadence, or any time health changes materially (green to red) between cadences.910**Not for:** pitching a new feature or arguing roadmap direction (that is product-management). Not for authoring the standing reporting template or governance process itself (that is operations). This is a concrete, this-period update on one project's delivery.1112## Method13141. Set overall RAG health with a rule, not a mood. Green = on plan; Amber = at risk, recoverable with action; Red = will miss a committed milestone without intervention. Decision point: if any critical-path milestone is threatened, the project is at least Amber regardless of overall vibe.152. State progress against the plan: milestones hit since last update, and next milestone with its date and confidence (see `proj-plan-schedule`).163. List blockers — only things actively stopping progress — each with an owner and what unblocks it (pull from `proj-raid-log`).174. Make asks explicit and actionable: who, what, by when. Decision point: an ask with no named person and date is noise — either assign it or drop it.185. Note changes to scope, date, or budget and point to the `proj-change-control` record.196. Keep it skimmable: health and asks at the top, detail below. Decision point: if a busy sponsor reads only the first three lines, do they know the state and what you need? If not, rewrite the top.207. Send on cadence even when green — silence reads as trouble.2122## Example2324Health: AMBER. Since last week: API milestone hit (day 8, on time). Next: integration by day 16, confidence medium. Blocker: waiting on auth service from Platform, owner Lee, unblocks integration — need it by day 12. Ask: Sponsor to escalate auth priority with Platform lead by Thu. Scope: unchanged. Budget: on track.2526## Pitfalls2728- **Watermelon status.** Green outside, red inside. Tie RAG to committed milestones, not optimism.29- **Activity as progress.** "The team worked hard" is not a milestone. Report against the plan's checkpoints.30- **Blockers with no owner.** Listing a problem nobody owns changes nothing. Name who and what unblocks it.31- **Vague asks.** "Need more support" is unactionable. Specify person, action, and deadline.3233## Output format3435```36# Status: <project> <date> HEALTH: 🟢/🟡/🔴37SUMMARY: <2 lines: state + top ask>38ASKS: <who> — <what> — by <when>39PROGRESS: hit=<milestones> | next=<milestone> <date> conf=<H/M/L>40BLOCKERS: <blocker> — owner <name> — unblocks by <date>41CHANGES: scope/date/budget → <ref to change-control or "none">42```
Matrixx0070