Lies, Damned Lies and Project Metrics (Part 3)By Bruce F. Webster | Posted 2008-06-18 Email Print
Instead of deciding ahead of time which metrics are likely relevant, you first want simply to gather as many metrics, or characteristics, of your IT project as you can, then process them
We’ve already covered the ideal qualities of metrics (informative and, preferably, predictive; objective; and automated), and why it’s so hard to come up with useful metrics for IT management. Let’s now talk about two concepts that may help you monitor and predict your IT project’s course: instrumentation and heuristics.
My first job after graduating from college was with General Dynamics in San Diego. I worked on several projects there, but one of the most interesting involved tanks and trucks. At the time, the Soviets were putting plywood shells–shaped and painted to look like tanks–atop large numbers of trucks to confuse NATO attempts to track Soviet tank movements along the European/Soviet Union border via satellite photos.
This project’s goal was to bounce side-looking radar signals off vehicles many miles away–that is, on the other side of the border─and determine if the vehicles had tracks (a tank) or wheels (a truck). Signal-processing techniques yielded 25 or so different characteristics in the returning radar signal; Bayesian analysis allowed us to use just three of those characteristics to distinguish accurately and rapidly between tanks and trucks.
The solution to IT project management metrics may be lie along the same lines, namely gathering as much information as possible and then finding which characteristics best identify or predict the state of the project.
In other words, instead of deciding ahead of time which metrics are likely relevant, you first want simply to gather as many metrics, or characteristics, of your IT project as you can, then process them to find which combination of metrics is most accurate for determining actual status and predicting completion.