Of all the possible organizational-improvement tools, metrics stands out for me as the most requested, misunderstood, feared—and useful. Defining metrics from a high level requires that I give you the What, Why, When, Where, Who, and How.

What

For me, metrics are a means of telling a complete story for the purpose of improving something. Usually, the idea is to improve an organization. Sometimes, though, you will want to focus on improving a process. In the end, anything you improve should align back to improvements that help the organization.

Metrics are a tool for improvement. By their nature, metrics use different levels of information to tell a story. Although I always strive to make this story comprehensive, it’s nearly impossible to capture everything. In most cases, I try to capture enough of what’s important to help with the improvement.

Metrics affect the improvement effort by helping you determine what was wrong in the first place, how well your efforts have worked (did you improve and did you improve as much as you wanted?), and what the new environment looks like after the change. I say “change” because improvement requires change. It doesn’t have to be drastic. It could mean that you do something new, you stop doing something, or you do something differently. But, improvement doesn’t come about without some change.

Albert Einstein said, “The definition of insanity is doing the same things, the same way, and expecting a different result.”

The following are just a few of the things a metrics program can help you do:

• Improve company “health” in a variety of areas
  • Improve customer satisfaction
  • Improve product/service value
  • Improve employee satisfaction
  • Improve process efficiency
  • Improve strategy, planning, and execution
• Provide a basis for change
  • What to change
  • When to change
  • How to change
• Lay a foundation for understanding your organization by providing insights into
  • strengths
  • problems
  • weaknesses
  • opportunities

Metrics are about change for the purpose of improvement. At least that’s how I use them. I’m an idealist, and you’ll see that reflected in my belief that metrics can be a powerful tool for improvement.

Why

Why metrics? To improve. I know I’ve already stated that. But, why metrics specifically? Why not use any of the other methods du jour (TQM, Six Sigma, Balanced Scorecard, etc.)? The funny thing is, any of the methods you choose will require you to use metrics—or at least the components of metrics. As a foundation, these improvement methods want you to create a baseline to see how well the improvement effort worked. All of these methods also want you to measure the amount of time, money, and effort that went into the improvement. But none of that will actually help you improve the thing you want to improve!

Metrics will provide insights into the thing you want to improve—be it a product, service, or process. This insight is valuable to those doing the job—fulfilling the need or providing the service. It helps them see their efforts in a new light, often as a more complete picture. It will help them find ways to improve. It will also help them see the benefits they’ve reaped. It will provide cherished feedback that the team can use to make continuous improvement a reality (instead of the latest catch-phrase).

Metrics also provides insights for upper management. It allows the team leader to market the improvement effort to those who control the funding. It shines a light on his efforts so he can gain support for the improvement efforts.

It also allows you to share your efforts with your customers in ways they easily understand. They gain insight to how things are changing for the better. Look at any new product release (I especially like Apple’s semi-annual announcements) and notice the amount of metrics sprinkled throughout.

Metrics provide insight. They also provide a level of legitimacy to your argument. All other things being equal, data is a tie breaker. If you and another department have competing requests for resources, the one with data wins.

When

Ideally, you’d not undertake a metrics effort of any significant scale until your organization could show that it was not suffering from organizational immaturity—the inability to take on enterprise-wide change. But, that’s only a prerequisite for implementing a program organization-wide. If you are in charge of a department or unit and you want to implement a department-wide metrics program, you only have to ensure that your unit is capable of the change.

Chances are very good that you already collect data and measures. You may have automated tools that track, collect, and even spit out reports full of data and measures. You may feed information into an annual report. You may already fulfill requests for specific measures. Depending on your industry, there may be well-worn standards that have been used for years (if not decades). These are not necessarily metrics per my definition, nor are creating such standards the intent of this book. Those data and measures are reported, but not used. They aren’t used to improve a process, product, or service.

It may be time for you to start using your information for your own benefit. It may be time for you to develop a metrics program. The major question you have to ask is, are you ready, willing, and able to change? Do you want to improve?

You’ll learn in this book that part of the “when” is collecting information on the thing you want to improve before you attempt to make it better—just as good researchers do. So, the when is before you start, during, and after your improvement efforts.

Where

The metrics program should reside with the owner of the data. I spend 80 percent of my workday developing metrics for others. I coach my customers through the design, creation, implementation, and maintenance of the metrics. In many cases, I also produce and publish their metrics. But I happily tell anyone who asks that I don’t own any of them. I am just helping the owners produce them. They are not mine. My greatest successes are when I can transfer the maintenance and publishing of the metrics to someone on the team who owns the metric. I then transition to a consultant role, helping them use and improve the metrics. This transition takes time—normally because of either a lack of skill or resources. But having the owner of the metric take over the production, maintenance, and publishing of them is always the ultimate goal for me.

