Amber is where a project goes when nobody wants to say red. Here is how to make the status mean something.
Look at a portfolio report that has been running for a year and you will usually find the same thing: a column of amber, a few greens, and almost no reds.
Amber is not a status. It is a negotiation outcome. It is where a project goes when the delivery lead thinks it is red, the sponsor does not want it reported as red, and amber is the thing they can both sign.
The result is a report where the colour carries no information. Everybody knows this, which is why the first question in most portfolio reviews is "but what is actually going on with this one" — the report having failed at its only job.
The root cause is that the status is declared. Someone chooses it, and a person choosing a colour that reflects on their own delivery will choose optimistically. Not dishonestly — optimistically, which is worse because it is sincere.
The fix is to derive it. The status is calculated from things that are harder to argue with:
Then red, amber and green are outputs, not opinions. A project is red because two milestones have slipped and 80% of contingency is gone, and the conversation moves to what to do rather than what colour it is.
Keep the ability to override — sometimes the rules are wrong. But make the override visible: show the derived status, the reported status, and the name of whoever changed it. In practice this removes almost all of the optimism, not because anyone is challenged but because writing your name next to a change is a different act from picking a colour.
The thresholds have to be agreed when nobody is red, because the moment a specific project is at issue, the argument is about that project rather than about the rule.
A serviceable default:
Notice that on this definition, amber and red are both asks. Amber says "I need something from my sponsor". Red says "I need something from the board". A status that asks for nothing is green, and a project that has been amber for four months without an ask is mis-reported by its own definition.
When a project sits at amber for months, one of three things is true:
The intervention was never actually requested. Amber was used to signal discomfort rather than to ask for something. Fix: require every non-green status to name what is needed and from whom. A blank in that field forces the status back to green, which is uncomfortable exactly once.
The intervention was requested and refused. Then it is red — the project will miss its commitment and nobody has agreed to fix it. Amber is being used to avoid recording a decision that was already made.
The baseline is wrong. The project is fine and being measured against a plan nobody believes. Re-baseline it, formally, with a record of why. A project measured against a dead plan produces noise every month for the rest of its life.
All three are resolvable. None of them resolves while the status is a colour someone picked.
A single colour is a snapshot and a snapshot hides the thing you most want to know.
Report the status and the direction: amber and improving is a different management problem from amber and deteriorating, and treating them the same is how a project arrives at red with no warning.
Two months of consecutive deterioration should force a conversation regardless of the current colour. A project going green → green → amber is more urgent than one that has been amber and stable since March, and a status-only report puts them in the same bucket.
The [Programme Dashboard](/products/programme-dashboard.html) derives RAG from milestones, contingency, spend and open issues, shows the derived and reported status side by side, and tracks the trend — with a worked example where the derived status disagrees with the reported one. £35.