• Choose a category
• All
• Classic-Fiction

When you get the “I’ll know it when I see it” argument from a higher-up, stay strong. The best way to help customers identify what they really want is to help them identify their root question. In Douglas Hubbard’s excellent book, How to Measure Anything: Finding the Value of Intangibles in Business (Wiley, 2010), the author introduces his methodology for identifying what people really want to know.

Hubbard uses what he calls a “clarification chain,” which allows you to keep digging deeper into what matters to the client. He asks simply, “What do you mean by x?” In his example of working with the Department of Veterans Affairs, he ended up holding multiple workshops just to get to the root question. Hubbard doesn’t require a root question per se, he stops well short. But his book is about measures, not metrics (in our definition). The good news is that he is totally correct about being able to measure anything. I’ve used his book numerous times. Sometimes when I work with a client, we run into a roadblock after we’ve identified the question, designed a plausible metric, and determined the information we need. Often, the client doesn’t want to get past the picture because she doesn’t believe we can measure what we need to compile the information. I pull out Douglas Hubbard’s book from the shelf and assure her that we can really measure anything. This is even easier because with the root question, metric, and information requirements in hand, identifying the measures become very simple.

So, it’s not impossible to start at the bottom, it’s just not the wise choice.

Designing Metrics

The How

Now that we have a common language to communicate with, the next step is to discuss how to proceed. I’ve read numerous books, articles, and blog posts on Balanced Scorecards, Performance Measures, and Metrics for Improvement. Each pushes the reader to use the author’s methods and tools. But, I haven’t found one yet that puts “how to develop a metric from scratch” into plain English. It’s about time someone did.

In this chapter we’ll cover the following:

How to form a root question—the right root question

How to develop a metric by drawing a picture

How to flesh out the information, measures, and data needed to make the picture

How to collect data, measures, and information

This will seem like a lot of work (and it is), but I guarantee you that if you follow this method you will save an enormous amount of time and effort in the long run. Most of your savings will come from less rework, less frustration, and less dissatisfaction with the metrics you develop.

Think of it this way: You can build a house by first creating a blueprint to ensure you get the house that you want. Or you can just order a lot of lumber and supplies and make it up as you go along. This process doesn’t work when building a house or developing software. It requires discipline to do the groundwork first. It will be well worth it. I’ve never seen anyone disappointed because they had a well thought-out plan, but I’ve helped many programmers try to unravel the spaghetti code they ended up with because they started programming before they knew what the requirements were.

While programmers have improved at upfront planning, and builders would never think to just start hammering away, sadly those seeking to use metrics still want to skip the requirements phase.

So let’s start working on that blueprint.

Getting to the Root Question

Before you can design a metric, you have to first identify the root question: What is the real driving need? In the service desk example in the last chapter, the director asked, “Is the service desk responsive to our customers?” The analyst took that question and developed a decent metric with it—percentage of service calls abandoned. He didn’t do a great job, however, because he didn’t make a picture (metric) first. Instead, he went straight to collecting data and measures. He also didn’t determine if the question was a root question or