Metrics is becoming one of those Bullshit Bingo terms that are tossed around at most higher level staff meetings – like synergy, paradigm, and empowerment – but I think metrics are being given a raw deal through misuse.
I define metrics as information graphics that show performance trends. As such, they should, at the very least, do two things: show the data and tell a story based on the relationships of the data. When you depart from this, you end up with, well, a mess.
Case in point. Recently there was an exercise to produce “metrics” on how offices would be supporting projects in the coming year. The example provided was a colorful Gantt-type chart with red, yellow, and green bars, milestones, and deliverables plotted against the fiscal year. This “metric” failed in at least three areas:
- It did not show any data, nor was it based on any data. What it showed were the guesses of managers about the coming year and how their offices were going to perform. There was no math involved, no objective extrapolation from previous years, and no indication of the level of uncertainty of those guesses.
- It did not tell a convincing story. It did not objectively show data in a way that shows relationships. Instead it just showed a pretty picture of what managers wanted to say: things will be good, okay, bad, etc. You don’t need a metric for this, you need words.
- It wasted time. For those of you in Very Large Companies (or the Government), I’m sure you’ve already guessed that the example metric was in PowerPoint. And not as a plot of data, but as a whole shitload of drawing primitives to make it look like a Gantt chart.
Needless to say, this request was met with distain from working engineers and with a “let’s just get it done and over with” attitude from mid-level managers. I’m happy to say that most of the metrics were returned in Excel or Project format – the working engineer does’t have time to be fingerpainting in PowerPoint.
This was a metric to scoff at, but that shouldn’t dissuade you from thinking about metrics and how best to design and use them for your own projects. Just make sure you have real data, that you show real, meaningful relationships, and that you use a tool that is efficient and that presents the data honestly.
The best references on this are the books by Edward Tufte and by William S. Cleveland.
Bad Engineering 