Green is a judgement, not a colour
· 4 min read · by Tan Gravam
How do you make RAG status reports useful?
The short answer
A status colour is only worth reading if it carries the reasoning behind it: what changed since last time, what is now different from the plan, and what decision or help is needed. Colour alone decays fast, because reporting amber costs a conversation and reporting green costs nothing, so everything drifts green until it goes red without passing through amber. Ask for the sentence rather than the rating and the rating becomes honest as a side effect.
Every delivery organisation eventually builds a status board, and every status board eventually goes green. Not because delivery improved — because reporting amber costs a conversation and reporting green costs nothing.
So things drift green, and then one week they go red without ever passing through amber, which is the tell. Amber is the honest state and it is the one the system has quietly priced out.
The colour is the output, not the input
A rating on its own carries almost no information. "Amber" could mean a dependency slipped, the scope grew, someone left, or the person filling in the form was in a bad mood on Thursday. The reader has to ask, so the status board does not save the conversation it was built to save.
What actually transfers is three sentences:
- What changed since last time. Not what happened — what is different.
- What is now different from the plan. The comparison against the promise, which is the only thing that makes "on track" a claim rather than a feeling.
- What decision or help is needed. The one that converts a report into an action, and the one most formats omit entirely.
Ask for those and the colour becomes a summary of them rather than a substitute for them. It also becomes honest as a side effect: it is easy to write "green" and hard to write "green" directly above "the security review has not been scheduled and we need it by the 14th".
Why amber gets skipped
Worth being precise about the mechanism, because it is not laziness.
Amber invites attention. Attention arrives as questions, a meeting, and sometimes an offer of help that costs more to absorb than the problem did. A team that reports amber early and gets a week of scrutiny learns to report amber late. This is rational behaviour and no amount of encouragement changes it.
What changes it is making amber cheap: a status that says "amber, waiting on a confirmation, no help needed yet" should produce no meeting at all. If the format has a field for what is needed, and "nothing yet" is a valid answer, then amber stops being a summons.
Cadence: less often, with more in it
Weekly status on a twelve-week commitment produces eleven reports saying "on track" and one saying "not". The eleven are not free — they consume the attention that should have been available for the one.
Report when something changes, plus a low-frequency heartbeat so silence is distinguishable from neglect. What you want to detect is not the current colour but the derivative: a demand that was green for six weeks and is now amber is far more interesting than one that has been amber throughout, and a board that only shows current state hides exactly that.
The same applies to confidence. A drop in confidence is usually the earliest honest signal there is — earlier than a date moving, because the person closest to the work feels it before they can prove it.
And the last update is not the close: what it takes for work to count as complete is a separate question with a separate answer.
A written check-in is also what lets the status meeting shrink to thirty minutes of decisions.
Who it is for
Status reporting collapses when nobody can say who reads it. If the answer is "leadership, in case they ask", the format optimises for looking fine and the information content goes to zero.
The useful framing is narrower: this update exists so that someone can make a decision earlier than they otherwise would. That immediately tells you what belongs in it — the change, the deviation, the ask — and what does not, which is most of what usually goes in.
How DeliverySheet does it
The check-in opens lean and deliberately: one question — "is delivery still on track?" — with on track / at risk / off track, then what changed, then an optional "what decision or help is needed". Next milestone, risk changes, confidence and the date sit behind an Advanced section, because a 30-second update that gets written beats a thorough one that does not.
The health view reads the derivative rather than the current colour: it surfaces a confidence that has dropped since the previous check-in, an update that has gone stale, and contradictions — a green rating sitting above overdue work or an unresolved high-severity risk. Flagging that a check-in disagrees with itself is the part that keeps the colour meaning something.
And a check-in can mark that it reflects a change to the committed baseline, which routes into a re-baseline rather than letting the plan drift silently — the same machinery behind naming which thing slips .
Defined in the glossary: RAG status
I'm Tan Gravam. I build DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.
$189/month per workspace, unlimited members. 7-day free trial — card required, cancel before it ends and you're not charged. I answer the support email myself.
Not ready for that? Play eight rounds of Request or topic? It takes two minutes and needs no sign-up.
More on after the commitment
Read the overview: After the commitment: tracking, closing and learning →
- Close the quarter by counting the exceptions
Three counts close a quarter: honest closes, slips with named differences, and early-commitment exceptions. Each changes next quarter's line.
- How to tell stakeholders a project is late
When to tell stakeholders a project is delayed, the four parts of the message, and five project delay emails to copy, from a new date to a stop.
- A change request process that fits on one page
A lightweight change request process: what a request must state, who decides, and when to re-baseline with a reason. With a copyable checklist.