Project RAG Status Conventions

Large-scale projects involving multiple streams of work (sub-projects) most of the time require a way of communicating the essence of progress updates without getting into the details. This is especially relevant if your audience is senior managers and above who have little time to appreciate the detail and want to have a birds-eye view of the status of say, the key high level milestones being delivered by the various work-streams.  It is often the responsibility of the Project/Program manager to feed this information in a format that is visually appealing and simple, this format is often referred to as a RAG status report:

R A G  =  Red  Amber  Green

This is a convention that project management use to summarise the status of work, largely around the following areas (which by the way is what I'm using currently in managing my own projects):

• Project / Task Status 
• Are we on track / target / according to plan? Green
• Are we on track but have highlighted risks that could impact the original plan? Amber
• Have we missed our original targets? Amber
• Are we so screwed that the project launch / completion is delayed? Red
• Issue Status
• Is this a top priority Showstopper Critical issue? Red
• Is this a medium priority issue that can wait a week to resolve? Amber
• Is the issue resolved and closed? Green
• Risks
• Does this risk rank in top 5 (High Probability/Impact)? Red
• Does this risk rank between 6-20 (Medium Probability/Impact)? Amber
• Is the risk for completeness, to be monitored but very low probability/Impact? Green

Generally the RAG status is meant to communicate at a high level to senior management the status of various streams of work. This is well known in the project management knowledge-base, although the actual usage and value of the RAG does vary.  Used correctly, the RAG report can be invaluable, I've seen RAG statuses used in real world projects not just for reporting purposes, but had triggered active management intervention in saving projects, rather than being used for pointing blame.  This is not always possible hence some people believe the RAG report doesn't make much sense because it triggers actions too late. However, if the convention is designed such that problems are anticipated in advance, and you have the support of the senior stakeholders, and you have frequent RAG updates, then it is in fact possible to provide valuable output from the RAG report...

As highlighted in my previous post on the importance of defining clear defect severity and priority definitions to prevent ambiguity and confusion amongst the entire project team, the RAG status conventions need to be defined and accepted in pretty much the same way.  The RAG status is a sensitive topic, depending on your audience, you have to be careful how the RAG is applied.

Here are a few example references:

• Definitions of RAG
• Possibly useful templates for download
• What the theory teaches you

Real-world Examples

Speaking from experience again, the RAG status can be a source of contention. Whatever you do, make sure you review the terms and conditions of the RAG conventions before publicising your report. Whether you're a vendor delivering software components to your customer, or you're just simply reporting to your executive committee for your project, care must be taken to ensure your interpretation of the status accurately reflects the status as you best understand it. Sometimes you have to temper the status, keeping an internal RAG for your internal management, and an external RAG to soften the message upwards to the key stakeholders.  

Some might argue this is insane, that we need to be transparent as possible and that the stakeholders must appreciate the detail otherwise what value is the report if we're hiding behind a wall of misrepresentation, putting up a farce??

I am very much a strong-willed, principle-minded person who stands pretty much up to the transparency argument, but I've been burnt in the past and had to succumb to the wishes of senior management NOT to be so transparent. As a vendor, you want to promote a sense of order, that you got things under control. Present a sense of calm, but in the background you're frantically trying to put out the fire - In other words, when reporting back to the customer Never Ever Report a Red RAG status!!  Unbelievable, I know, but it actually causes less headache and keeps the customer off your back!

But what if this is an internal project and your stakeholders are CEOs of your own company who are too busy to get involved with the detail? What if you've been clear and honest in the reporting, and are following the conventions to the letter and are reporting on the RAG convention as published? What if all the milestones are Red?? Should you hide this from the Exec Committee?? Again, my initial reaction is No, absolutely not.  But as a seasoned manager, one has to gauge the culture of the organisation, taking appropriate actions to manage both upwards and downwards.  Recently though, I did provide a report that was flagged as Red for pretty much the whole programme, this didn't go down so well.  I am now thinking about tempering the format yet again, to avoid the avalanche from above...

However, the purist in me really shares the same view as this post "Starting Green" where it proposes the RAG actually turned on its head: start off with Red and work your way towards green.  Really interesting experiment to try, but you have to have an open-minded organisation to be willing to give this a go! 

However, the reality is though, the RAG status is quite entrenched in classic management's mindset, how can a project start off in the Red? Didn't you do enough planning? We wouldn't have baselined the plan unless the project manager's had produced the initial baseline plans using best/worst/realistic estimates, so the projects/tasks must definitely start off in the Green state??

My Own Templates that Seem to Work

As always I'd like to share some of the stuff that have proved to work for me, and am currently using in my day-to-day activities (hopefully these are all self-explanatory):

Generic RAG for Internal - External Translation (Notice NO Red to External Players)
Download PDF

Example of Sub-Project RAG for Multiple Workstreams
Download PDF

Component Software Development per User Story / Work Package
Download PDF

Other Formats

I've seen other RAG / Traffic light formats been used before.  Typical SAP projects use the UP / Down / Right icon graphics to signal progress:

• Vertical Up Arrow - Amber
• Vertical Down Arrow -  Red
• Horizontal Green Arrow - Green (Amber is also used if tasks are on Target with some associate Risk)

There are also others that use primarily the colours to signify severity, but also include arrows to forecast/predict the status anticipated for the next update:

• Horizontal Arrow - Status anticipated to be the same next report
• Down Arrow - Status anticipated to be down next report (e.g. Amber next report from being Red this report)
• Up Arrow - Status anticipated to be up next report (e.g. Amber next report from being Green this report)