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.

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, which is people. Because the people element adds variability, the service is variable. This holds true, especially for the value proposition—not eve...

What Is A Service Offering?

The ITIL 4 Best Practice Guidance defines a “Service Offering” as a description of one or more services designed to address the needs of a target customer or group. As a service provider, we can’t stop there! We must know what the contracts of our service offering are and be able to put them into context as required by the customer. Let’s explore the three elements that comprise a Service Offering. A “Service Offering” may include: Goods, Access to Resources, and Service Actions 1. Goods – When we think of “Goods” within a service offering these are the items where ownership is transferred to the consumer and the consumer takes responsibility for the future use of these goods. Example of goods that are being provided in the offering – If this is a hotel service then toiletries or chocolates are yours to take with you. You the consumer own these and they are yours to take with you. ...

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

This article was originally published in 2015. With the Introduction of ITIL 4, some of this best practice has changed. See ITIL 4 and the Evolving Role of Roles . Updated Definitions in ITIL 4: Process Owner: In ITIL 4, the concept of 'processes' has expanded into broader 'practices.' Consequently, the Process Owner is now often referred to as the 'Practice Owner.' This individual is accountable for the overall design, performance, integration, and improvement of a specific practice within the organization. They ensure that the practice achieves its intended outcomes and aligns with the organization's objectives. Process Manager: Now commonly known as the 'Practice Manager' in ITIL 4, this role is responsible for the day-to-day management of the practice. The Practice Manager ensures that activities are carried out as intended, manages resources assigned to the practice, and oversees the practitioners performing the work. Process Practit...

Search