When I was working on IT strategy, something that always interested me was metrics: how were we to get objective measures of how well an IT business was doing. It turns out that this is surprisingly hard to do. Hardest of all criteria to measure was quality, the one that should have been the simplest.
It turns out that this is basically because nobody has a clue what quality means, and so people go between the extremes of customer satisfaction surveys (totally subjective) and immensely complex requirement to product linkage measures (objective in themselves, but entirely subjective when it comes to deciding what the requirements actually were). None of these are very satisfactory.
So, I had a think, and I realised that there is one unifying feature that both customer and supplier can agree on: risk. What happens in any procurement is that the customer had a risk, and they pay the supplier to mitigate it. So why not measure quality in terms of the amount of risk mitigated?
This is very easy to understand, but there’s something else. If the customer gives the supplier a 473 page requirement document, they are basically saying ‘we want the solution to look like this’. If they specify the risk they are facing, the supplier is free to provide the most effective mitigation whatever it may be. It may well be that the best solution is not technical at all, but a process change.
So: simple, precise, enabling. All good things. I’ve put up a draft paper, on which I would be very glad to receive comments.