The Myth of Metrics

The world record for the 100 meter dash is 9.58 seconds. The world record for the mile is 3 minutes 43 seconds. The record for running a marathon is 2 hours and 3 minutes. The 100 meter freestyle swimming record is 44 seconds. The world land speed record is 760 miles per hour (1223 KmH).  And the list goes on and on. So what do these records have to do with ITSM? First these records are metrics: results of measurements. They measure the performance of processes (structured steps or actions undertaken to achieve an objective) and indicate the level of performance of people and vehicles doing the process. Second these data points reveal the myth of metrics. This myth is the belief that a person or organization can pick a data point or metric (desired result) before doing a process and through sheer willpower or force of action achieve that point. For example a person could not pick a time such as one (1) hour and say they are going to run a full length marathon in one hour. The only way that we could ever achieve a one hour marathon is to improve the process we use for preparing for, training for, and actually running a marathon. The limits of human and mechanical performance are dependent on the processes used to undertake an action or achieve certain objectives.

So why does the myth of metrics exist? This belief comes first from confusing results of measurements (metrics) with targets or objectives. Objectives and outcomes are actions or situations we aim to achieve or accomplish; they are not data points. Metrics or results are indicators of how close we were to our objectives. The myth also derives from a belief that a person or mechanism has complete control over a result after they complete an action. If I shoot an arrow at a target, I have absolutely no control over where the arrow actually lands (the result or metric) once it leaves the bow. The only part I have control over is the actions (process) I use to aim, draw the bow string and let the arrow fly. If I want to improve where the arrow actually lands, I have two choices: move the target or improve my processes.
So let’s look at a typical example of where the myth of metrics comes into play with ITSM. This is the measurement called Mean Time to Restore Service (MTRS). So many organizations believe that by simply picking an arbitrary target data point for MTRS they will be able to achieve that level of performance just because they set the target. Yet no one knows really why that number is the target. If I tell my Service Desk personnel and technicians that I want all incidents to be restored within 15 minutes, I am simply setting my people and organization up for failure and confusion. The only way I can improve my MTRS is not to set a random or arbitrary target, but to follow the Incident Management process, measure the results and use that as a baseline for control and improvement.
Dr Walter Shewhart (mentor of W Edwards Deming) showed this to be true when he developed the concepts behind statistical control in the 1920’s. The only way to improve quality (conformance to customer requirements) or results is to first conduct the process; then measure it to see if it is within its natural range. If it is in range (statistical control) nothing more is needed; if not then either change the objective or improve the process. The natural range of a result of an action cannot be decided before the action is done (the myth of metrics). It is the result of doing the action.
When it comes to providing quality and value to our customers through ITSM there is an order of operations that will help you avoid the myth of metrics:
1.    Define and design your ITSM processes
2.    Run the processes
3.    Measure the processes
4.    Baseline the results
5.    Run the process again
6.    Measure the process again
7.    Compare the second result to the first (baseline)
8.    Change the objective or improve the process
So focus on doing and improving your processes rather than achieving impractical, unattainable or arbitrary metrics and data points. Your customers will appreciate the effort.

Comments

Popular posts from this blog

The Role of Process Practitioner

The Difference between Change and Release Management

The ITIL Application Management Lifecycle and SDLC

Search This Blog