Status Report

Origin & evolution

The dominant convention is the RAG status, a traffic-light scheme borrowed into project management: Red, Amber, Green. RAG reporting compresses health into a single colour for a glance-level read. Green means on track, Amber means at risk but manageable, Red means intervention is needed now. The appeal is speed; the cost is that a colour hides its own reasoning.

The well-documented failure mode is the watermelon report. A watermelon project is green on the outside and red in the middle: the reported status is green while a closer look reveals serious trouble. The cause is rarely deception. Reporters learn that a red status invites blame instead of help, so they round up, and as one account of the pattern puts it, projects rarely jump from green to red overnight; they slide from "green but actually amber" to "amber but we said green" to "red and everyone knew but nobody said." The cost of finding out late almost always exceeds the cost of finding out early.

The field's response has been to anchor colours to evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference →. A status no longer floats on judgement; it is derived from measured signals, milestone⛳MilestoneProgram ManagementA key date or achievementView reference → slippage, deliverable acceptance, burned budget, so the colour reports a fact rather than a mood. The report becomes trustworthy in proportion to how little discretion the reporter has over the colour.

How it works in practice

A program reports green for five consecutive weeks. The weekly report is a single RAG colour and a paragraph of narrative, both written by the program manager. In week six the integration phase fails and the colour jumps straight to red. The steering group, blindsided, asks the question that always follows: how was this green last week?

The fix is structural. The next report derives its colour from connected facts instead of a paragraph. Three of eight deliverables are past their gated dates: that alone forces amber. The risk register🧯Risk RegisterProgram ManagementA register of project risksView reference → holds two open high-severity items with no mitigation owner: that forces red. The program manager can annotate, but cannot overrule the arithmetic. The watermelon problem shrinks because the colour is now an output of measurable state, not an act of courage by whoever writes the report.

Status report vs. its neighbours

• Dashboard🎛️DashboardData & AnalyticsAn analytics dashboardView reference →: A dashboard is a live, always-on view that the reader pulls when they want it. A status report is a point-in-time snapshot that is pushed on a cadence and framed with narrative. The dashboard shows current state; the report adds interpretation and a timestamp you can hold someone to.
• Milestone: A milestone is one of the dated facts a status report rolls up; whether milestones were hit is a primary input to the colour. The report aggregates many milestones into a single read of health.
• Risk register: A risk register lists what might go wrong, with likelihood and owners. A status report summarises present reality and pulls from the register to justify an amber or red. The register is the standing ledger; the report is this week's read of it.

In the graph

In the Unified Product Graph, a status report sits in the delivery region as a reporting node attached to the work it summarises through program_reported_via_status_reportProgramreported viaStatus Reporthierarchy. Because the report is a connected node rather than a free-text update, its colour can be computed from the same graph it lives in: the gated milestones, the accepted deliverables, the open risks all hang off the program already. That structure is the direct antidote to the watermelon: when the status is derived from connected, queryable facts instead of authored prose, green that contradicts the underlying nodes becomes visibly, mechanically wrong.