The Wrong Way to Plan a KPI Project

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.


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.


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

Upcoming KPI Training

>> USA, Washington DC, 25-27 June 2024

>> Africa, Dubai UAE, 13-15 August 2024

>> UK & Europe, Online Interactive, 30 Sep - 4 Oct 2024

>> North America, Online Interactive, 7-11 October 2024

Register for the next PuMP Blueprint Workshop near you

Reprinting Articles

You are welcome to use articles from the Measure Up blog, with these requirements

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.
Suite 117 Level 14,
167 Eagle Street,
Brisbane Qld 4000,
Stacey Barr Pty Ltd
ACN: 129953635
Director: Stacey Barr