The problem with RAG statuses

In my work I come across a lot of attempts to explain in simple, one-word ways what the status of a piece of work – usually a project – really is. Much the most popular is the ‘traffic light’ system, or ‘RAG report’ as it’s known around the IT industry. It’s a great idea: simple, clear and apparently quiet unequivocal.

RAG reporting doesn’t really belong with Agile. In a mature Agile environment, short-range communication is more informal, and long-range reporting (e.g., to the very of the management hierarchy) isn’t needed, because people closer to the delivery are trusted to manage it effectively. If they need help or the people at the top are going to have their expectations disappointed then someone will already have told them.

But many teams work in less mature environments than that, and RAG reports continue to abound. So this brings me to a second problem with RAG reporting – in many organisations the very definition of Red, Amber and Green is usually, frankly, quite irrational.

However, there is surprisingly little on the web about this topic, so here are my current thoughts on defining red, amber and green. Nothing radical, but a little more consistent and logical than some of the ideas I have seen floated, especially in the companies I have worked in.

The first question that needs to be answered is what exactly ARG reports are for. If you look at most organisations’ RAG criteria, they are generally defined in terms of percentages or absolute numbers. For example, if a project budget looks like going over by 20%, it’s a Red. I don’t understand this approach, especially in a project-based organisation. One of the basic features of any intelligent project governance approach is to define project-specific tolerances t reflect the project-specific circumstances, known risks, and so on – not to treat them all as though they were peas in a pod.

So when project A is 20% over budget, that may indeed be disastrous, because its agreed budget tolerance is 10%. But project B, which has always been expected to need more re-financing at some point, has a tolerance of 30% (yes, such projects do exist), so overspending by 20% is not, by itself, cause for concern, and certainly not cause for trumpeting a disaster from the rooftops.

Who are RAG reports for?

So what – or, more precisely, who – are RAG reports for? First and foremost, they are not for everyone. They are for people who:

know the basic parameters of the project, including its tolerances for budget, delivery, and so on; and

are in some sense accountable for the project’s success, or at least need to understand its prospects for success.

In other words, RAG reports are aimed at people like the project board, quality managers, your PMO and so on.

So what do they need to know about a project that can be usefully and meaningfully communicated in something as simple as a single colour? Really it’s very simple: Do you (the report’s audience) need to do about this work?

A general definition of RAG statuses

So the message the RAG status needs to convey to the reader:

Green: Everything’s fine, you have more pressing things to worry about, go away.

Amber: I have problems, but I’m pretty sure I can fix them with what I have available. So nothing to actually worry about yet, but you probably need to keep an eye on what happens next.

Red: I have real problems and I can’t solve them with what I have available. YOU NEED TO DO SOMETHING.

Hence the RAG definitions I would recommend:

Green: All aspects of the project are fully under the PM’s control using only the project’s authorised plan & arrangements (e.g., budget, dependencies, resources, etc.).

Amber: Additional actions are required, but can be successfully managed within the project’s authorised capabilities & tolerances.

These are very general descriptions, of course, though none the worse for that. By being so general, they make it easier to achieve the consistency that is the basis of good quality management. But at the same time they are probably too abstract (I would not say vague) to be easily sued by busy project managers who aren’t much inclined to debate the finer subtleties of their project’s status.

More specifiic definitions

In addition to these high-level definitions, here are a few definitions of more detailed RAG statuses, as they relate to particular areas of project management. They are pretty useful tests of the overall status, but always bear in mind that the ultimate test is the above core definitions.

Finance

Green:

The project’s current budget is sufficient for the project, and is expected to remain so.

Amber:

There are outstanding changes that have yet to be budgeted for.

The PM does not maintain a record of expenditures.

Actual and forecast expenditure have not been reviewed/reconciled since the last report.

The authorised budget is currently being challenged.

The project is forecast to overspend (including tolerance) but there is a credible path to recovery.

Red:

The project is forecast to overspend (including tolerance) and there is no credible path to recovery.

Finances were Amber in the last report and no recovery plan has yet been agreed to return those particular problems to Green.

The project (or stage) has mobilised without budget authorisation.

The project is overspent (including tolerance).

Scope & governance

Green:

The authorised scope is correct, is authorised, meets stakeholder expectations, and is expected to remain so.

The current governance meets the project’s needs, is within our governance framework, and is expected to remain adequate.

Amber:

The project is not explicitly aligned with an authorised business goal and/or has moved from baseline scope.

There is at least on open & unauthorised change request (CR).

Cumulative impact of CRs exceeds original tolerance.

The authorised scope is forecast to become invalid (e.g., known change in business strategy) but there is a credible path to recovery.

Red:

The authorised scope is forecast to become invalid and there is no credible path to recovery.

Scope & Governance was Amber in the last report and no recovery plan has yet been agreed to return those particular problems to Green.

The project has started without an authorised scope.

There is no Project Sponsor/Senior supplier/Senior user on your project board.

The authorised scope is no longer valid.

Schedule

Green:

The currently authorised plan and arrangements are sufficient to assure the successful delivery of the project as a whole.

A critical path product/milestone has slipped/is forecast to slip, but there is a credible path to recovery.

Red:

A critical path product/milestone has slipped/is forecast to slip, without a credible path to recovery.

Schedule was Amber in the last report and no recovery plan has yet been agreed to return those particular problems to Green.

The project (or stage) has started without an approved plan.

Unfinished work that should already have been complete has yet to be rescheduled.

Work is underway that is not on the authorised plan.

Resources

Green:

