Two Steps to Getting Truly Useful Project Management Metrics
I believe one of the hard steps to getting to truly useful project management metrics is to get to a point where we realize that the “metric” actually tells us something useful — and we believe it. For too long, organizations have been whipping together PowerPoint slides and dashboards purporting all sorts of insights — based upon data. Too often these are never paid attention to nor ever used in managing as they did not capture an enduring truth, just someone’s current speculation couched in data.
One test of a metric I’ve employed is to observe if the metric is used routinely in daily practice. We computed the average time to fix a defect and found that this simple metric — once we realized it effectively predicted the near future — readily answered many daily questions: How long to fix this new defect? When will all defects get fixed? How long until the defect arrival rate is down to a product shippable level? What use to consist of continual — and often heated — discussion and debates became a simple “tell the customer we’ll have it fixed by next week” with everyone confident we’ll do just that.
For more see Knowing Your Project Management Average Is Powerful
Getting to this point of “ah ah!” — where we finally produced a metric that makes sense and is useful — can be leveraged to help an organization evolve to “smart” metrics instead of “we wish” metrics. So while that gives us a chance to get good metrics, what I’ve observed is with some organizations the time to finally “believe” the metrics, is longer than the life of the metric.
We had computed that it took us six months from when product software development was complete to when we had ironed out all the bugs and had optimized the product to where it would be acceptable to the customer. This was a great insight when we first recognized it. It went against normal intuition because, as each product was different, the assumption was that the “back end” would vary with the project. It didn’t. It just took consistently six months.
Compare with Is Your Schedule Really Driven By Your Requirements?
Over time, as we changed our process — this tail end characteristic, unfortunately, moved out to eight months. The problem really arose when very senior management, who never bought into the notion that the tail end process was fairly predictable at six months, suddenly got religion and started to quote, several years later, that the end process would take about six months. I had to try and re-educate them. At least one very senior manager seemed annoyed that something I had “harped on for years” had “suddenly” changed. How could they believe this new number then? This is where we go too much the other way where finding a key metric, some folks just want it to stay the same, even as the real-world changes.
First, find a few real metrics that tell us something useful and predictable about the way we do our daily business. They should not change too rapidly with time, but will often change over time. Once we’ve built confidence with these few metrics and folks can see what a good metric looks like, we can then secondly develop a few more measured insights and our management decisions are now on the road to greater effectiveness.
Do your project metrics provide predictable insight that allows you to make rapid decisions each day?