Thursday, April 01, 2010

Red, Yellow, Green Project status

Over the past month I’ve read several interesting articles on status reports and I thought I would expand on an old post of mine (Red, Yellow, Green, Blue project status).

Obviously there is some common ground when it comes to status reports, but if you are going to have a status report or dashboard view of projects and you want to use the stop light approach as part of your information how would you define what Green, Yellow and Red means and for what?

Let’s start with the basic way: 
It is the old triple constraint: Scope, Time, Budget.You could have a stoplight for each one (Scope, Schedule and Budget).  Then you need a method of how to determine what Green, Yellow, Red means.  
Here is an example for Scope: 
Green - We are on track to deliver committed scope by committed deadline with committed resources/funding.
Yellow - We are not on track to deliver committed scope by committed deadline with committed resources/funding, but we have a plan to get back to green.
Red - We are not on track and we need a plan to get the project back on track.
Here is an example that brings in a couple more data-points and shows a bit of the history of the project over the past 4 months:
Okay, so that is a general overview, but we all know as project managers we hate it when our projects slip into the yellow/red areas. 
I’ve seen some organizations let the PM pick the color of the status in which yellow and red was meant to raise a flag that something is going on (using a reference as to when to change the color).  I’ve also seen organizations that uses metrics pulled out of project documents along with the PM answering some questions on a rating system which then the dashboard crunches the numbers and selects the color rating.  

What are some other metrics to follow?
How about a stoplight for risks?
If you capture a 1 to 5 rating for probability and  impact multiply the two and if it reaches a certain level it will = yellow or red. This measurement isn’t meant to take the place of a full-blown weighted risk-assessment methodology, which should be calculated separately for larger projects.
How about a stoplight for resources?
Do you monitor your resources?  If your resource are over allocated by 5-9% for the next report period it turns it yellow.  If 10% or more it turns red.  If you are tacking this in Project it should be easy to mine this data.

How often do we do this?
It depends on your organization and types of projects.  You may have some mission critical projects that you want the PM to update the dashboard weekly.  Or smaller side projects that a monthly update is okay.  This is something that should be decided at the beginning of the project and I personally like to see this indicated in the project charter.

How about just one stoplight for the entire project?
Yes, this is possible if you set up metadata to output one rating number or leave it up the PM to decide on the color.
Finally, stoplights give us a quick view into a project and are an effect way to view project information as long as the team member or executive can drill down further into your project to see what is going on as to why things are yellow or red.

Working the system
The dashboard data is as good as the project data compiled to create it.  Recently I spoke with a friend about her PMO and the stoplight concept.  She was aware that PMs in her organization know how they can fool the system to keep their projects green (including just resaving the previous month update so it looks like it was updated).  Knowing this is it important for the PMO to periodically check the status of their projects to make sure the PM is not trying to work the system (a mature PMO should conduct monthly analysis of a part of their PM process to make sure their PMs are in check).

Things to keep in mind
A red project does not = failure on the PM. It indicates that they are managing risks appropriately and requesting the appropriate degree of support to move projects back to green.

Noteable link:


  1. Ryan,
    What would be the error bands on these?

    Here's the system we live by

    The up and down (or sideways) arrows indicate trending.

    Once "off green" the critical question that must be answered is "what's your get to GREEN plan?" "What reporting period will you be back to GREEN?"

    The bulls eye chart shows how the performance measures move toward success.

    No performance measure can be used that doesn't have a historically adjust variance.

    And finally no performance measure can be sued that doesn't provide an actionable outcomes for corrective actions - meaning don't measure stuff that can't be used to make corrective decisions with - it's a waste of time.

  2. Glen,

    I can't say that I've seen arrows like that before, but I really like the idea. It is kinda like my screen my screen shot but gives you the same information within one column.

    Thanks for your comments,


  3. Ryan,
    The wInsight product (screen shot) is a popular tool in defense and space. There are others - Safran is our favorite. The key approach here is to show trends rather than a static value.
    In many cases cost is always YELLOW, simply because management reserve is rarely used.
    wInsight is a data warehouse for program information and Safran is the next generation of that approach.
    One of the issues with measures of scope and other softer items is - what are the boundaries. This is why you'd not see them in the dashboards of the programs we work.
    Rather, compliance against a baselined requirements document.
    How would "stakeholder involvement" be measured?

  4. This comment has been removed by the author.

  5. The best traffic light system I was asked to use involved calculated lights: schedule, cash, cost were all calculated based on actuals + EAC. Try as I might (and I did) I could not "cheat" the system.
    A way to get around PMs copying last month's data to this month (another "cheat") is to wipe out the previous month's forecast and force a new entry each month. In our case, the only data that was carried over month to month was real data copied from the business system. All forecast data had to re-entered by the PM monthly. I appreciated the elegance in this: it forced me as a PM to verify my forecasts on a monthly basis, at a cost of about 5 minutes per project.
    BTW, we were checking the traffic lights monthly.
    We also used arrows, as Glen mentions, to show trending: yellow trending to red is worse than trending to green.
    Finally, there was only one traffic light the PM could manually set, called something like "overall status". This allowed the PM to account for gut feelings, events that had not shown up in the finance data yet, resource issues, etc.

  6. Pretty good post. I just stumbled upon your blog and wanted to say that I have really enjoyed reading your blog posts.Any way Ill be subscribing to your feed and I hope you post again soon

  7. Hi Ryan,
    Last month at the local PMI chapter, Ken Hanley talked about the Dumb Ideas in Conventional Project Management..
    Here is the link to his presentation..

    What do you think about his Idea #: 9. I didn't totally agree with Ken Hanley..

  8. Selvaa,

    The important thing you need to do is define what Red, Yellow and Green means. If they are based off project metrics then the PMs and staff the review the dash boards need to know what the cut offs are.

    If the item is yellow or red (or just into the yellow = yellowish green) there should be a requirement as to why it is not green and the plan to get it back to green.

  9. Project management is always important for success of a project In fact it is key for success.I agree with ryanendres that define what Red, Yellow and Green is really important.Thanks for writing a nice blog.


Your comment will be reviewed to determine if it is appropriate. If you are adding links to your products, your comment will not be posted.