Skip to content

RAG Status: a tool not a weapon

Added to your CPD log

View or edit this activity in your CPD log.

Go to My CPD
Only APM members have access to CPD features Become a member Already added to CPD log

View or edit this activity in your CPD log.

Go to My CPD
Added to your Saved Content Go to my Saved Content
David Hamilton RAG status.jpg

I have always been a big fan of a RAG status. The simple red/amber/green colour-coding gives both a snapshot of a project and highlights the areas to focus on. Whatever your role on a project or programme, the RAG status should quickly tell you what you need to know and the direction of travel, particularly if you track the trends. An amber status looks a lot more positive if it has been red for the previous two months.

I say ‘should’. My hesitation is because I have seen too many instances where the RAG status is treated as a weapon and not a tool. It is a weapon to beat and be beaten with; it is a window to the project that is best kept closed lest someone see in. There can be a nervousness in revealing the true status of a project if there might be negative (or work creating) repercussions.

Some years ago I was managing a project migrating data from an existing system to a new system and that new system was still in development. The development was delayed and the project deadline was going to be missed by around four months. You can’t migrate data on to a system that doesn’t exist so, for me, the project status had turned red. I dutifully reported this to the programme manager only to be told, ‘Say it’s amber – there’ll be too much trouble if we say it is red.’ Followed by an attempt to justify that it might actually be amber because maybe the new system could be finished on time if certain planets aligned and miracles happened.

Perhaps the programme manager was right. Staying below the radar at least gave us a slim chance of remediating the situation (although there was a greater risk that things would get worse). If we reported the project as red then we would be asked to investigate the cause of the delays, we would have deadlines set on the re-plan, and we might be pushed in to committing to unrealistic timescales. We would have created a lot of noise that distracted us from the job of delivering the project.

Yet, we were misrepresenting the project. We were also throwing away the opportunity to get senior level support. We may have been able to ask for additional resources or funding, or put contractual or financial pressure on the external supplier that was doing the development work. We were also, most likely, delaying the inevitable. Clawing back the delay was unlikely but, a bit like a politician, maybe we could break the news at a more opportune moment. The programme manager was also, quite clearly, trying to protect their own position.

It is easy to look at this situation and say ‘the status should have been reported accurately’, but I would like to add one more thing: culture. This particular organisation had a culture of blame and consequences. Non-delivering project managers would be shuffled on to other projects or, if they were contractors, removed altogether. Project delays would, as I am sure the programme manager knew, lead to an inquisition that would most likely delay things further. RAG status was most definitely used as a weapon to beat the project teams.

Set the rules early on

I have never forgotten that experience and I think about it a lot when I hear debates about RAG status. RAG status is a tool that needs to be used correctively and effectively, but the ‘rules’ need to be defined for each project and environment.

Firstly, the RAG criteria should be clearly defined for that particular project or programme. There is no standard definition that everyone uses. On a short project, amber may be any delay over two weeks; on a long project it may be four weeks. Amber may be a five per cent overspend or it may be 10 per cent. Define the criteria at the beginning, get input from everyone, write it down, and use it.

Secondly, understand and influence the culture that you are operating in. It is easy to say that RAG status is a tool, but it only works if everyone shares that view and acts accordingly. Think about how you view a red status. Are you comfortable putting it on a project status report? If you are on a project or programme board, how do you feel when you get a red status report? No one wants a project to be red, but how you react to it is key. I like transparency. I want to know that there is a problem as early as possible, I want to discuss it, and I want the team to work together to resolve it. I don’t want a surprise months down the line.

There are some nuances. If a project has slipped a little but we are confident it will be quickly back on track, then I am comfortable seeing a green status with an explanation of the position. Similarly, if there are unknowns that prevent the status being clearly defined but there is a plan to resolve that. There will also be circumstances when a project is behind schedule because there have been mistakes made. We would all prefer there not to be mistakes, but we are all human and it is better for a mistake to be owned and the team moved forward together.

A RAG status can be a tool or it can be a weapon, but I don’t believe it can be both. You can either use it as a mechanism for monitoring a project and resolving issues in a timely fashion, or you can use it as a way to politicise and scapegoat. If you opt for the former, then you are helping to create a culture of transparency, support, and delivery. If the latter, a culture of secrecy, blame, and overruns. If you try to be both then you create a culture of unpredictability and distrust.

If you work in, or come from, a culture where the RAG status is an instrument of fear then you may need to think about your own approach and reaction. You might even find it helpful to assess whether, in this regard, your own behaviours are red, amber, or green…

Read more from David in his blog ‘Why is escalation the last resort?’, in which he argues that
escalation should never be a threat or a punishment; it should be for the benefit of the organisation.

Red, amber, green, find out how to monitor the status of your projects in APM’s assurance assessment toolkit, free to download.


Image: Sandra Rodriguez/Shutterstock


Join the conversation!

Log in to post a comment, or create an account if you don't have one already.

  1. Ben Brownlee
    Ben Brownlee 04 August 2020, 02:04 PM

    Thanks for this article David. I find a RAG system with more granularity helpful to avoid some of the status issues you mention. At the BBC, for example, we use a five level status with clear definitions on each level against the areas of stakeholders, scope, cost, benefits, timescales, etc. This is so that sponsors, other stakeholders and PMs understand what's meant by an Amber/Red status and the areas that they need to address to bring the project or programme back to a more 'comfortable' or deliverable status.

  2. Tim Podesta
    Tim Podesta 05 August 2020, 12:15 PM

    An excellent article and the comment that a RAG with further granularity is well made. In looking at a refresh of the Measures for Assuring Projects MfAP document we are looking at the 1-10 scale which covers the RAG and a Blue for best in class exemplars. To further colour refine the 1-10 scale we have noted the IPA approach for red, red/amber, amber, amber/green and green. On David's point of RAG not being a threat I could not agree more. In fact the language used around having a project RAG score can be seen as threatening - I prefer to talk about a RAG level which implies more of a guide and opportunity for conversation and improvement.