Using Color on a Project Status – Worthless without Definition
Red, Yellow and Green – infamous colors used for street lights, ugly holiday sweaters and project management status reports. While I am fundamentally opposed to the ugly sweaters, I am a strong supporter of street lights and project management status reports. The status report is a critical communication tool.
Project team members and leadership within your company cannot check on project status daily. Yet they need to stay informed of the overall health of the project. There are so many ways to do this in a way that is effective for team members, executives, and the project manager. This post is going to focus on the use of color in status reporting but another day I may have to write a post about how to use the status report (PLEASE do not have a meeting to read your status report….. ). I would strongly suggest looking into the PMI organization for some good guidance from their PMBOK (Project Management Body of Knowledge).
I understand why so many people are driven to report status based on color. It’s easy to read, visually easy to recognize, and so many people like to use jazzy little clip art of spotlights on their status report for fun. But a red, yellow, green status report is as worthless as the crayons it is made with if you do not define what specifically drives a project to be classified by one of these three colors.
All projects involve 3 things – Scope, Schedule, and Cost. Therefore, a good way to define how you will monitor the status of your project involves these three areas. You can try to blend these three areas together to report a single “color” status — but I think the overall project is better reported by area for a more complete perspective.
Reporting Status of Scope
Scope is a bit tricky as it is either defined, or not. A good way to monitor the health of your Scope is to track the number of pending, approved, or rejected change requests (post-requirements approval). Given that a change in Scope will also (likely) impact your Schedule and/or Cost – this area bleeds into the other two. I would suggest talking with your Project Sponsor early in the project to define what an acceptable amount of change will be for this project. This can be hard to quantify but when you consider what the priority of the project is (Scope, Schedule or Cost – only one is most important) – then you should be able to set an objective to manage scope change appropriately. If Scope is your project priority – then you may expect a high number of change requests. If Schedule is your priority, you may want to define an objective to only accept X days of additional development into your project through change requests. If Cost is your priority, then you may state that change requests will be budgeted to stay within X% of your total budget. Again – this is subjective – just some ideas here to get the conversation started.
So for Scope, in our situation, we may state that the following:
At any point, if the volume of approved change requests is within 0-2% of total budget = the status of the effort will be Green. Change Requests +2%-6% will be considered Yellow. Any point when the approved change requests exceed 6%, the status of Scope will be Red.
Fact-based and yet still associated to a color! Best of both worlds!
Reporting Status of Schedule
This type of status reporting is more native to many project managers. It’s all about dates. Most project managers define a WBS early in their project lifecycle. The idea of reporting status is about using the major milestones in your schedule and noting when you are starting to press against the boundaries that you define early in the lifecycle.
Any major milestone that is not met within 2 business days of the Planned Date will cause for the Schedule to be reported as Yellow. If a major milestone is not met within 5 business days of the Planned Date will cause for the Schedule to be reported as Red. Any major milestone that is accomplished prior to or by the Planned Date will cause for the Schedule to be reported as Green.
If, along the way, the project schedule changes (which they so often do) – then just revise your tracking plans as needed. And make sure you define your own boundaries – I used 2 & 5 business days as an example – it all depends on the Project Priority. If Schedule is not a significant objective for this project, pick your battles and select windows of time that are appropriate. Don’t scream that your project is Red because of a missed Major Milestone when, in reality, the Project Sponsor just wants it delivered sometime this year.
Reporting Status of Cost
By now, I’m almost thinking that I don’t need to write anything for this section. I’m sure that you get the idea….
The status of Cost will be reported as Green if Project Actuals & Project Forecast are within 2% of the Total Budget. If the Project Actuals + Project Forecast are between +2%-6%, the status of Cost will be reported as Yellow. If Project Actuals & Project Forecast exceed 6%, the status of Cost will be reported as Red.
Hopefully this post is giving you some ideas of why colors are meaningless unless you put some thought behind them. Too often, project managers apply color subjectively and can get everyone’s attention on a RED project that may be distracting management attention from something else that needs it more. If you are going to use color, define how it will be applied in advance. Make it part of your project kick-off so everyone understands how the status will be reported and the color will complement their understanding of the situation being reported on the status.