Status by rule.

The colour nobody chose

I have sat through more status meetings than I care to count in which the longest discussion of the afternoon was not about the programme at all. It was about whether a line should be amber or red.

Everyone in the room had the same facts. The schedule had slipped again, the design was behind, and the contractor’s explanation had a familiar ring to it. Yet the conversation was not about what to do. It was about what colour to call it. The project manager wanted amber, because red would bring the board down on the team. The sponsor wanted amber, because red would bring the board down on the sponsor. Amber it was. Nobody had lied, and the board was told almost nothing.

That is the problem with RAG status in one scene. It is not that the colours are poorly defined. It is that the colour is chosen, every period, by the people with the most to lose from choosing honestly.

1. What a RAG actually measures

A RAG rating looks like data. It sits in a cell on a dashboard, it rolls up neatly, and it can be counted. But it is not a measurement. It is an opinion about a measurement, offered by the person closest to the work, and then reported to the board as though it were fact.

Most organisations know this, which is why they write criteria. Red if the variance is significant. Amber if it is manageable. Green if it is on track. Read those definitions closely and every one of them hands the choice straight back to the reporter. Significant to whom? Manageable by when? Two competent managers looking at the same facts will often choose different colours, and both can defend the choice.

A single colour is also asked to do too much. It is meant to say where the project is, where it is heading, and how confident the reporter feels about both. It cannot carry all three, so in practice it carries whichever one the reporter finds most comfortable.

2. Why everything turns amber

Give people a three-position scale with consequences attached to either end and they will settle in the middle. Green invites someone to ask whether you are being optimistic. Red invites intervention, extra reporting and an uncomfortable meeting. Amber invites neither. It is the safest place on the dashboard, and over time a programme’s reporting migrates towards it.

A board pack in which most lines are amber is telling the board very little. Worse, it is hiding the lines that matter among the lines that do not. The project that is quietly heading for a twelve-month overrun looks the same as the project with a minor procurement delay.

Amber is not a status. It is a place to wait.

Then there is the familiar watermelon: green on the outside, red within. The underlying measures decline for several periods while the colour holds, because no one wants to be the person who turned it. When it finally goes red, the deterioration is history. I made a similar point in The owner’s seat: by the time the numbers turn red, the failure has already happened.

3. Move the judgement; do not pretend to remove it

The usual response is to write better colour definitions. That does not work, because it leaves the choice where it was. The remedy is to stop asking the reporter for the colour at all.

I want to be careful here, because there is a tempting overclaim. No status mechanism is entirely objective. Somebody has to decide how much tolerance a project is given, what counts as evidence of progress, and who checks it. Those are judgements, and they will remain judgements.

The difference is when they are made. Under RAG, the judgement is made every month, by the person reporting, at the moment they have the strongest interest in the answer. Under the approach I set out below, the judgement is made once, at the start, in writing, before anyone has bad news to manage. After that, the status follows from the numbers. Nobody is asked how they feel about it.

I call this status by rule.

4. Four numbers instead of a colour

Every project reports the same four measures every period. Each is a number, and each can be checked against a source record by someone who was not in the room.

Tolerance consumed. For time, cost and contingency, how much of the tolerance delegated by the board has been used to date, and how much is forecast to be used by completion, as a percentage. This is the anchor. It answers the only question a board really needs answered: how close is this project to needing a decision above its own level? On time, it must be measured against the locked sanction baseline, not the latest accepted programme, or contractual changes will quietly absorb the delay.

Evidence of progress. Of the gate criteria due by now, how many have been evidenced and verified by someone other than the author. In the early phases of a programme, where most output is design and consent documents, this replaces percent complete, which is the most negotiable number in project controls. Thirty-four of fifty-one is either true or it is not.

Say/do. Of the actions the team committed to last period, how many were done. This is the single best measure I know of whether a team’s forecasts can be believed. It needs no interpretation and it is very hard to spin.

Forecast stability. How many times the completion forecast has moved later in the last three periods, and by how much in total. A forecast that slips a fortnight every month is a buried problem announcing itself, one reasonable adjustment at a time.

The first two measure the project. The second two measure the reporting. That is deliberate, because optimism rarely sits in the facts. It sits in how the facts are presented.

5. Four states, set by rule

From those numbers, each project falls into one of four states. The reporter does not choose. The rules do, in a fixed order.

Breached means actual consumption has passed 100% of tolerance on any dimension. Escalation to the next tier is automatic, and there is no discussion of whether it is really breached. In recovery means an approved recovery plan exists and is forecast to hold within its own tolerances. Forecast breach means the forecast passes 100% on any dimension, or the trend over the last three periods crosses it within three periods; the projected breach date is reported. Within tolerance means none of the above.

Two refinements matter more than they look. A project leaves forecast breach only after two consecutive good periods, because one good month is not a recovery. And a project in recovery continues to show its movement against the original sanction baseline, so a recovery plan cannot be used to reset the record.

The reporter supplies the numbers. The state follows from them.

6. Making bad news rise on its own

The test of any reporting system is not whether it can show bad news. It is whether bad news reaches the board without someone having to volunteer it. Four features do most of the work.

The board pack is sorted worst first, by forecast tolerance consumed. The project in most trouble is on page one, every time. Nothing sits quietly on page fourteen.

Overrides are allowed, but signed. A project manager who believes the rule has produced the wrong answer may say so, and sometimes they will be right. But the calculated state still shows, with the override, the reason and the name beside it, and a second consecutive override goes to the board. Judgement is welcome; anonymous judgement is not.

Missing data is treated as bad data. A measure not submitted by the cut-off is ranked as forecast breach until it arrives. Under RAG, silence is often the safest option available. Under status by rule, it is the least safe.

Finally, history is kept. Every period’s figures are retained, so trends are calculated from the record rather than recalled in a meeting, and a forecast cannot be moved without the previous one remaining visible.

7. What the board actually sees

Take two projects in the same portfolio. The figures are illustrative.

Under RAG, both might reasonably be reported amber. One has a note about consultant resourcing; the other has a note about a late design review. The board nods, and moves on.

Under status by rule, the first reads: forecast breach, projected in March. Time tolerance 55% used and forecast at 110%. Twenty-two of forty-one gate criteria evidenced. Five of nine commitments delivered. Forecast moved three times in three periods, seven weeks in total. The second reads: within tolerance, forecast at 75%, thirty-four of thirty-eight criteria evidenced, eight of nine commitments delivered, no forecast movement.

Nobody needs to explain to that board which project deserves its time. The question writes itself, and it is asked in March rather than in August.

Retiring the traffic lights

None of this requires new systems. The four measures use records most programmes already keep, or should: a locked baseline, a cost report, a risk register, a gate criteria register and last month’s report. What it does require is three uncomfortable decisions taken early. The board must delegate tolerances in writing and challenge them when it sets them, not when they are breached. Verification must sit outside the team being verified. And commitments must be reviewed against the programme, so that a team cannot protect its say/do ratio by promising very little.

I would run both systems side by side for one period and show the board the differences. In my experience, the differences are the argument. Then retire the colours.

This is the companion to Predictive reporting, not post-mortem reporting. That piece is about what reporting should look at. This one is about who should decide what it says.

RAG status persists because it is comfortable, familiar and cheap. It is all three. It is also the reason so many boards learn about their programme’s problems last. Reporting should tell a board the truth early. A system that lets the reporter choose the answer was never going to do that.