Skip to main content

Posts

The Meaning of IT

What does the IT in ITIL® stand for? This question may seem easy to answer. The IT stands for “information technology”. But what does that really mean? Is there more than one way to answer the question of what the IT in ITIL® means? I believe there are more than one context or meaning for IT and we must be aware of the distinct meanings. Let’s take a look at some of the ideas or concepts behind IT. ·         IT as “information technology” : This most basic use of IT refers to the physical and technological pieces and components made up of electronics and operating/machine software. E.g. A desktop computer is IT as “information technology”. ·        IT as “management information systems (MIS)” : Computerized components that are used to manage, control and govern information used to run a business or organization. E.g. A customer relationship management system is IT as “MIS”. ·          IT as “collection of applications and infrastructure” : This umbrella use of IT encom

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