Measuring project KPIs
I once received a copy of a post implementation review report that basically said: “We don’t know if we got the benefits from this project as the KPIs and other benefit measures were largely vague, unmeasurable or irrelevant.”
Overall, the conclusion was that the project had ‘failed’ to deliver the results and benefits expected. Not altogether surprising when you have ‘vague, unmeasurable and irrelevant’ goals. As the Cheshire Cat said to Alice in Wonderland, “If you don’t know where you’re going, any road will take you there!”
If there is one thing I hammer as vital to project success is the need to spend the time clearly and thoroughly define your desired business outcomes in clear, measurable terms and then focus your whole project on realising them. But many people don’t get it.
The second part of this story involves a workshop with some quite senior management. We were developing a business case for this client and defining their value proposition in clear, measurable terms. Their reaction was:
- “Too many benefits.” I wonder how many times they’ve said that of a project!
- “Too ambitious.” We might actually deal with the root problems if we take this approach. Can’t we just deal with the easy symptoms and look like we’re doing something?
- “Yeah, but what does the software do?” Thinking is hard, can’t we just adopt the software?
I was pleased to see that even the software expert said, “If there is anything I’ve learned from installing systems over the past 10 years it is that unless the business knows exactly what it is trying to achieve, the software installation will be a failure.”
What this experience makes clear is that software and demos are being used as a replacement for thinking. And this is the nub of the problem: that people need help to think and that so many of the problems we have are as a result of a reluctance or inability to think.
How do you address this problem?
