Stop for red
How can you report status and progress more frequently so it accounts for both good days and bad days?
A traffic light works well for directing traffic for a couple of reasons. These reasons also makes traffic lights really poor for reporting status. Every color has an associated action and behaviors that all driver know and at least the vast majority obey. The next color follows a predictable pattern so you know what to expect to happen in the future. It’s based on timers or sensors so it’s changing based on the same input signals every time.
Neither of these conditions are usually true using ‘RAG’ status reporting for projects or programs. Certainly not following a predictable patterns. Example: Reporting ‘Amber’ might not be too bad if the previous 3 reports showed ‘Red’. Neither does it give any steer towards what appropriate actions would be when status shifts from ‘Green’ to ‘Red’.
What’s makes the traffic light model even more dubious as reporting status is our propensity and ability to select status in anticipation of actions. In most borderline cases reporting ‘Green’ as to signal ”There’s nothing to see here, no action required”. Also when we have been looking at hundreds of ‘RAG’ project status reports is the the more infrequent the reports are made, the more ‘Green’ they appear.
Consider
How can you report status and progress more frequently so it accounts for both good days and bad days? Provide not just the current status but the trend and most recent previous statuses. And do report frequently enough to account for both ups and downs.
Additional Insights
The future of full stack engineering talent
The art of feedback
Don’t confuse tools with technologies
