Skip to main content

Posts

Reference Models

In 1999 the US Federal Government took a step toward improving the quality, performance, delivery and support of IT-based services. This step was the creation of the Federal Enterprise Architecture Framework (FEAF).  This framework consists of five reference models. A reference model is an abstract or logical framework or structure that describes the interconnections between ideas, concepts, elements or components that make up a whole system. We can look to the FEAF reference models as a guide for how we might approach an ITSM implementation regardless of industry or organizational structure. Performance Reference Model : Used to measure the performance of major IT investments  This equates to a CSI or Metrics Program  Business Reference Model : Process-driven structure that describe business operations regardless of the organization that performs them This equates to a Service Portfolio framework Services Reference Model : Classification of service components an

Service Measurement

Before my life as an ITSM professor, I was responsible for delivering the monthly reports on IT at a large specialty retailer organization with multiple remote locations in several states across America.   I delivered many of the standard reports for Service Desk, Change Management and System Availability.   System availability was a standard report that reviewed from a system / hardware perspective just how available the systems and their supporting components were throughout the month.   This was delivered in percentages and the goal was to maintain 100% infrastructure availability. Even though many of the individual systems and components were meeting their required SLAs, our customers were still not satisfied with the availability and performance of critical services.   W e needed to re-address what should we be measuring and how should we be reporting achievements back to the business and customers. W e decided to report on the end to end delivery of our services and the a

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 w

Process Improvement Paths

When it comes to processes, W. Edwards Deming stated that there are only two choices: execute the process or improve the process. When it comes to improving a process we have three basic paths we can follow: develop the process (if it does not exist), redesign the process (if it is sore need of fixing) or improve the process (tweaking it in incremental ways). So let’s explore each of these paths in a little more depth. Develop the Process: This path occurs when you really do not have a process. You might have some loosely followed procedures or perhaps steps that people follow in their heads. There is no formally defined, developed or documented process. This path allows you to start from the beginning by gathering requirements for the process, creating a process definition document and then implementing the process. This path takes the longest time and in some ways the most work. Redesign the Process: This path occurs when the process you have in place just does not provid

Single to Double Loop Learning

C hris Argyris is one of the most important and influential thinkers in the last 100 years. Yet, few people are aware of his efforts in organizational development and human behavior. Argyris wrote about a number of different areas of organizational change management. Perhaps one of his most important contributions has been in the area of Single-loop and Double-loop learning for individuals and organizations. Single-loop learning is when an individual or group undertakes an action and the result is not what they expect or believe be the result should be. So they go about “correcting” their approach on the assumption that they must have done something “wrong” the first time. As a result of the “correction” they expect a different result. Some of you may recognize this as the classic definition of “insanity”. Others have called these “self-fulfilling” prophecies. Doing the same kinds of things over and over and expecting different results. Single-loop Learning results from creating what

Questions about OLAs and SLAs

The Professor was recently asked about the following very interesting situation. In my organization, we have a service desk that is not part of the main IT department.  Since we are a service desk solution provider, it is actually in one of our businesses units.  So our IT department has chosen to take advantage of that in-place service desk to effectively also be the service desk for internal employees.   Is this a situation where an operational level agreement (OLA) applies?    Or are the “parts” of the internal organization too far apart and a service level agreement (SLA) is more appropriate? I think the idea is that the OLA applies to different internal groups within IT?   Is that true? Let’s first define these terms and then apply them to this situation. An SLA is an agreement between a service provider and a customer. In the case of the service desk that is in one of the company’s business units, that service desk is a Type I (internal) service provider. Since ITIL is non-p

ITIL at the Service Desk

Trends such as mobile computing, consumerization (also known as bring your own device (BYOD), and cloud computing are having a dramatic impact on the service desk. These trends are prompting many organizations to evaluate and improve their existing service management processes , or implement new processes where needed, and to rethink the role the service desk plays in implementing, executing and improving these processes. It would be easy to look at these trends and think of them only as the deployment of new technologies but there are bigger considerations at stake. What services are these technologies enabling? What business processes do these services underpin? How is the business impacted when these services are interrupted? An important key performance indicator (KPI) for service catalog management is whether the service desk has the information that it needs about those services and their associated interfaces and dependencies. This is because the service desk plays