Starting Green

One of the most useless project management conventions I have ever worked with is the status stoplight or RAG status. From a simplicity perspective, it is designed to convey a general state of the project. Green means things are “OK”. Amber means things aren’t that OK. Red means things are not OK at all. The convention is to get the attention of stakeholders when the status changes from green to amber to red. It is a beacon, or warning signal that something needs to change.

Meaningless, Clueless, Shocked: In my experience, though – there are two problems with the RAG status. The status is so general as to be meaningless, so no one really has any clue what is going on or what they are expected to do about it, except when the status goes red. Which leads to the second problem – when the status goes red, it brings a crap-ton of clueless auditors with microscopes and shocked executives with stupid questions out of the woodwork. At the very moment, that the project team needs to be “all hands on deck” to fix the issues, we end up spending more energy in unhelpful meetings answering questions asked by people who if they read the documents and statuses that were previously published, would probably learn what they should have known all along, HAD THEY BEEN PAYING ATTENTION!.

Most organizations, the implied meaning of the RAG status is based on budget and time line feasibility for the committed project scope or statement of work. Green means feasible, amber means maybe feasible, maybe not, red means not feasible. It doesn’t tell you how much anything, and many organizations don’t have meaningful quantified values representing how bad it gets before you go from green to amber to red. It is very subjective, and based on the project manager or sponsor or delivery manager’s gut.

Feasibility is binary: Enough about what is wrong, what can we do instead? Feasibility is not a relative measure, it is binary. “Maybe” is a problem, ‘cuz it doesn’t fit into binary very well. In my experience, “maybe” is the right answer until the project is complete. So lets propose a metric on what drives “maybe”, risk. Risk is derived from the bets you made on specific outcomes that may not happen as predicted. The amount of risk depends on each bet, your confidence in that bet (or probability of desired outcome), and the impact of that bet in terms of budget and/or schedule. The rag status can be considered “green” when the schedule and budget “cover” the known risk impacts at a certain confidence or above. The organization or project stakeholders can establish certain risk “levels” to report status – red, amber and green.

Quantified Risk Impact: This using quantified risk impact versus budget and schedule is at least a way to take the subjectivity out of the status indicator. We must also understand that risk is relative to remaining budget and schedule. As the project progresses, the less risk you have the ability to accept or mitigate. So you want to retire risk as fast or faster, relative to the project as you complete work. This requires frequent re-assessment of risk – and a measure of “risk remaining” along with “work remaining” alongside your budget and schedule remaining metrics.

Risk Mitigation: The last thing is the work required to mitigate risk. When a risk is uncovered, or identified, the project team decides whether to accept the risk (make the bet) or to mitigate the risk (hedge the bet). Mitigating the risk requires adding work to the plan to reduce the impact of the bad outcome. The mitigation activities are added to the other planned activities, and when they are complete the impact of the risk is reduced. (this is a common mistake, that because we planned the mitigation, we reduce the impact of the risk) Risk mitigation is performed, based on mitigation cost versus risk impact and probability. Planners schedule risk mitigation, so that it is complete before risk impact is “realized”, but starting “as late as possible” so that I do not incur the mitigation cost, if the impact appears less likely or less costly as time passes.

So the final stupid thing is really that all projects traditionally start “green”. You have no team, no details, a desired scope, a budget and a desired completion date, and we say we are green. A project should be Red until the core team is on-line. A project should be Amber until the team has demonstrated that they can meet planned delivery milestones. Yet to most of us, this appears counter-intuitive. The deadline is far off – we have plenty of time to recover, to get our stuff together, how can the status be red. It’s simple. Until the team is formed and demonstrating that they can deliver at planned capacity, they are the biggest risk, and the risk impact is the delta between expected delivery and actual delivery – which at the beginning is “The Whole Project”.

My recommendation: Make your projects earn their amber or green status. Start projects red, have clear guidelines around risk and delivery for “earning” their amber or green statuses. History has shown with so many projects failing to deliver full scope, on time, on budget, with expected quality and business value – starting green lulls us into a false sense of security. It allows executives to feel like we (the project team) have it under control, when in reality we just have a long fuse on a ticking bomb. When the project goes “red” the executive asks “How did this happen” – the answer really is, most likely, that we never really had it under control in the first place, we just assumed that we had enough time to recover.