IT Communications Blog

Although almost every project uses this paradigm, Red, Yellow, Green status is not very useful unless implemented in a certain way. The following suggestions are ways to improve the effectiveness of using this kind of status indicator.
1 – Define Red, Yellow, Green in terms of its most common perceived use (timeline).
2 – Expand the color coded status paradigm to report on more than just tracking to plan.
3 – Pull the emotion out of the color coding.
We talked about item 1 in a previous post. We’ll use this post to discuss item 2, and leave item 3 for a following blog post.
Most often, red, yellow, green is implied to indicate how an initiative is tracking to plan. That’s fine, but tracking to plan (or schedule adherence) is only one element of a healthful project, and is hardly the most important element.
In IT project management (and often in other disciplines), there are 3 levers that can be pulled to change the dynamics of a project:
1) Schedule
2) Scope
3) Quality
You can compromise scope or quality to adhere to a schedule. And if scope and/or quality are more important than a date, than reporting status on dates only, is a poor indicator of project health. However, it’s almost always what red, yellow, green is implying.
There is a better way… The creation of a dashboard that looks at a project in high level, color coded, simple concepts can convey far more information than a single status indicator. Expanding past the three categories listed above is recommended. For example, a weekly status report could report “Red”, “Yellow”, “Green” status on a series of project health indicators, such as:
1) Schedule
2) Scope
3) Quality
4) Budget
5) Resources
And then all of that get’s wrapped into an “Overall” status. In my previous post, I said that color coding only works if each status indicator has well defined and socialized metrics behind it. This applies to all status indicators. So for each of the 5 criteria, and in turn the overall indicator, there needs to be rules for why it is Red, Yellow, or Green.
This discipline increases the effectiveness of the status reporting process because the report creator must think critically on what the status really means, and where the problems are at. It also encourages the recipients to acknowledge that projects can be complex organisms which require constant tuning to approach a successful outcome.

It seems like every IT organization requires project managers, team leads, and program managers to produce status reports and dashboards displaying the successes and failures of current initiatives. Almost without exception, the focal point of the status report is the indicator colors of “Red”, “Yellow”, and “Green”.
As stated in a previous blog posting, I often question the usefulness of this color coding strategy. However, forgoing the color indication entirely would leave most reviewers at a complete loss. So how do we make the Red, Yellow, Green status more effective? Here are three suggestions:
1 – Define Red, Yellow, Green in terms of its most common perceived use (timeline).
2 – Expand the color coded status paradigm to report on more than just tracking to plan.
3 – Pull the emotion out of the color coding.

We’ll talk about this first concept in this blog. The remaining two points will be discussed in following postings.
Read the rest of this entry »

It seems like every IT organization requires project managers, team leads, and program managers to produce status reports and dashboards displaying the successes and failures of current initiatives. Almost without exception, the focal point of the status report is the indicator colors of “Red”, “Yellow”, “Green”. I often question the usefulness of using such an arbitrary paradigm. First, it does not mean very much to the people that review these status reports, although these people may not realize this. Second, it’s often more of an indicator of the general mood of the people contributing to the project or writing the status report, than objective metrics and data that could then be translated to red, yellow, or green. So let’s first talk about what Red, Yellow, Green is supposed to mean. Green usually means that the project is progressing as planned and that the dates socialized are realistic and almost guaranteed. Yellow means that there are risks to the schedule and there is hopefully a mitigation plan in place to alleviate these issues, but the schedule is at risk or the scope is reduced. Red means that the project is not going to meet its objectives, and it usually refers to the socialized dates that the team is driving to. The problem with all of this is that the sizing up of status based on this type of system alone is very subjective, and usually follows a very familiar pattern. The project starts as green for a timeframe that starts right after the initial plan is baselined to about 25% into the project plan. The project then turns yellow because obstacles have been identified that jeopardize the plan (in terms of dates), and towards the end, most projects go red (from a timeline perspective), and need to be re-baselined. Once the project is re-baselined, it goes back to green or yellow status and the process repeats. The reality is that the color coding is not helpful in assessing the health of a project or the plan that underlies it. All projects should start out as yellow, because planning is no guarantee of success, and timelines are only one metric that should be considered when communicating the health of a project. There is also scope, quality, budget, morale, business value, ROI, etc. Usually none of this is represented in the color coding. So what else could be done to communicate status more effectively? The answer is metrics and tools that allow managers to assess health based on these metrics. I’ll post some comments on this approach in a future blog.