On first inspection it seems like common sense: Measure the stuff that will make a difference to your success. There's a corollary of course: Why would you measure stuff that is indifferent to your success?
I guess this is sufficiently mysterious that it warranted a recent article in the Harvard Business Review, the theme of which is: measure stuff that really counts!
When we port this idea to the project domain, it's amazing what you find. Most project managers focus on measuring the consumption of input (the stuff that feeds the beast), and resist, even disdain, measuring production of output: that which the beast begets--project value.
Of the former (input), I am speaking of money, schedule, resources. Of the latter (output), I am speaking of throughput, value earned, and metrics about "done". To its credit, the Agile movement has given a real lift to the output metrics. In fact, I call agile an output-centric methodology. There's less worship of the cost and schedule, and almost total focus on throughput (velocity x units/time) and "done" (no credit on the burn-down if it can't be delivered)
But, returning to for a moment to the Harvard Business Review, the point made in the article is that cause-and-effect are not all that straightforward. The article is repleat with regression plots showing the weak relationships between outcomes and what was thought to be the input drivers. Here at Musings, we've made the point about the difference between correlation (things moving together) and cause-effect (things moving because other things move).
So, even when you turn your focus to output, more so than input, you still may miss the cause for the effect of a better and more valuable project outcome.
To go there, you need metrics about integration of the parts (something often missed by the earned value crowd), and the emergent effects of all the parts working together (not entirely predictable). (Parts are parts, but it's the system!)In other words, to really shift from input to output, you need metrics about how the system of deliverable parts is going to make good on your project objectives.
Not altogether up on systems? See: Donella Meadows: Thinking in Systems.
