My early lessons when I started my adventures with KPI modeling seem almost too obvious nowadays, but two are worth repeating.
1. Any time you plan to invest time and effort in a project, consider the size of the prize. If the prize does not justify the effort, don’t start.
2. If you are not sure, try a small sample, do it fast, if it works try a larger sample, then roll it out progressively as you can prove that it works.
Too often we see large and complex projects fail because they did not work, but only after hundreds of millions have been invested. All ground-breaking projects are risky. One way to limit the risk is to make it work on a small scale, learn the lessons cheaply, and plan a progressive roll-out to the rest.
An example immediately comes to mind.
In the late ’80’s Westpac, the large Australian Bank, set up a joint venture with IBM to revolutionize integrated customer focused banking software. A few years later they wrote off an undisclosed sum, but the Westpac share was around $180 million.
At the same time ANZ Bank, facing the same problem, decided to adapt working “Hogan” software progressively extending its capability from small US banks to large banks. It worked, from the first day it went live, for customers, staff and the bank, costing a fraction of the failed investment of their competitor.
Westpac/IBM attempted to solve “the problem of world hunger” in a single bite. ANZ found something that worked and adapted it progressively until it covered the whole bank.
There are many other examples, such as the failure of the New Zealand Police to develop an integrated national police information system. A laudable goal, but the failure led to a $100 million write-off for the New Zealand Government. The project was too complex and there was no “chicken test” to use Tom Peter’s metaphor.
KPI Models are risky because …
• they are new,
• the first choice of KPIs may be incorrect,
• the information may not be readily available,
• people may not welcome large scale change, etc.
So, while the prize is small, keep the risk low. Do your “chicken test” early.
KPI Models should start off small and experimental
This is the prime reason that The KPI Bible suggests a low risk route for model development.
Start with a chart on a large piece of paper, drawn in pencil, with an eraser handy. When you are confident that the logic is right and you have tested it with a small sample of data, you can take the next small step.
Convert your model into a spreadsheet, and test it over an extended period in the functional unit that it serves. Observe the response. Here are a few important questions.
• Is the result consistent with other observations of performance?
• How do people respond to changes in KPIs.
• Does decision making improve?
• Does performance improve?
• Do other units want to try it out?
Now you are ready to roll out the ideas to the rest of the organization. You have established credibility, and you have some keen customers.
The big step is now a low risk step
When you have a few models in the business process working you face the challenge of integrating it into the management system.
This may involve tricky and even controversial changes, so you need a secure platform before you move.
Here are a few of the potential challenges:
• New or streamlined data collection.
• Acceptance of the KPIs and the KPI model at the top level.
• Changes to the Chart of Accounts to align with the KPI model.
• Automatic feedback of KPI performance using dashboards.
This is the first point at which significant investment is required, but the task is well defined, and no longer theoretical.
You will still use the first steps of this process every time you need to make a strategic change in your business.
And the final good reason
In a changing world, business models and business structures are dynamic as customer preferences, market structures, and technologies develop. The KPIs, the KPI Model and the shape of the organization will change in response.
So finally I suggest you don’t set out a goal to achieve a perfect model, and set it in stone.
As we have learned from recent earthquakes in New Zealand, the structures that fail are brick and mortar, the ones that survive are flexible and bend in response to unreasonable forces.
My regular readers will notice a new website www.realkpis.com, and the new sourcebook for my collected KPI modeling work, The KPI Bible, is available there.