When using a RAG (Red, Amber, Green) scoring system on control charts for cost and schedule, would you score a variance from green to amber and then to red the further you move away from a zero variance, no matter if it is favorable or unfavorable?

For example: if your baseline for costs was $1,000 and your RAG scoring was green for 0 to 5%, amber for 6% to 8%, red for 9% and greater, would you score red for both a variance of $110 either favorable (under running) or unfavorable (overrun)?

What about if you're scoring revenue? It seems counter-intuitive to report a favorable variance in red if you exceed your plan by x points; however, you are still that far away from plan. Would using "red" in the score to draw attention to the variance, maybe to exploit and enhance whatever is going right, be appropriate? Or does the red score just indicate something bad?

3 Answers 3


In my experience, most projects don't score an underspend as "Red" or "Amber", as long as these are genuine savings. However, if they are variations due to timing, then it may be an issue for the project to underspend this year and overspend by the same amount next year. A couple of places where I have worked have set next year's budgets in September or October based on forecasts, and the organisation's accounting policies have explicitly excluded any opportunities to roll over any variations (underspends or overspends) from the current year into the next year. This was acknowledged to be an issue for projects, but it didn't change the policy.

My preference would be to report all variations according to their absolute values, as long as your stakeholders understand and agree with this. Red in this situation doesn't necessarily mean "bad" - it just means a big variation, which could, in some circumstances, be bad. This is similar to what I was taught within Price 2, where risks are defined as any potential variation, whether good or bad. When challenged, the instructor explained that variations are evidence of projects not progressing as planned, so steps may need to be taken to manage the variation. In some cases that might be seeking extra money, whereas in the case of an underspend it could be having to give money back to the money people. In either case, it's a change that needs to be managed and is therefore extra work for the project!

As someone else has said, context is king.


The advantage of the Red, Amber, Green scoring lies in the fact that it's simple, well known, and intuitive. Everyone knows how a traffic light looks like and how it works. Green means "safe", "all good", "go". Red means "unsafe", "not good", "stop".

So intuitively, green means something good, red means something bad. If you want to signal positive things with Red, then you are asking for trouble. It's counter-intuitive at first, which is one problem, but then - and this is the biggest problem - with time people learn that red can also be a good thing. It's like changing the meaning of traffic lights to mean that you can also drive through the intersection on Red.

If seems you want to communicate some extra information together with the colors of the status by finding a way to use only the colors themselves. The Red, Amber, Green is a simple system, but in its simplicity also lies its limitation. If you want to draw attention to the variance in each indicator, just add another information to your status. Keep the meaning of the colors and pair them with another indicator/status/KPI to enhance the color (e.g. Green for good + something that says "OKish" or "really good"; Red for bad + something that says "No need to panic yet" or "Head for the hills").


Context is king.

I'd suggest a slightly different interpretation. Yellow means that this situation/factor/variable should be monitored, and Red means that action should be taken.

A large variance in revenue probably requires action. I'd be comfortable coding it red. Much depends on the context/audience. I'm not sure why project team members/SME/individual contributors would care about a variation in revenue. Variations in revenue are generally of interest to strategic players. A large variance in revenue means that you didn't estimate revenue correctly, and that you don't understand your revenue model correctly. The next period's revenue will be highly variable. +11 this quarter might mean -11 next quarter (a 22% drop). Large variations in revenue pose a risk to the project.

Fortunately, risk management can help us to manage that risk.

  • Use everything you know about quality measurement to improve your revenue estimates; expand that confidence interval until 95% of all revenue measurements are within the estimate and no more than 2 successive measurements exceed the interval.

  • Develop plans based on possible outcomes:

  • What will you do if the next period's revenue is 22% less than this period's? What impact will that have on your project? How much financial reserve do you have? Can you float that? Can you transfer the risk (negotiate good deals on a loan?)

  • What will you do if the next period's revenue is another 11% jump? For some domains holding onto cash can generate legal or regulatory problems. In every domain I don't want to be holding that revenue in cash. That is lost opportunity - it is the literal definition of leaving cash on the table.

  • Large variations in revenue strongly suggest that you don't understand your market, and that you've made poor investment decisions. Should you change prices? Increase capacity? Invest heavily in quality (the Amazon model)? Give everyone a bonus? (not if next period is a 22% drop).

Edge case; "large variance" implies that you have a reasonable confidence in your projected revenue. If this is an initial estimate, or an estimate based on low fidelity numbers then "large" had better be a very large number. In my domains, an 80% error at the beginning of the project is considered to be "green", because it relies on so many unknowns. If your confidence interval is 10%, then you're talking a fairly mature project.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.