RAG is not Black and White

Most of us are familiar with the technique of describing the status of a project by using the three traffic light colours: red, amber and green. The RAG Status.   But Although the use of RAG is ubiquitous, the way it’s calculated and the meaning of the colours is not. Nor is the intended impact and likely reaction from senior leadership.

In fact, were you to cut a portfolio of projects from Company A and paste them into Company B and then reassess the RAG for each project using the prevailing method – things could get messy.

At a simplistic level, of course, green indicates that everything is ok, amber indicates that there are concerns and red indicates that something’s gone wrong.

Using a RAG status is a quick and visual way of indicating the current status of things.

So long as everyone interprets the colours the same way.

Some organisations use complex algorithms to calculate a RAG status, based on underlying data from the project in question, often calculated automatically by some sort of Portfolio Management System.

Others use a threshold based approach: a project which is x% over a pre-stated threshold is Amber, y% over is Red, etc..

I’ve known some companies that refer to a “RAG status”, but use yellow instead of amber.  A RYG status, more accurately.

Some other companies I’ve worked for use blue too.  The blue representing “nearly red”.  A RBAG status.

However a company uses colours to represent the status of a project, the critical thing is that everyone understands what the colours represent, that the method of “calculation” is consistent throughout the organisation (across borders, geographies and timezones), and that the leadership response to each is also consistent.

You wouldn’t want, for example, one director to dismiss a Red status as irrelevant and unimportant and another to go into DEFCON 3.

I know one organisation, for example, where the US parent company has a fixed threshold approach to calculating a RYG status, and their European counterparts use a different system

On the US side, the financial threshold for going into a Red status is set at 10% over budget.  In other words, if a change initiative is 0 to 9% over budget it is Yellow, 10% and over it is Red.

On the European side, however, a project goes into a Red status if the project manager thinks it should, and the Sponsor agrees – all based on a rational consideration of the current state of play and underlying metrics of the project.

In this case, the definitions in use were (I paraphrase):

  • Green – Everything is cool and groovy, hunky dory, no issues, going as planned.
  • Amber – Although we’ve gone off piste, we have spotted a way to get back on course. Things are in hand. Leadership is comfortable. Remain alert and vigilant.
  • Red – We’re off piste, and have not yet got a plan to get back on course. All hands on deck, look at options, decide best approach forward, regroup, cancel lunch.

There is nothing wrong per se with either approach. Or to put it another way, both are equally valid.

The problem is one of interpretation. Of reaction. Of intent.

Consider a project in which the year-to-date cost is 10% over budget. Let’s say that according to the automatic threshold approach, it’s Red. And let’s also say that we knew we were going to go over budget at this point due to various cash flow factors and risk mitigation strategies we have had to deploy. Sponsor is comfortable. Senior leaders are comfortable. Project Manager is comfortable. Finance is comfortable.

The point is, we knew we would go over budget by 10% for a short period. You could say – in a sense – don’t all shout at once – we even planned to go over budget for a short period of time.

Are we really Red then?

The system says Red because we crossed a threshold. But what are we going to do about it? What is our intent?

Nothing, because things will right themselves next month?

The danger is that we end up spending lots of time and energy explaining that we’re not really Red, and things will fall back into line, and it’s just a cash flow issue, and we knew it would happen, etc.

So in effect, ignore the Red status for this month.

That sounds all wrong.

Now consider the same scenario, except that the RAG status is agreed manually between the project leadership and the Sponsor.

“Are we Red?,” asks the Sponsor.

“No,” says the Project Manager.

“Why not?”

“We’re off-piste for sure, but we knew we would be, and we know it’s just a cash flow issue which will resolve itself next month. There is no other action to take. We have a plan. Let’s monitor things until it rights itself.”

“Amber then?,” suggests the Sponsor.

“Agreed.”

The difference here is that the RAG status has been discussed by the project leadership and the Sponsor, and they have agreed a considered approach to leave it Amber.

And how do we make sure that there is consistency across other teams, projects, programmes, Sponsors? We make sure that the PMO acts as the Conscience of the business. The normaliser. The referee. The quality assurance team.

This approach provides a framework for a project team and sponsor to discuss the current state of play of a project, to consider all of the underlying issues and metrics, and to come to a considered opinion.

RAG is not black and white. There are exceptions, there are nearlys, there “yes, buts”.

Actively deciding that a project is Red carries much more weight than an automatic calculation.

Why?

Because you’ll know we mean it. And if it means preparing for DEFCON 3, then prepare for DEFCON 3.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: