Making status indicators meaningful : Use your RAG wisely!

RAG indicators, or Red/Amber/Green traffic lights, can be tricky to use. They are a great visual aid in project status reports that will provide an instant understanding of how well (green) or badly (red) the project is going.  They can also be over-engineered, complicated to understand and sometimes even misleading. The RAG status is a traffic light and should be as clear as the one you see when driving!  The last thing you want is this:

Common mistakes with RAG indicators are:

• having too many traffic lights and making it impossible for the reader to quickly work out if the project is going well or not.
• abusing a colour: painting the report red screams of panic, having green lights all over is great but be careful as it may raise suspicion (just be sure it is all indeed green), and the non-committal amber tells people that everything is so-so and doesn’t help too much with confidence (if you are using amber everywhere, what are you telling your reader; that everything is at risk or that everything is under control?).
• letting people interpret loosely the meaning of an indicator: be clear upfront as to what they mean (add a legend if necessary) and substantiate the colour with a simple statement saying what you’re doing about it (especially if amber or red).

Keep it clear and simple:

• Make status indicators clear: this is the definition I communicate to my audiences when using a RAG:

* GREEN: the project is progressing according to plan = we are delivering on time/scope/budget.

* AMBER: there are issues and/or risks that will impact the project if not fixed = we are at risk of not delivering on time/scope/budget.

* RED: there are issues and/or risks that are impacting the project right now = we are not delivering on time/scope/budget.

• Limit the number of lights to 4 or 5 topics representing your overall project.  It could be just tracking the 3 almighty axis of project management: Schedule, Budget and Scope. Or on a technology project, you could use workstreams to report on such as: Process & Training, Application Development, Data Migration, Deployment.
• Put an overall indicator for the project – as the PM it is your responsibility – and your right!- to make a call on how the overall project is going. It also helps binding the team together and avoid silos of responsibilites (if you report only by workstreams for example, those will only care about “their” indicator).
• Report on the progress trend so your reader knows whether this is on an-going status that’s not changing, or if there has been a major change since the last status point. You can either use “last week/this week” or a symbol (up, down or bidirectional arrows) to show trend.

Here is an example: