Doing vs achieving

When you have a machine measuring its “performance” can be quite simple. Number of units produced per time frame. If that number goes up, the machine is more effective. But humans are not machines. Still we often measure their performance in a matter as if they were.

• * Phone calls per hour
• * Cases closed per hour
• * Number of new features delivered
• * Computers produced
• * and so on

Even though all of these can be argued to measure “performance” (do) they say nothing about what we actually “achieved” with the effort. What value, if any, did we create?

KPI’s and common faults with them

When someone walks in the room and introduces a new KPI (Key Performance Indicator) that we are going to measure I tend to be a bit reserved. The first reason being that we often fail at how we communicate and introduce them. I have several times witnessed an introduction going something like this:

– “We are going to start measuring the number of cases per agent”. Yea, that’s it… just that and then they walk away.

Why do I consider this a bad way… no, a horrible way, to introduce a KPI? Well, it explains absolutely nothing about “why”.

A normal reaction when you don’t get any explanation is that you try to figure one out. Given the KPI above and our obvious lack of transparency, the agents in question might start thinking things like

• * “Don’t they trust us?”
• * “Don’t they believe we actually work all day?”
• * “Do they want to figure out who has the fewest cases of us… why?… To terminate one of us?”

All of those could be legitimate reasons behind the KPI. I mean how should we know, we didn’t get any explanation. But the KPI could also be a result of a desire to make sure a small subset of individuals aren’t overloaded with work, since we genuinely care about them. Perhaps we want to identify knowledge gaps and provide knowledge sharing. The point is that the receivers of a badly communicated KPI have no way of knowing.

So when introducing a KPI be sure to explain why we do it. Explain what it will help us uncover and what our plan to fix it is if the KPI signals a problem.

The second reason for my reservations tend to be the fact that we often misuse or misunderstand the KPI’s we measure. Before we introduce a KPI we as the creators of it must understand what it is and what it isn’t. If we measure the number of new features delivered and mistake that for happy customers we risk basing decisions on incorrect data. Instead, most KPI’s are a measure of the output of a single process in an often very complicated weave of connected or dependent processes. It is not what that output actually “achieved”. So a KPI by itself, seldom gives a complete picture.

If you count the “cases per agent” but don’t have supporting measures of

• * what type of cases those are
• * how many people were involved in solving them
• * how long the cases took and how much of that time was outside the control of the agent in question

you could very easily end up thinking the agent delivering the most “value” to your customers is the worst one on the team.

So before using KPI’s make sure you

• * understand what you are measuring
• * understand what the number is showing you
• * understand that many KPI’s will form the behavior of your team, something that is often overlooked and undesirable. You measure the “number of cases per agent”, do you consider bad customer service to quickly close a lot of cases fast to be a good thing?
• * understand what the KPI is NOT showing you
• * are able to explain all of this to anyone else

After all this is in place and understood the final thing is to not loose focus on the fact that the KPI (most often) shows you with what “performance” something was “done”. It often tells you nothing of what was “achieved”.

If you care about what we “achieve” and not only what we “do” we need to think different.

KPI’s with a different focus

So if we want to instead look at the impact of the work we do and see what the team “achieved”, what kind of measurements could we use? Examples could include

• * Customer satisfaction
• * Daily Active Users
• * The daily support cases per 100 customers

-“Wait, what? Didn’t we just establish that measuring the number of support cases was bad?”

The difference might seem subtle but in reality it’s huge. In the first example we measured the number of cases the agent closed per day, the agents performance at closing cases. This KPI could improve by actual positive measures but it could also be improved by an agent “stressing and working overtime”, “creating cases in the system for quick and easy things the agents usually just fix” or at the worst “giving worse customer service and closing cases faster”. Nothing in the KPI itself focuses on us achieving some kind of positive impact for the customer which leads to them being happy repeat customers with our company.

In the second case we instead measure how many users are in need of support. For this measurement to be successful we want it to trend down. This allows us to make sure our work achieve an impact the results in less customers needing support. To reach this goal we could focus on things such as cleaning up technical debt, streamlining the setup process, implementing a great FAQ-system or we could work with other departments to make sure the entire process from sales to installation is coherent. The time saved by less people having to contact support could then be used to give the remaining number of customers who need support an even better experience.

The “Agile Leadership Toolkit” in the “Professional Scrum Series” uses the expression KVI’s (Key Value Indicator). Now, you could craft KPI’s that encapsulates the exact same thing. But what KVI’s does is to show a shift in focus that becomes an integral part of the KVI. From focusing on what we “do” to focusing on what we “achieve”. For that reason alone I see justification for the different naming. A KPI can be formed to focus on the impact of the customer and value for the company, or not, and still be a KPI. But a KVI can never NOT focus on this and still be a KVI.

3 steps to your first KVI

Step 1:

Create a clear customer impact

How does the customer benefit from this? Do we relieve a pain or do they gain something?

Example: By not requiring to contact support as much they save time and frustration. Those who still need to contact support will be greeted by agents with more time and energy to help solve their cases.

Step 2:

Visualize how this creates value for the company

How does the customer impact generate money for the company?

Example: More time to focus on the difficult cases enables us to leave the customers happier and for them to become ambassadors for our company bringing in more business.

Step 3:

Choose a metric that measures value

With the customer impact and company value known we can form our KVI. This process often iterative and with inputs from various members several KVI’s can tested over time to make the KVI better and better.

Co-create

For a team to feel ownership they should be part of identifying and creating the KVI. If a team know and stand behind a KVI of “The daily support cases per 100 customers” they will have this in their heads when designing solutions. They will do all they can to make sure their new solutions don’t negatively impact the KVI of the team.

To make sure you form inspirational KVI’s for the teams you can use the 5xI’s

• * Influence. The team are able to influence the metric
• * Insight. The metric is tangible and visual. Team members can update the metric themselves and are eager to follow the latest numbers.
• * Ideas. The metric is inspirational and causes ideas to thrive.
• * Intent. The intent behind the metric is clear. Team members can explain the purpose behind it.
• * Impact. The metric focuses on the customer.

All of a sudden we have started measuring what a team actually “achieves” instead of the performance of them “doing” stuff. All while adding more value to our customers and at the same time more purpose for our teams.