So the metrics need to eventually reside in the data owner’s domain. That can be on their office walls. It can be on their shared computer drive. It can be on their web site. That’s where it belongs. But metrics show up in other places like annual reports, monthly meetings, and public web sites.

The publication of metrics will be up to the owner. The decision of where it will be published should be a careful decision based on the use of the metrics and the need for others to have access to the information. The more mature the organization, the more comfortable it will be with sharing the metrics. Many organizations are not mature enough to share metrics with their peers, their customers, and definitely not the public.

Who

I fulfill part of the “who” question on a daily basis. I am the producer of many of the metrics my organization uses. I am also the lead designer, collector, analyst, and publisher. But as stated in the Where section, I am always looking to transfer as much of this as possible to the metrics owner.

Who are the owners? The owners of the metrics are primarily those who are delivering the product, service, or carrying out the process. But ownership can be spread across the entire organization, depending on how you define the item being measured.

The key here isn’t so much who owns the metric but in who doesn’t. Don’t exclude the frontline worker. Don’t think the metric belongs to the CEO or upper management. If the metric is reported at those lofty heights, it doesn’t mean they should reside only there. Remember the purpose of metrics. Unless the CEO and top managers are the ones improving the processes (and they rarely directly deliver products or services), then you have to include the people carrying out the work—the ones that will be responsible for making the improvements actual work. How much harm can be done if upper management finds out that a department was using metrics for improvement but hadn’t shared them upstream? Some. But now imagine how much trouble can arise if a department finds out that upper management had been reviewing metrics about their processes, services, or products and they didn’t even know. Will that significantly harm the organization? I’m willing to bet it will.

If upper management wants metrics on a department, unit, process, service, or product, all of those involved should be included in the distribution of those metrics. They should also be involved in the design, creation, and publication of them.

The simple answer to “who?” is this: everyone in the organization, with the frontline workers being the primary “who.”

How

I offer you a comprehensive set of guidelines for developing metrics for improvement. I call them guidelines because “rules” would mean that I’m offering the only right way. As with most things, there’s more than one right way to develop metrics. The language, processes, and tools I offer are a result of more than twenty years of experience. That experience was full of successes and failures. I learned from both and am happy to share the results so you won’t have to fall into the same holes I did. And if you’re already in one of those holes, my advice is simple: stop digging and climb out.

What You’ll Find Inside

Having a common language for metrics and its components is an essential foundation for the conversation we'll engage in throughout this book. While putting this book together, and while thinking about all of the tools you can use to make your analysis and publishing of metrics easier, it struck me that there is another important distinction between metrics and other tools for improvement.

First and foremost, for me, metrics are in and of themselves tools for improvement. Even when using metrics to keep track of progress or predict future trends, metrics should be seen as a means for improvement. But that’s not enough to distinguish it from a mass of other tools out there. I’ve used many tools to solve organizational problems. Total Quality Management, the Capability Maturity Model, Lean, and Lean Six Sigma are a few. Each of these improvement methodologies also uses data and measures. Six Sigma uses data throughout its processes, not only to measure improvement but to determine what to improve. There are also measures of success and goal attainment. There are even measures which turn ordinary wishes into SMART (specific, measurable, attainable, realistic, and time-bound) goals.

Many of the tools designed around metrics are for statistical analysis. These powerful tools can be used to determine relationships between different data, causal relationships, and even determine the accuracy of data.

But “metrics,” for me, are much more and in some ways a bit less than a statistical analysis tool.

Metrics are not a statistician’s dream or an analyst’s favorite tool. The school of statistical analysis is much larger and deeper than I plan on digging. A common disclaimer I offer when teaching on metrics is that I am not a statistician, nor will the course include statistics. In these ways, metrics are a bit less.

But metrics are in many ways much more than statistics. They are a means of telling stories, and of providing valuable insights. Metrics are a tool for pointing out the correct direction to take when at a cross-roads—a choice between one improvement effort and another.

Metrics, for me, are the cornerstone of an organizational development program and a tool for answering the most important organizational questions.

It is these minor distinctions between metrics and other measurement-based tools for improvement that make this book a necessity. There are courses on statistics (one of my colleagues came to metrics by way of being a statistician), books on various analytical tools, and software tools developed for this purpose (SPSS, MiniTab, and Sigma XL, to name three). But there is little written or taught about the use of metrics. This deficiency has been partially addressed by Kaplan and Norton with their Balanced Scorecard methodology and by Dr. Dean Spitzer’s book Transforming Performance Measurement (AMACOM, 2007). I intend to take their efforts to their logical and necessary next step—making the design, creation, and use of metrics practical for anyone.

Metrics will make it possible for you to use data, measures, and information to improve your organization and lead to the key business results you need to be a success.

I hope this book helps you to develop metrics that in turn help you improve your organization. Regardless of the size or mission of your organization, metrics can be a powerful tool for improvement, and this book will make metrics as simple as possible.