Unit testing procurement performance measurement

I’d like to see an study showing the percentage of performance measurement initiatives that last longer than a year. I bet it’s not high.

My working theory is that the designers of performance measurement initiatives are too ambitious at the outset and set up measurements that never get used and therefore eventually stop getting collected and reported.

This scenario is analogous to building features into software that never get used.

To combat the tendency to over-design, techniques such as agile development are gaining acceptance in the software development community and serve as excellent models to assist us in developing better performance measurement systems.

One of the mantras of the agile methodology is to write unit tests for each component developed. This ensures that every single component built actually works before you attempt to put them together.

A recent article reports that a study of software development projects contained the following finding:

Key message: “measuring a [SIC] over 20 projects: if you have a large number of unit tests your code will be an order of magnitude less complex.”

The key message for designers of performance measurement systems is to start small when developing and implementing measurements, test them with your audience to ensure they serve business needs, and then move on to the next set of measurements.

The approach may seem pedestrian but you’ll be further ahead a year down the road.