Why do we use project RAG status instead of team confidence levels to make it more personal and accountable?

Question

On lots of PM reporting decks you see the usual RAG status and I was wondering why we do this versus simply putting down "confidence levels" that make it more accountable and personal.

"The project is Red" seems less accountable and clear compared to "I have low confidence that I will hit the date listed."

I feel like the whole RAG status is not very natural and meaningful to many sponsors and project participants (even if its defined somewhere), so I wonder if being more explicit and accountable is actually a better way to report on projects.

Another point is that with RAG, people seems to keep project "Green" until there is a problem. Where confidence on delivery might have degraded because of complexity or underestimating, I have observed folks not changing the status early enough. I feel like if they were forced to put a personal confidence level, things would change much sooner as it represent a statement about them (not just the project status). It's a psychological point but I feel like there is something to it.

Does anyone have any information where RAG came from and if they have any evidence that is better understood than just listing out confidence levels (High, Medium, Low)?

To be clear, I have no issues with actually having the visual colors showing, but just saying "the project is Amber" seem one step removed from what we are actually saying...why require the translation?

Answer 1

First of all: Why RAG instead of numbers with a legend or text? Because it's faster to grasp. From our cultural background we know that red is a warning color, yellow is something to be aware of, and green is more like ok. If something appears in red on my screen, I automatically look at it first. If there's to much red to focus on the specifics, I know I'm in trouble...

Regarding clearness: What does "low confidence" mean? 20%? 30%? 5%? It is seldom possible for 2 or more people to agree on a certainty level. After all you're not going to conduct statistical tests. So whatever representation you chose, the "value" you assign remains a gut feeling to some extend.

It has been found in management that it is easier to categorize things, if the categories are few and distant from each other. R = "critical", A = "out of normal", G = "ok". I can quickly decide which category my current situation is in. You can see the same in Planning Poker where the numbers are chosen with increasing distance in order to make it easier for you to decide which one is more accurate.

Regarding personalization: As you can see from the the wikipedia article there are alternative/extended versions of RAG being developed as users find they do not fit there needs.

Answer 2

Adding on to what salsolatragus said, in a project environment where deadlines are critical to be met, the application of colour psychology (in RAG, or any other extension of RAG) is extremely useful as it instinctively promotes a specific awareness with less ambiguity (than a scale system), while making it appear more objective. This is useful from an individual issue level, to an overall project level.

It may not be useful to clients to see "oh, my project is listed as red...", but that's where communication comes into it - you'd have to say it's red lighted which means we're working as fast as we can to meet the deadline, but we may need to extend it due to lack of resources or unexpected things/changes to the scope.

