Status Reports are Evil

I am not a big fan of status reports. As far as I’m concerned, they should all come with a health warning: “this is a political tool – all statuses allowed as long as they are green”. Surely common sense tells us that the only indicator of how well we are doing is the rapid delivery of valuable functionality to our customers, selling each iteration as it’s built and justifying the project approach through the delivery of outstanding results? (Not forgetting, of course, to continually question whether the way we are operating could be improved). Reputation can only be built on what has been achieved, not on what we say we are achieving, so attempting to demonstrate progress by circulating a static report can never be as powerful as merely showing the products that have been created.

We should concentrate on doing the work, not on just talking about it. As Stephen Denning suggests in the Leader’s Guide to Radical Management, it’s time to take the “red pill” and see just how “many of the bureaucratic practices of the organization appear comical or pointless”. Indeed, traditional approaches often seem to deliver exactly what we don’t want, be it project documentation or actual product. This could be because our governance function mandates the delivery of useless artefacts (don’t get me started on the Project Initiation Document). Or it could be because we realise that what sounded like a good idea at the time is actually an addition that brings little value. Status reports fall into both of these categories – a useful maxim that I always apply when setting up and running projects is “if it might be useful then DON’T DO IT. ‘Might’ just isn’t enough.”

 

So long as we are consistently releasing valuable, working, maintainable products to our customers then we are doing fine, and the only success factor we need then worry about is whether we are delivering on time. This an area where Agile methodologies help by building contingency into the process through an insistence upon prioritized requirements, where we consider the delivery of only the most pressing functionality a successful endeavour. And status reporting doesn’t add anything to this delivery process. If your stakeholders really want to know how things are progressing between each product delivery just take a photo of the “not started / in progress / done” grid on your whiteboard; this is where the most up to date status information resides!

The project triangle of cost, time, and scope is a myth. If we don’t engage and then impress our customers with great products, low prices and excellent service, then we’re in trouble. And then no amount of green on our status reports will save us.

HOME