The Wrong Way to Plan a KPI Project

September 13, 2016 by Stacey Barr

The project team gets together and sets the scope of their KPI project. They outline the steps that need to be followed. They specify how much time to allow for each step. They define the report to be delivered at the end of the project. Then they call for quotes from KPI consultants. And even though this hasn’t worked in the past, they wonder why it doesn’t work again.

mountainroadtodeadend

The typical KPI project plan that I see most often contains sections that scope the project like this:

  1. Gather Data: about current industry reports and measures, current internal data collection and measures used, and user needs and preferences.
  2. Create Framework: about what measures should be used, and how they should relate to goals or outcomes.
  3. Provide Report: about recommended measures, the data dictionary, report designs, and future ideas.
  4. Methodology: about the approach to take, generally to follow something trivial like the SMART framework.
  5. Timing: about the number, length, and purpose of workshops to be conducted, who the people are to be involved, and deadlines.

This typical approach is riddled with assumptions, many of which are wrong. And it will only attract consultants who are merely facilitators, and only think they know about how to develop meaningful performance measures.

Assumption 1: The industry already has the answer.

This is the laziest way to decide what to measure: what is everyone else like us measuring? So few people take the harder but more successful way: what do we really need to measure, as evidence of our unique strategy? The industry doesn’t have the answer. Just because a measure is relevant to an industry, doesn’t mean it’s relevant to your organisation, right now. And just because the industry is measuring something, doesn’t automatically make it a good measure (or even a real measure).

At best, what the industry is measuring (and even what you’re already measuring) could build your list of potential measures. But to sort that list, you need to understand the results you want the measures for, in order to filter those measures to the few that are most relevant and feasible for you.

Assumption 2: KPI stakeholders know what they need.

If a consultant is needed to develop KPIs, it means the users of KPIs have no idea what they need. If they knew, they’d already have it. Or the project should be about data collection, not measure selection. People don’t know what to measure, because they don’t know how to design evidence of their most important – and usually intangible or complex – performance goals. Asking them won’t help.

Stakeholders – and not just users of the KPIs – need to be involved in two tasks specifically, and neither of these tasks is a consultation about their requirements.

  1. Education about what good performance measurement is, and how to develop good measures. Most people don’t know how to design meaningful measures.
  2. Implementing what they’ve learned to design the measures they need. This is the only way they will ‘own’ the chosen measures.

Assumption 3: A few half-day workshops is enough time.

Performance measure design is a very hard thing to think about, when you’re not good at it yet. In a culture where meetings are usually a waste of time and people are incredibly busy, workshops for KPIs are kept as short as possible. They allow for little more than brainstorming. And deadlines are usually way too tight, because the effort to get buy-in and to get data are underestimated.

But trying to save time in the measure design phase creates more time that is wasted, later. That’s because measures are chose that aren’t useful, people haven’t really bought into them, or they can’t be brought to life.

Assumption 4: Measurement is about measures.

Typical KPI projects put most of the effort into finding measures. Sure, they might start with a list of goals or a specific program or process that the measures are for. But the attention goes to answering the question “what could we measure?” And they seek to answer this question through industry research, internal stocktaking, and user consultation.

The problem with this is that a very important question is never asked. And whenever that important question isn’t asked and isn’t answered, the wrong measures are chosen for the results we want to measure. This very important question is “how would we recognise the results we want if they were happening now?” If we can’t answer this question, we don’t really understand why we need measures.

What does a KPI project scope need?

To avoid repeating the same mistakes and wasting even more time in finding the right measures, KPI projects need to include these:

  • A deliberate measure development methodology (no brainstorming). Ask consultants to explain theirs.
  • A step to make sure results are measurable before choosing measures.
  • Realistic timeframes for implementing the deliberate methodology.
  • The owners and users of the measures being trained in how to use the deliberate methodology.
  • The owners and users of the measures participating in the selection of measures, using the deliberate methodology.

DISCUSSION:

What’s your opinion about this? Do you agree or disagree? Why? Let’s chat on the Measure Up blog…

Facebooktwittergoogle_pluslinkedinmailby feather

Speak Your Mind

Your email address will not be published. Required fields are marked *

  1. David says:

    I’d start with measuring the performance that customers want. If KPIs don’t tell about the customer value being delivered, then they are not helping. In my business we got to one measure that did this; the measure was a critical outcome that customers sought; everything was about delivering against this measure. It was not an abstract number, but one that a customer was directly about customer experience.

  2. Barry says:

    One of your BEST POSTS EVER TRACEY! I AGREE WITH YOU TOTALLY ON ALL COUNTS. WITH YOUR PERMISSION I WILL USE THE “how would we recognise the results we want if they were happening now?”-QUESTION IN FUTURE . . .

  3. Kirk Mitchell says:

    I agree with your overall point and love your model. Where any of the orgs that tried to dictate the process IT functions? That is the only exception to your response as IT has frameworks and functional models that already outline key measures and KPMs. The additions to the model would be minor given the rigor already in place. The targets should be aligned to the maturity of the org and the appetite for improvement.

    If i took my team through your model, they scream that they were rethinking the obvious and wasting time with redundancy from a Lean perspective and I’d be hard pressed to make the case they were wrong. And even if you way was better, most IT orgs would be open to learning this through pain by making an incremental step forward, and then revisiting the approach. It’s a journey as they say, and many orgs choose NOT to do the best thing first for a range of legitimate reasons.

    • Stacey Barr says:

      The orgs I was talking about were NOT IT functions at all. But I’d suggest that even IT is at risk of measuring stuff just because everyone else does or just because the data is easy to get. And not because it aligns strongly to their current strategy, in the context of the organisation’s strategy.

Connect with Stacey


Haven’t found what you’re looking for? Want more information? Fill out the form below and I’ll get in touch with you as soon as possible.



*We respect your email privacy.
PO Box 422
Samford, Qld, 4520
Australia
Stacey Barr Pty Ltd
ACN: 129953635
Director: Stacey Barr
Simple Share Buttons