RAG status: using the tool the best way

I am really grateful to everyone who contacted me with thoughts and comments after the first blog on RAG status, a tool not a weapon. I have found out some interesting things about how organisations use RAG, and about intra-company (and sometimes intra-project) variations in RAG interpretation. I am going to mention three things in this blog – RAG status variants, using RAG as a predictive tool, and how to avoid RAG status reporting issues. This is probably not a blog for the purist as we look at uses of RAG status that some might consider to be a deviation from its true purpose.

I’ll start with some RAG status variants that I learned about, in alphabetical order:

BAG – Blue is used instead of Red because red has negative and alarmist connotations
BRAG – Black is added to denote a showstopping/catastrophic event, e.g. a supplier going out of business
PRAG – Purple indicates a situation that is worse than red, but only applies for a short period, e.g. a disaster recovery situation but things will return to normal
RAGB – Blue is included for activities that have been successfully completed
RAGG – Grey is added to indicate where there is an information gap that prevents that status being correctly assessed
RAYG – Yellow is added between amber and green where something is, and I quote, ‘not quite green and not quite amber’

I will add no further comment on these other than I think there are some useful ideas in there (although changing red to blue will not change the fact that the project is in difficulty).

When I wrote the first blog, it was focused on the fact that RAG is a reporting tool that informs on the status of key project activities in an accurate way. However, I’ve also been told of circumstances where RAG usage goes beyond reporting the current status and is used as a predictor of future status, e.g. an ‘amber’ RAG status doesn’t meant that the workstream is ‘amber’ now, but that it will be by the next status report. Confused? I was.

I think I understand it. Most of us will know that feeling where, on the face of it, the status might be ‘green’ but there are so many outstanding issues that it will not be long before it slips to ‘amber’. Where the project manager, using their experience, is confident that this is the case then they will report an ‘amber’ RAG status in advance of it happening to highlight the need for corrective measures to be taken.

This predictive use feels like an overlap with both the risk log and the horizon-scanning activities that happen on projects, both of which identify potential problems before they arise. Perhaps using the RAG status to highlight a future problem creates an immediacy that results in speedier action being taken. Or maybe it is just a simpler way to integrate future risks into the project reporting or to generate the necessary level of senior stakeholder attention. So while I can see that there may be reasons to do this, I think project tools are already available that achieve the same outcomes.

This ties nicely back into the importance of defining RAG status to prevent reporting issues. There is general agreement that it is normal for the definition of RAG status to vary between projects. The problems arise where the status has not been defined or is not used consistently, either at a project or an organisational level. If the RAG means different things to each project workstream then it is difficult for the Project Board or Steering Committee to get an accurate sense of the project status. This can be equally true where organisation-level change boards are trying to assess status across a portfolio of projects.

To avoid reporting issues not only does the RAG need to be clearly defined, it must be communicated and consistently applied. It must also be allowed to evolve. As a project moves through the life cycle, the initial RAG definition may need to change. This may be as simple as positive or negative changes to the budget meaning that the initial RAG status thresholds need amendment. Project teams also need to recognise when the initial RAG definition just is not working, e.g. you have defined ’green’ so rigidly that anything other than perfection is ‘amber’, even though everything is going fine. At the end of the day, the RAG status must be useful and it must work for the project so don’t be afraid to change it (and communicate that change).

Overall, I can see that the addition of categories may be helpful in some instances, but I am cautious about using it to stray beyond the purposes of status reporting and overlapping with other project tools. I would place more emphasis on the definition at a project or organisational level; on the role of the project manager in ensuring that it is used consistently; and on monitoring and evolving the definition throughout the project to ensure it maintains optimal usefulness.

And I still think it is a great tool.

Further resources

_{Vlad Zymovin/Shutterstock.com}