In my previous column, I talked about the use of metrics in IT project management and the three qualities of an ideal metric: informative and preferably predictive, objective, and automated. The ideal set of metrics would tell you when your IT project is going to ship; these metrics would give you the same answer no matter who calculated them; and, in fact, the computer should calculate them for you or for anyone else who asks.

And then you woke up.

A predictive IT project metric (or a set thereof) would be able to measure—or at least estimate—the gap between where the system under development is now and where it needs to be to ship or go into production.

What you want to know, first and foremost, is the amount of time that will pass from now (“current spot”) to when the projects ships/enters production (“project end”). But that in turn depends on many factors, including:

• The amount of invention (novel problem solving) that still has to occur.

• The amount of discovery (e.g., running into roadblocks and dead ends) that still has to occur.

• The adequacy of the current architecture, design and implementation.

• The amount of actual coding that still has to occur.

• The amount of quality engineering (testing, reviews, etc.) that still has to occur.

• Any and all remaining external dependencies (availability of resources, availability of technologies, deliveries from vendors and other projects, etc.).

• The talent, experience and productivity of your IT engineers and managers, as well as turnover among those employees.

• The amount of business process re-engineering required to put this system into production, as well as the degree of resistance or cooperation among the affected business units.

• The complexity, cohesion and comprehensibility of the overall system.

• The amount of analysis (gathering relevant subject-matter information) that still has to occur.

This is not an exhaustive list, but it gives you an idea of the challenges you face. Imagine trying to derive all this information from counting the number of lines of source code created so far, or the number of object classes, or the number of open and closed defects. It just won’t work. And yet metrics such as those are commonly gathered, reported and relied upon as if they revealed anything meaningful about the project’s overall progress.