Skip to main content

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.


Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you. Roles and Responsibilities: Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance. Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables.  An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and th

Four Service Characteristics

Recently I came across several articles by researchers and experts that laid out definitions and characteristics of services. ITIL provides us with a definition that can help drive the creation of value-laden services: A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. An area that ITIL is not so clear is in terms of service characteristics. Several researchers and experts put forth that services have four basic characteristics (IHIP): ·          Intangibility—Services are the results of actions not things. They have no physical presence and represent a logical set of elements. One way to think of service is “work done for others.” ·          Heterogeneity—Also known as “variability”; services are unique items because of the mechanisms used to deliver services-that is people. Because the people element adds variability, the service is variable. This holds true especially for the v

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service". I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize: SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle. ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the