Processes 3: Measuring them

When I talk about "measuring" a process, I really mean monitoring or measuring the results. The point is to find out whether your process is succeeding or failing. In other words, Are you getting what you want?

In order to distinguish success from failure, you have to do three things: set up some objective criterion of what constitutes success at the beginning of a cycle (a year, a quarter, a project, or whatever); check at the end of the cycle to see how you did; and then publish the results to anyone who needs to know. I'll talk about each of these.

Define your metric 

Typically you measure each process by one or more performance metrics or Key Performance Indicators (KPIs). First you decide what to measure, and then you set a goal that you want to achieve. 

Maybe you decide to measure the effectiveness of the product development process by setting a target that 80% of your development projects will complete on time and on budget. 

Maybe you decide to measure the effectiveness of the shipping process by setting a target of 98% on-time-delivery of orders. 

In each case the idea is that if the process is working correctly, you will hit the target; and if you fail to hit the target, something might be wrong with the process. In principle you can choose almost anything as long as it makes sense – but let me qualify that remark. Some metric definitions are better than others.

There is an extensive literature about how to design process metrics, and I don't propose to summarize it all. But one of the most common bits of advice recommends defining "SMART metrics," where "SMART" is an acronym defined as follows:

• Specific: Say exactly what has to be done.
• Measurable: Make the goal quantitative, so you can measure whether you got there or how much progress you made.
• Achievable: Don't ask for the impossible, or nobody will bother to try.
• Relevant: Make sure the goal is connected to the work in some natural way.
• Time-bound: Define a goal to be completed by a specific point in the future, so everyone knows what target to aim at.

These are perfectly good criteria, and if you can define your metrics this way by all means do so. But some topics don't lend themselves to the SMART criteria; for example, in some cases the most meaningful measure of success might be qualitative or binary rather than quantitative. So if you find you need a shorter and more general list of criteria for your process metrics, I think the bare minimum list of features for any meaningful metric is this one instead:

• Achievable: Success has to be possible, or no-one will try.
• Non-trivial: Failure has to be possible, or no-one will care.
• Unambiguous: You have to be able to tell the difference between success and failure or your metric does you no good – because the whole point of a metric is to tell you whether you succeeded or failed.

Again, if you are able to define SMART goals, do it. But if you can't, at least make sure your goals are Achievable, Non-trivial, and Unambiguous. Those are – and have to be – the basics.

Measure your performance

This should be straightforward, shouldn't it? You defined your metric so that it's measurable. Go measure it.   😀

Publish your results

Now that you've found out how you are doing, tell the world. 

Not literally the whole world, of course. Don't tell your competitors. Don't post your results on the Internet, or on the front page of the daily newspaper. But inside your organization, transparency is a virtue. 

And really, even if you try to restrict the results to those who have a "need to know," that list is still pretty long. 

• All the functional managers responsible for the process have to be informed, because they can't manage effectively without feedback. 
• All the functional workers who implement the process have to be informed, because you cannot hold people responsible for meeting a goal without telling them what the goal is and whether they met it. 
• Top management have to be informed, because they are steering the whole ship and have to know if they are too close to an iceberg. 

So at that point, why not make the information available to anyone who wants to look it up? Post it on a bulletin board outside your office, and keep it updated as a normal routine. When you are transparent with your colleagues, it says that you trust them; and it makes them more likely to trust you. This is always a good thing. Or think of it this way: 

• If the numbers are good, you have no motive to hide them.
• If the numbers are bad because of reasons outside your control, you have no need to hide them.
• And if the numbers are bad because of reasons inside your control that you haven't addressed yet, you shouldn't be able to hide them. 

Never manage your work in a way that you are ashamed of, and you never have to be ashamed of the results. Even when you fail.

Is that all? Not quite. There are ways that KPIs can go badly wrong, if you aren't careful. But that's a different topic from the one in this post. What I have explained here are the formal criteria for any metrics that are useful and functional. On the other hand, if a KPI meets all the right formal criteria but you are measuring the wrong things, your results still won't be any help. That's the topic of my next post.