Unless you are using specific statistics to determine a scale of 1-5, e.g. < 20% is 1, < 40% is 2 etc (and % based off what? completed issues? incomplete issues? can you be confident that ALL issues are recorded? can you be confident that you won't be interrupted?), then a 1-5 scale of completion confidence would be subjective - you'd go off a feel. If you feel like it won't be done, you might put a 1, 2 or 3, as you can't really know it won't be done. If you want to come up with a scale though, you should keep it simple and based on common terminology or processes your team, and stakeholders, would be aware of. 'Low confidence' as said before - what is considered low? Is it your opinion, the opinion of 2 developers colluding together to not have to work as hard?

Making something bright red and in your face is more likely to get the attention of someone than something that has been classified as a number. Example: if you have a project that has 5 issues to be completed, and they are all behind schedule (and you aren't already urging people to do them ASAP constantly), then marking them as red will, from a psychological stand point, make them feel like it has to be done quicker. Mark one as amber, and immediately, your staff will think of doing that one last. If you used a 1-5 scale, they would have to sort the list descending first, to determine which to do first, rather than just being able to look at it.

For example, I've noticed this in my team in projects when there's an issue that needs doing. If I change it to 'Immediate' priority, which makes it go red and bold, they'll often even do it from home! We use Redmine which has Immediate, Urgent, High etc (essentially a 1-5 scale). I would prefer it to be RAG, because those 3 categories should all essentially mean the same thing to me, and my team don't care about the difference between them. Anything other than normal means do it asap, so its a cultural thing too.

In terms of RAG and colour psychology, we actually have a Do Not Disturb light on our door office door. We change the colours based on the importance of why we shouldn't be disturbed, and it works. When it's red, people will be really nervous about asking us. When it's green, they just walk on in.

Answer 3

The two different reporting alternatives are not mutually exclusive. Confidence level is a statistical construct but I don't think this is what you mean. I am interpreting the use of confidence level more from a PM's/Team's subjective opinion of how things look and where things are headed.

I think BOTH should be used when communicating to stakeholders. The RAG should be a calculated result; it's objective (reasonably objective anyway); it's reliable and a high degree of validity. Because of this, the data that goes into it is lagging, it's historical, with the assumption that its future is based on the past.

A PM's and or team's opinion of health, a subjective view, and their confidence of how things are should supplement the RAG. By definition, it is far more subjective, less reliable and valid, but can show analytical thought about the future. The analysis can include additional leading indicators to help predict the future. Of course, you can do some of that with a more objective RAG formula, too. However, there is something to be said to include the human in the analysis.

Therefore, use both. Our numbers indicate we are red; however, I have medium to high confidence, based on the interventions deployed and some signs of improvement, that we can recover by project end. The red shows where we are, it gives the sponsors opportunity to challenge the subjective and likely overly optimistic of health, but they can also find some comfort based on the PM's point of view.

Answer 4

TL;DR

"The project is Red" seems less accountable and clear compared to "I have low confidence that I will hit the date listed."

The core of your question presumes that:

1. Personal accountability is the goal (or at least a desirable outcome).
2. A person's confidence in something is an accurate measure of project status.
3. Feelings are an objective measurement.

I think the presumptions are, at best, solving the wrong problem. I assume the underlying problem is really "Why is my project not currently within tolerance?"

If you want to communicate effectively about your project, be clear and concise. If a project is out of tolerance, always inspect project and organizational processes first. "Accountability" is generally a poor substitute for good processes or efficient dynamics.

Red, Yellow, and Green

Red, yellow, and green are often used simply because they are very visual, and because they correspond to traffic light signals that most people are already familiar with. This makes the cognitive load low.

A sea of green means everything's okay. A few red dots draw attention to problem areas. A sea of yellow or red indicate a project that's badly off-track.

Accuracy Doesn't Depend on Encoding

Can people misrepresent the status of a project? Sure. Even if you aren't using color codes, how many projects have 60% of tasks at 80% completion? Are those numbers any more honest than the color codes? Even if they are, what does that actually mean? Is it within the expected range of values, or not?

Red, yellow, and green are no more (or less) honest than any other metric. But as long as everyone agrees on what the colors mean, they communicate more efficiently about the urgency of a status.

Personally, I'd pay more attention to a work package that's flashing Yellow Alert! than something marked 63.2% complete, plus or minus 3%, with an 85% confidence level of 6.8% schedule slippage. YMMV, I suppose.

Fixing Blame

Saying "the project schedule is out of tolerance by six weeks" is more objective than saying "Joe doesn't feel confident that he can embiggen his widget by next Tuesday." The first is useful information about the status of the project, while the second is either a way to blame Joe for something that may represent a broader process problem, or perhaps even to blame him for not drinking the project-approved Kool-Aid.

If your immediate follow-up question is "Why isn't Joe confident that he can embiggen the widget before the Gantt chart says it should be embiggened?," then at least you're trying to investigate a process problem that has the potential to impact the project.

If that's not the point of measuring the confidence of task performers, then it basically amounts to scapegoating anyone who isn't buying into the defined management targets. Would you rather Joe say "Rah! Rah! I feel absolutely, positively confident that my widget will be embiggened by next Tuesday!" even though no one's even sourced a widget supplier yet? You're either encouraging him to lie, or holding him responsible for something outside his control. Either way, it can't end well for ol' Joe unless he bails on the project before it implodes in fiery failure.

Focusing on the project's process and overall progress is generally more constructive than blaming individuals. If you're worried that individuals will be motivated to pass the buck, you might want to spend more time thinking about why they are motivated to avoid responsibility on the project than on trying to hold their toes to the fire.

In my experience, if you fix the project dymanics, and the project usually fixes itself. Your mileage will vary.