RAG Status: a tool not a weapon

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