Every field has its own set of terminology. Any business process can be described in plain English, but what the terms mean in a particular field could be completely different from common definitions. In the IT Infrastructure Library (ITIL®) management framework especially, there are a number of terms that need to be specifically used, rather than the colloquial English equivalent.

When I implement ITIL® processes in organizations, I start with a basic ITIL® training and one of the first ground rules is that people who are working in an ITIL® compliant organization must use ITIL® language only, and unlearn the equivalent jargon. For example, if my laptop is not working, it is commonly referred to as, "I have a problem with my laptop." But this phrase doesn't work in ITIL® because "problem" means something far greater than a laptop's condition, and so it uses another term: "incident."

Service

IT service is the foundation upon which the entire ITIL® framework is built. However, I have often heard people refer to a service in the wrong context.

A service is something of value that the customer enjoys. It is defined from the customer's standpoint and not from the organization that is providing it. The customer avails services such as the Internet service, email or cell phone service. The IT organization must refer to Internet, email and cell phones together as a service, rather than referring to the individual elements.

To run a cell phone service, the IT organization needs network services, tower services, server services and other application services. All of these enabling services cannot be referred to as IT services, but rather various elements that make the up the service that the customer enjoys.

For example, TrainSignal provides video training service to IT pros worldwide. So, the staff will refer to the services they offer as video training, instead of the application service that enables students to log in to the video training portal and the server service that hosts the application.

Incident

An incident refers to a disruption to an existing service. To quote the example of the cell phone service, if you are unable to make calls from your cell phone, the service is not working as it should. There is a breakdown of service. The disruption to a service  that the customer is entitled to use is called as an "incident."

As I mentioned earlier, IT staff refer to an incident by various names, like issue and problem. Since these terms have different definitions, it is imperative that the IT staff be trained to inculcate ITIL® language as their own.

Service request

Mixing one term with another interchangeably is another challenge. Many IT organizations do not differentiate between incidents and service requests, and they treat the two as one and the same. However, there is a herculean difference between the two. I will explain the difference and also justify why it is necessary to not mix these two terms.

An incident is a disruption to an existing service, and a service request is an add-on to the existing service. Examples could be an access request to an application, request to get a new laptop, and creation of a folder on a shared drive. Incidents are generally attached with stringent timelines for resolution (say four hours for a critical priority incident).

Service requests, on the other hand, are not-so-stringent, as there is no breakage of service. If incidents and service requests are conjoined, the IT staff is required to resolve service requests within stringent timelines. To do this, head count must increase to resolve service requests at an incident target timeline, and I'll go into SLAs later in this article. And more importantly, if an incident and a service request arrive at the same time, it's possible that the technician resolves the service request ahead of the incident, which is not ideal.

Incidents must be prioritized over service requests as incidents mean downtime to service.

Problem

A problem in ITIL® indicates something of far greater impact over an incident. A problem arises when the root cause of an incident is unknown, which translates to the incident being irresolvable. Also, if similar incidents repeat over a period of time, it is referred to as a problem as well.

Service level agreement (SLA) and operation level agreement (OLA)

A service-level agreement (SLA) is an agreement signed between the customer and the IT organization, to guarantee the level of services offered. operation-level agreement (OLA) is signed between internal teams within the IT organization to ensure that the targets agreed upon in the SLA are met. Customer does not see the OLA and it is internal to the organization.

For instance, if the SLA to deliver a service (say create a mailbox) is two business days, and to deliver the service, it takes three different teams within the IT organization to work sequentially, an OLA is created between the three teams to ensure that the SLA of two business days is achieved.

Utility and warranty

Any service that is developed has two pillars, without which the service has no meaning: utility and warranty. Utility is also referred to as "fit for purpose" and warranty as "fit for use."

Utility is the aspect of a service which ensures that the developed service does what it is supposed to do. Warranty ensures that the service is usable and conforms to the requirements of the customer.

Let me illustrate this with an example. With a cell phone service, a customer has the ability to make and receive calls. This is what the customer wanted to do (utility) when he subscribed to the service. To be able to use the service (warranty), the cell phone service must be available when he needs to use it, there must be sufficient capacity to place the call, the service obtained must be continuous without disruptions, and it must be secure.

Critical success factor (CSF)

Critical success factor (CSF) is the element of a service that needs to function absolutely as intended, in order to deem the service a success.

If you are offering a cell phone service, then the service must operate the way it was designed. For example, if a customer is placing a call to a certain number, the call must land at the intended number and not elsewhere. Placing this call at the right destination is one of the critical success factors for a cell phone service.

Let me illustrate CSFs further with a non-IT example. If I am driving my car, and turn the steering wheel towards the left side, I want the wheels to turn left as well and not right or remain straight. The alignment between the steering wheel and the wheels of my car is the critical success factor to my driving.

Key performance indicator (KPI)

Key performance indicators (KPI) show whether the service is succeeding or failing. As the name indicates, a KPI measures the performance of a service. When a service is designed, the designers also come up with KPIs that will be used during the operations to determine how the service is faring. If it is not performing the way it is expected to fare, then improvements must be made in order to bring the performance of the service on track.

In the cell phone service, one of the KPIs could be "percent decrease in call drop rate." This KPI relates to the number of active calls that get dropped. For the cell phone service to succeed, it is important that call drops be minimized. So, the identified KPI indicates what signals to watch for to ensure the success of a service. In this example, the call drop rate must decrease over a period of time. While designing the service, the designer must make provisions for recording the call drops, and calculating the call drop rate.

A service could have a number of KPIs. It is prudent to have a few strong KPIs that will indicate the success of a service. It is my experience that some service designers identify a number of KPIs without thinking about whether they can be measured or if they are giving the true pulse of the service. Having a number of irrelevant KPIs increases the cost of running a service and eats away a lot of the management time. It can also disorient the service improvement cycle.

Sign up for a free 3-day trial to get access to TrainSignal's entire training library, including project management training for ITIL® v3 Foundations.

ITIL® is a Registered Trade Mark of the Cabinet Office.