“Thinking Clearly About Performance” Communications of the ACM, September 2010 was a great article I found hidden in my backlog of reading, but I found as basic as it was, it was a challenge to “think clearly” about what the article was trying to say.

First, Think Clearly About The Project

There is a simple notion I’ve often noticed. If I personally don’t do something regularly, then it doesn’t matter how simple it is, I will not “get it” — think clearly about it — without some additional time and effort.

I’ve written a few articles on just using simple project management averages. Add em up, divide by the total, and find an average. It is always amazing how this simple number enlightens people who are otherwise incredibly bright.  My classic example is the time to fix software defects in a large worldwide corporation.  All the experts, our smartest people, would always say something like it will take three days to fix a defect but in fact, when we add them all up and divide by all of em, it was rarely less than seven days and often depending upon where we were in the project, 10 to 14 and even 20+ days.

Another classic example I’ve used is how long it takes to complete a project (software, IT, etc.).  Of course, the common answer is that it depends upon the requirements — and while this seems logical, it is amazing how often I’ll ultimately get the closest answer by adding up past similar projects, dividing by the total and then using that as the estimate.  Again, what I see typically is the expert answer (sometimes backed up by large planning processes — some developed by the top consulting firms in the nation) taking 2-3 months to complete and my answer based upon what has happened in the recent past being computed in a few minutes and being more accurate (i.e., closer to when the project finally completed) then the high end complex process.

Metrics Regularly And Consistently Used Are Better Understood

The bottom line is that even basic numbers, averages for example, are not readily understood by folks unless they are used regularly by these same folks.

I often say we have to “live” with the numbers for awhile before we come to understand them.  I love such things as distributions and percentiles to help characterize “populations” of data, but the fact is that unless we work with the numbers regularly, use them daily, they don’t stick and these fancy terms don’t have any “gut” level meaning.  When we make use of our performance data daily, then these fancy terms are just that: “fancy” and we wonder why we need such intimidating terms for things that are very simple (once we get to know them!).

The Challenge Is To Get A Team To Use Good Metrics

I remember the first time I used the average we had computed for how long it was taking to fix a defect.  I knew it was just an average.  I knew that some defects were fixed in hours and others took weeks to understand and complete.  Nevertheless, when the inevitable demand was made of “how long until we fix this problem?”  I said — about a problem we have no details on yet, just that there was a problem — it should be no problem getting it fixed by this time next week as we are averaging seven days to fix our defects.  The conference call went silent for a moment — only a moment.  It was heresy.  The traditional and expected reply was “by this Friday.”   The ensuing cries of outrage were tremendous.  I waited a moment, then softened my response by saying “of course, that is the average, and as we are able to reproduce and understand the defect, we’ll know more.”

My purpose was to warm up the crowd to the notion of understanding the numbers.  Over the course of the project I regularly used the current average number of days and the number of days it was taking to fix 95% of all the defects we see.  This second number was “the longest defects to fix are currently taking about X days” number. The good news was that every few weeks, the average dropped by about a day.  I also knew this was normal over the course of a project, because I’ve looked at the data for past projects and this happened to them and because  this is what  has been happening on our current project.

Clear And Objective Thinking Requires Daily Practice

Clear and objective thinking requires regular practice, just like any other skill.  Clearly thinking about the numbers that characterize our project performance requires this same approach of using those numbers on a daily basis.  Once we’ve come to know our performance numbers they become simple and obvious and tell us where we really stand.

What part of your project could benefit by more clear thinking on a daily basis?