Traffic Lights and Project Status

For years, I have ranted against traffic lights as a way to discuss project status. That's because on serial lifecycle projects, or on long projects, the traffic light was always yellow or red. And, because managers, especially senior managers expected the light to turn green by itself with no outside intervention.

But Lisa Crispin noted at Belgium Testing Days that her project was mostly green. It's an agile project, and the build mostly works, and the tests mostly pass. It's a rare day when things don't work.

And, now my friend and colleague Yves Hanoulle has another really good use of red and green highlighting in a report that shows more testing, fewer warnings, unreachable code detected. I really like that unreachable code detected!

The nice thing about using red and green is that red means stop and green means go. It still doesn't help the color-blind people, but it's a nice use of the contrasting colors for those of us who can see the colors and understand that if we want to fix something we'd better.

For me, these uses of red and green are different than the traffic light project status. For one thing, they are binary status: either red or green, not yellow. And, the teams' reactions are different. Lisa's and Yves' teams (I suspect, I don't know for sure) are much more likely to pounce on a red piece of data than when a project team had a yellow traffic light status.

So, I have to be clearer on how I rant about using traffic lights to describe project status. For agile projects, traffic lights, as long as they are binary and prompt people to action, are a good indication of status. For other projects, I still like weather reports.

4 Replies to “Traffic Lights and Project Status”

  1. Thank you for turning my question into a blogpost. That is more useful then an e-mail answer. 😉

    Yes the teams I am coaching are reacting to the report and the BigVisual screen that goes with it. Already in 2 retrospectives teams said: wow visual management does work.
    The other site is that some people don’t like my reports. Still figuring out why (I have some idea’s but they are not verified, so I won’t write that on a blog.)

  2. I have worked on lots of serial projects where the traffic lights where green. And they were really green, not just green to look good.

    There are many cases where serial projects work.

  3. I like to use red – amber – green (RAG) because it helps communicate some useful nuances around issues:

    Green – no problems, we’re doing as well as expected
    Amber – we’ve got a problem, but we (the team) think we can deal with it
    Red – we’ve got a problem and we’ve exhausted our internal options, so we need executive intervention

    Amber helps ensure that the exec / sponsor / management isn’t surprised by an issue suddenly hitting them from nowhere. But it also ensures that they don’t wade in too soon — execs who panic and intervene too early can do a lot of damage…

    Big thing that lots of teams seem to miss is communicating what the colours mean. Just using them without having a dialogue with the exec (or whoever else is likely to see them) about what they mean is a recipe for miscommunicating.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.