A RAG status uses the colour of traffic lights (Red, Amber, Green) to signal project status. This is a pretty standard tool in the project manager’s tool kit but some folk don’t think RAG is helpful in an Agile context. Personally I use RAG status for risks and issues and have redefined what they mean. In my scheme Red becomes a call for help.
My RAG Status
Real world traffic lights are very clear calls to action and I think the RAG status flags should also be very clear. The audience for RAG is usually a controlling group (e.g. programme board) so I want it very clear whether or not I need them to do something. I use Red for that.
If a risk or issue goes Red in my project then I need help to resolve it. I’m admitting I can’t mitigate against the risk or resolve the issue with the resources currently at my disposal.
I use Amber to highlight something that might go Red. I don’t need help with it yet but there is a good chance it will and I want the controlling group know about it before that happens.
|Red||Escalated – need help to resolve||Work with controlling group to resolve the risk/issue|
|Amber||Can handle within team but flagging potential escalation||Warn the controlling group that a risk/issue might need their help|
|Green||Can handle within team||None|
But my usage is not the convention. Personally I don’t find the normal usage of RAG terribly useful.
RAG traffic lights are common in project reporting. Although there is general agreement on what Green means different organisations have different ways of defining Amber and Red. Here are a few examples:
Complete an Exception Report
Imperial College: ICT Project Process – RAG status definition is the most fulsome of the schemes I looked at. Quite bureaucratic really, “Exception Reports” and all that. However it is also probably the closest to my use of RAG because Amber means you have to “raise awareness to the project board”.
|Red||The project requires remedial action to achieve objectives
The timeline/cost/objectives are at risk
|Raise to the Project Board and complete an Exception Report to explain or an RFC to gain approval for budget, time or scope changes.|
|Amber||The project has a problem but action is being taken to resolve this OR a potential problem has been identified and no action may be taken at this time but it is being carefully monitored
The timeline/cost/objectives may be at risk
|Raise awareness to the Project Board. The Project Director will determine if an Exception Report is necessary.|
|Green||The project is on target to succeed
The timeline/cost/objectives are within plan
High Medium and Low Risk
One scheme – from Business Docs UK: RAG Status – Communicate Project Status! – is to treat Red Amber and Green as code for High Medium and Low. Somehow I don’t think this mapping adds much value.
|Red||High Risk and/or serious project issues are in motion||–|
iWise2: RAG Status – Focus on progress and prioritise issues quickly with Red, Amber, Green is interesting because they add Blue to the RAG. I don’t like this scheme because there are no clear calls to action and no distinction between classes of risk.
Risks are a part and parcel of all projects and need management. I don’t like this scheme because it doesn’t distinguish between risks that are not a concern and risks that are out of control. Both will be Amber.
|Red||A problem needs serious attention and action now||–|
|Amber||Not complete, in progress, a risk but not an issue yet|
|Green||On track, in progress and complete to plan, no issues||–|
|Blue||Completed, finished and handed over to another responsibility|
RG rather than RAG
Johanna Rothman doesn’t like to use RAG for project status because there is usually no clear call to action (I completely agree). But she gives a couple of examples were teams use Red and Green lights. She likes these examples because of the call to action of the Red light and the absence of Amber. But, from my perspective, leaving out the Amber means the controlling group lack the appropriate level of forewarning that something nasty might come their way.