One of the skills of project management is monitoring and controlling your project to ensure it delivers on time, on budget and to the required scope – and any other quality measures that your project customer or sponsor has set.
RAG status is something that comes up time and time again when talking about status of business projects.
In project management, RAG is an acronym that stands for Red, Amber, Green and relates to project status. In the USA I have seen this as Red, Yellow, Green (RYG), so you may see that acronym too.
What Does RAG Status Mean?
RAG is a shorthand for identifying the project status, but there has to be something substantive behind the shorthand.
Many companies make up their own definitions and tolerances for what makes a project ‘Red’ so if you have these already, work within their boundaries. If you are setting up RAG for your project, or within your PMO, then think about what you want the statuses to mean for you.
A fast, easy to understand breakdown is:
- Green: Project progressing to plan
- Amber: Project may need assistance in the future; currently handling within the project team but management team: be aware
- Red: Escalation: project team need help to resolve a problem
You can add more granularity to this, for example:
- Green: Project is within tolerance
- Amber: Project budget or timescale is +/- 10%. Scope is within tolerance
- Red: Project budget and timescale is +/- 10% or project budget or project timescale is +/- 15% or scope is carrying unplanned changes
In fact, you can make up whatever categorization makes sense to your project. I have seen some quite complicated matrices that specify targets, tolerances and breaches for different sizes and categories of project. You can make it as complicated as you want (or as simple). However, everyone agrees that Green means things are going to plan – it’s only Red and Amber that you’ll have to define yourself or use one of the many examples online.
Personally, I don’t feel it matters what definitions and categorizations you use, as long as everyone knows what it means. For that reason, you’ll find that the simpler it is, the easier it is.
What Is RAG Used For?
RAG status can be applied to:
- The whole project
- A workstream or strand of the project
- A risk (or project risk exposure)
- An issue (or cumulative issues on the project)
- A change
- Anything, really!
The easiest way is to allocate a RAG status to the whole project, but on larger projects or in complex portfolios you might want to break it down and apply a RAG status to each element such as budget, scope, resourcing or timescale. These can then be aggregated up to give you a project-level status.
Working Out RAG
It’s actually quite easy to work out the RAG status of your project. Once your definitions are set, all you have to do is follow them.
Experienced project managers will also have a ‘gut feel’ for how things are going. Sometimes you just know that your project is going sideways and someone outside your immediate project team needs to know about it.
For timescales, check Schedule Reader to see how far adrift your original dates are from your actuals. That will give you an idea of whether you are still in the tolerance for your project or not. Check your budget tracker spreadsheet for how much over budget you are forecast to be. You can also check, if you don’t already know, if there are unplanned changes or major risks or issues that would cause a problem and that your sponsor and management team ought to know about. All of this informs the status of your project.
Sometimes you might see the acronym BRAG. The ‘B’ stands for Blue. Blue represents a project (or task within a project) that is completed.
This can be handy when you are looking at a list of projects. It’s clearer to see what projects are in need of management attention if you can mentally filter out the ones that are already completed. They might drop off the report list next month, but it’s important that they are marked as ‘you don’t need to worry about this anymore’ when they do appear on a status or priority list.
The Risks With RAG
There is one major issue with RAG and that it has no clear call to action. In other words, just saying a project is Red doesn’t automatically mean you sponsor leaps into action to resolve the problem. You’re going to have to spell out in more detail exactly what you expect from them, and then make sure they do it.
Of course, some project sponsors are totally engaged and will work all this out for themselves, but generally “raising awareness” isn’t enough: you need some action taking otherwise you can’t keep the project moving forward.
There’s another, smaller, concern and that’s the fact that RAG doesn’t translate particularly well to Agile environments. I don’t think that’s a major showstopper. You can use RAG if it suits you for project monitoring and control. If it doesn’t – and Agile methods have plenty of other ways to ensure project status is monitored accurately day by day, like standups and burndown charts – the don’t use it. Simple!
Despite the limitations, I think RAG is a very useful status tool, quickly offering everyone a glimpse at where the project is right now.