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.

The Four Ps of Service Design - It’s not all about Technology

People ask me why I think that many designs and projects often fail. The most common answer is from a lack of preparation and management. Many IT organizations just think about the technology (product) implementation and fail to understand the risks of not planning for the effective and efficient use of the four Ps: People, Process, Products (services, technology and tools) and Partners (suppliers, manufacturers and vendors). A holistic approach should be adopted for all Service Design aspects and areas to ensure consistency and integration within all activities and processes across the entire IT environment, providing end to end business-related functionality and quality. (SD 2.4.2) People: Have to have proper skills and possess the necessary competencies in order to get involved in the provision of IT services. The right skills, the right knowledge, the right level of experience must be kept current and aligned to the business needs. Products: These are the technology managem

What Is A Service Offering?

The ITIL4 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 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. Note: Goods may not always be provided for every Service Offe

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 the

Search