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.
Author Archive
Status – Red, Yellow, Green – Part 3 – More Than Just Timelines
by Michael Schwarz on July 2nd, 2010
Status – Red, Yellow, Green Part 2 – Defining Metrics
by Michael Schwarz on June 21st, 2010
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.
(more…)
Status: Red, Yellow, Green Leaves Much to be Desired
by Michael Schwarz on May 3rd, 2010
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.
Making Sense of QA Test Results – Part 4
by Michael Schwarz on March 23rd, 2010
What happens when you find yourself 80% through the timeline of what seems like a never ending test cycle, and can’t make sense of test statistics and defect counts? Every IT professional with enough experience has found themselves bogged down in a lengthy testing effort, buried in countless defects.
When you find yourself at this point, and the test planning failed to prepare for an elegant exit to traps like this (see previous parts in this series), it’s time to take it to the defects.
As stated in previous blog posts, in the end, Project Mangers need to only really answer the questions pertaining to real business value. Questions similar to the ones below help drive towards this:
1 – When can we go live?
2 – How much more money, time, and opportunity cost are we going to have to spend in order to go live with something worthwhile?
3 – If we went live tomorrow, what would the system look like? How would it feel? And what hindrances to core business functions would the organization experience?
Making Sense of QA Test Results – Part 3
by Michael Schwarz on February 28th, 2010
To run a successful testing effort requires careful and strategic preparation which should be baked in during the requirements phase. Dare I say test driven requirements? I don’t mean to preach agile or extreme programming methods, and in some cases (like large distributed multi vendor projects), waterfall delivery is inevitable. But even in the waterfall world, much can be taken from the XP. Thinking about testing as early is possible is one of these virtues.
Even if test driven requirements are not in the plan, building well thought out Business Requirements & User/Functional Scenarios is a must. Rating these items by severity (or importance to business success) is vital. Main flows and sub flows should each be rated accordingly. Test cases should then map to these specific items and they should maintain the severity level associated with them. Defects should be classified with this business severity in mind.
Making Sense of QA Test Results – Part 2
by Michael Schwarz on February 5th, 2010
Large software programs eventually involve equally large and cumbersome testing components. A great deal of work goes into planning, organizing, executing, and reporting on these testing efforts. Furthermore, most development initiatives run way past original timelines and naturally try to squeeze the testing initiative into slimmer timeframes.
What comes out of all of this usually amounts to a series of raw statistics, morphed into trend lines, bar graphs, limitless numbers, and complex dashboards that few people understand. If you’re lucky, there might be someone that can show a neat test coverage chart that shows how many test cases map to different parts of the application space, and how many of these test cases pass and fail.
It usually takes a great deal of effort, and in some cases, a lot of money in testing software tools to put all of this information together. But hidden within all of this information (vast rows of statistics and graphs), is a little secret that few people recognize… It doesn’t mean anything.
Making Sense of QA Test Results – Part 1
by Michael Schwarz on January 24th, 2010
How often have you been part of a software development project where Quality Assurance efforts seemed to produce relatively meaningless figures and statistics? What does 69% execution rate, with a 53% pass rate really mean? How do you make sense of 400 defects, even when they are set to appropriate priority and criticality? Does this tell you anything about the health of a development initiative?
Let’s say, for example, that you are in the PMO group of an organization launching a brand new wireless service offering. This offering includes all facets of a customer facing wireless service solution (from the network, to billing system, to customer self care and CSR systems).