The current stage has named, agreed resources and the resource requirements for the project as a whole are agreed.

Amber:

The plan includes over-committed resources.

The project lacks (or is forecast to lack) resources needed for successful delivery, but there is a credible path to recovery.

Red:

The project lacks (or is forecast to lack) resources needed for successful delivery, and there is no credible path to recovery.

Resources were Amber in the last report and no recovery plan has yet been agreed to return those particular problems to Green.

Plan contains tasks without predecessors or successors.

Plan contains tasks in the current stage without assigned resources.

The plan for the current stage is not fully resourced.

The plan for the project as a whole does not identify at least resource types.

Risks & issues

Green:

All known risks and issues can be managed within the current project arrangements & capabilities.

Amber:

At least one severe risk/issue is unlikely to be resolved as planned.

The project has escalated at least one risk.

Red:

The project has no effective risk/issue log.

Risks & Issues were Amber in the last report and no recovery plan has yet been agreed to return those particular problems to Green.

The risk/issue log has not been reviewed since the last report.

At least one severe risk/issue is unlikely to be resolved as planned.

Dependencies

Green:

All dependencies for the project as a whole have been formally defined and agreed.

Amber:

Not all dependencies for the project as a whole have been formally defined.

Not all dependencies for the project as a whole have been formally agreed on both sides.

An external dependency on the critical path has slipped (or is forecast to slip), but there is a credible path to recovery.

Red:

Dependencies were Amber in the last report and no recovery plan has yet been agreed to return those particular problems to Green.

An external dependency on the critical path has slipped (or is forecast to slip), and there is no credible path to recovery.

Not all dependencies for the current stage have been formally identified and agreed with the responsible managers.

The project plan does not identify all external dependencies and deliveries.

How many RAG statuses?

This multiplicity of criteria raises a key point: how many RAG statuses should your project have? Personally, I would strongly advocate using several RAG indicators at once. This not only gives your readers some idea of what questions they should be asking next, but they also allow organisations such as quality management or your PMO to compare reports from all their projects to identify hotspots and bottlenecks in the existing process that would perhaps benefit from a little company-wide improvement.

Exactly which areas you chose to RAG is up to you, of course. But what ever they are, they should be the areas you regard as the best indicators of project success and failure. That’s why I tend to start with the set above: in my experience, it is because dependencies and resourcing and all the rest tend to be the areas that drag a project under. You should chose your own, and test them every six months or so to see whether trends in individual RAG statuses did indeed predict success and failure. A few quick statistical tests using Excel is all you need (though what you use to replace unhelpful tests or unexplained failures is more speculative – a bit of an experiment).

Of course, this leaves a very important point unclear. If one particular facet of my work – the dependencies, for example, or the risks – is red but the rest are green, how do I calculate the overall status?

It is very tempting to fudge things here. If it’s mostly Green with just one Red, can’t we take a sort of average and call it Amber? No, we can’t – and the reason is simple. All the RAG criteria suggested above are individually capable of wrecking your project. Or if they aren’t they should not be on your list of questions. So if any of them is Red, the project as a whole is Red too.

RAGging your own expectations

One more detail. All the above RAGs are based on objective information (though no information in business is safe from manipulation). But there is one area of subjecting knowledge this leaves out: the manager’s own expectations of success. This is an important factor: a project manager faced with reds and ambers but who still expects to deliver as planned either has something interesting to tell you or needs to re-learn the basics of project management. Either way, I always include a ‘deliverability’ RAG – the PM’s assessment of how likely they are to succeed. The basic definitions of each colour are the same, and here are a few things PMs should ask themselves when setting their deliverability RAG:

Green:

You are confident that the project will deliver as planned and authorised, without disproportionate risks.

Amber:

You are not confident that the project will deliver as planned and authorised, but there are viable methods for recovering from this.

Red:

You are not confident that the project will deliver as planned and authorised, and there are no viable methods for recovering from this.

Deliverability was Amber in the last report and no recovery plan has yet been agreed to return those particular problems to Green.

I have found this a very useful and workable system, even down to the fact that it makes the supporting tools really easy to build. It takes practically no knowledge of spreadsheets to calculate the overall RAG status of a piece of work based on this system. No complex look-ups of percentages of values or conditions: if it’s red down below, it’s Red on top. Simple, effective, and above all else it tells its audience exactly what they want to know – What do I need to do?

A good read?

Search

Latest tweets!

My experience is quite different, though the people engaging consultants often haven't identified the problem. Instead, they've identified a symptom they've noticed. They often call it "the problem," though. I help them dig deeper. twitter.com/flowchai…

I've never known a team using stickies or index cards on a wall to need an administrator to accommodate changes in the way they work. They just do it. Inspecting and adapting your own process is magical.

"If your company simply takes the data provided and immediately fabricates the product with no careful study of the data, materials or process, it will most likely result in faulty products and leaves you with unhappy customers." twitter.com/IConnect…

For my money, the two greatest novels in the English language - Jane Eyre & Pride and Prejudice - are about complex, powerful women in a world that did not respect their complexity & power. This is not a coincidence. More please. twitter.com/Sketches…

#Adaptability is as central to #Agile as any other concept. In #Agile’s case, it’s especially striking – literally nothing is outside the scope of this principle – not just products & stories & designs & code but teams & the basic rules they work to.

It’s sometimes misunderstood why designers complain about shipping product. They often point at the designers need for perfection. This is not the issue designers have, it’s the need for quality in actually solving a real problem for our customers vs. shipping all the damn time.