ITIL® – “Batteries (Best Practices) not Included!”

In this article Ian deciphers the ITIL guidance on incidents and service requests and explains why ITIL is not the source of best practices as claimed by so many experts in ITIL, at least not on this topic.

The phone rings at the Millennium Fangel Bank Service Desk and is answered on the second ring by Fred, one of the most dependable and expert agents. Fred greets the latest caller.

FRED: “Help Desk, oh sorry, Service Desk, just can’t get used to that new name”

With one keystroke Fred has opened and partially completed a new incident record, a willing receptacle for the customer’s information and current situation. Fred recognizes the voice of Wilfredo Morales, the Change Manager.

WILFREDO: ‘Hello Fred, I’m glad its you. Not sure if you’ve heard yet, but all hell broke loose at this morning’s Change meeting and I’ve been told I need to attend that upcoming conflict resolution class. Do you know when, and where it is?”

FRED: “Hi Wilfredo, yes I can help you with that. You need to know when and where the next conflict resolution class is, one moment”

FRED: “I just need to close out this incident record and open up a service request through a different screen, there we are, I’m ready for you”

This will be just one of 25 incident records Fred will open, only to close and replace with a service request on this fun-filled, busy Monday.

That night the usual support centered reports will generate a statistical analysis of the day’s activities, and management will see yet another gradual improvement in the average turnaround time, and cost, of managing ‘incidents’. More evidence of the success of the recently announced ITIL® initiative, or is it?

The Incident Genealogical Tree
The first modern evidence of the management of incidents as a formal discipline started in the early 1970s, when branches of emergency services in the United States developed the ‘Incident Command System (ICS)’ as a new approach to the problem of managing rapidly moving wildfires in the State of California. In 1989 the term was incorporated into one of the first IT Infrastructure library® (ITIL) publications as part of the Help Desk Management discussion. It has since become a key term addressed in every ITIL discussion, class, and project.

In previous ITIL-speak, a service request was generally ignored and discussed in passing as part of the incident management topic. In ITIL v3, for the first time, the humble service request is presented as a valid alternative to an incident, optionally recorded upon receiving a ‘call’ at the support area, the Service Desk.

The ITIL perspective
Vendors and consultants typically trumpet ITIL as the ‘de facto standard’ and go-to reference for guidance on IT Service Management ‘best practices’. The topics of incidents and service requests are discussed in ‘version 3’ of ITIL in the Service Operation publication, as two distinct processes: Incident Management (pages 46-55), and Request Fulfillment (pages 55-58).

On page 48, figure 4.2 (‘Incident Management process flow’), ITIL clearly positions a service request as something considered mid-stream within the incident management process flow, qualifying its inclusion on page 50 by explaining:

“Please note that the check for Service Requests in this process does not imply that Service Requests are incidents. This is simply recognition of the fact that Service Requests are sometimes incorrectly logged as incidents.”

Later, on page 52, in Section 4.2.5.7 ‘Investigation and Diagnosis’, while explaining this incident management activity, ITIL says, rather unfortunately:

“In the case of incidents where the user is just seeking information, the Service Desk should be able to provide this fairly quickly and resolve the service request”

On page 55, in section 4.3 the ‘Request Fulfillment’ process is introduced, and includes:

“The term ‘Service Request’ is used as a generic description for many varying types of demands that are placed upon the IT Department by the users.”

And later …

“… their (service request) scale and frequent, low-risk nature means that they are better handled by a separate process, rather than being allowed to congest and obstruct the normal Incident and Change Management processes.”

On page 56, section 4.3.2, while discussing the scope of Request Fulfillment, ITIL states:

“Some organizations will be comfortable to let the Service Requests be handled through their Incident Management processes (and tools) – with Service Requests being handled as a particular type of ‘incident’ (using a high-level categorization system to identify those ‘incidents’ that are in fact Service Requests).”

This seems to imply a service request can be a type of incident.

“In an organization where large numbers of Service Requests have to be handled, and where the actions to be taken to fulfill those requests are very varied or specialized, it may be appropriate to handle Service Requests as a completely separate work stream – and to record and manage them as a separate record type.”

Clear?

One last quote from ITIL before I offer my observations and decipher:

On page 57, section 4.3.7 as part of the ‘Information Management’ guidance for the Request Fulfillment process, ITIL describes the type of information a service request record should include as:

What service is being requested
Who requested and authorized the service
Which process will be used to fulfill the request
To whom it was assigned to and what action was taken
The date and time when the request was logged as well as the date and time of all actions taken
Closure details.

Conspicuous by its absence (unless you suppose its embedded and implied in the ‘what service’ part), is any information regarding the customer perspective. What is their situation, why did they call, what is the impact and urgency of the situation? It’s all very ‘inside-out’ to me.

Decipher Statement
Many ITIL followers and evangelists waited almost eleven years for the famed inclusion of the service request discussion. It seems to me they will have to wait a bit longer for it to be as clear and pragmatic as is needed given the humble service request can represent as much as 80% of the reason for IT work effort (more on that in a separate article).

ITIL positions the service request as an afterthought. Something associated with low-level effort and priority. It also offers a very confused positioning of a request, flip-flopping between it being managed as a type of incident, and a separate entity. In both cases it just doesn’t read as ‘best practice’.

At no point does ITIL consider the concept of initially recording a service request, and then listening to the customer’s situation before classifying the request based upon the situation and type of response needed.

By encouraging a separate work effort and process, ITIL adds unnecessary bureaucracy, and compounds the difficulty of reporting on all work performed for a client, and thus calculating the total cost of providing service to a client.

ITIL encourages more processes than are required. After all, a request and an incident each require resources that have an associated effort, cost and response target. They each drive work effort and typically involve the same pool of resources. Why not manage them as common workload through a combined service request management ‘process’?

Additionally, having one consistent approach would enable the connecting of service requests to a catalog (brochure of services) component at the customer facing end, making that actionable, and a workload management component in the back office.

Perhaps worse of all, ITIL seems ignorant of the fact the larger percentage of workload drivers for a service provider, especially an IT organization, are non-incident related calls. And, this is where the greatest improvement in quality of service and operational efficiencies is to be had for an IT Service Management initiative.

Bonus Element: Best Practice Statements Offered by the USMBOK:
The following guidance is a subset offered by the universal service management body of knowledge (USMBOK™) with respect to managing service requests:

A service request is defined as any request from a customer community that may require resources from the Service Provider Organization (SPO)
A service request is the single input to the service provisioning system
A service request can be processed by a service transaction engine and require no manual intervention
There are at least eight common types of service requests
A service request is the container for a service encounter and moments of truth
The response to a service request is best co-designed with the involvement of the affected customers and users, and respondents
An incident is one type of service request

Using the USMBOK guidance, and not ITIL, Fred’s response may have been quite different:

Fred would have classified the request as ‘request for information’ and optionally sub-classified it based upon the customer situation.

FRED: “Hello, Service Desk… how can I help you?”

With one keystroke Fred has opened and partially completed a new service request record.

FRED: “Hi Wilfredo, yes I can help you with that. You need to know when and where the next conflict resolution class is, one moment”

Fred continues to ask Wilfredo for some background context, sets the impact and urgency, and looks up the request in the service request catalog to find he is entitled to respond on behalf of the organization. He finds the information he needs in the online training calendar, relays this to Wilfredo, and attaches a copy to the service request record.

FRED: “Good. Glad I could help. Let me send you that information attached to a record of our call. If I may, could I include a quick satisfaction survey as to the service I’ve provided to you?”

There is no opening and closing of unnecessary incident records. There is one receptacle, the service request, for all work performed on behalf of the customer, no matter how trivial it may seem. No pollution of the statistics. In fact the statistical analysis is easier to collate and more relevant to the work effort and needs of management decision-making.

The true burden a customer or community places on the service provider is easier to understand, and the language and management of the response effort simpler. A better practice? I hope so, because it represents how many, if not the majority of service support organizations operate today, prior to perhaps re-engineering their processes to be more ‘ITIL compatible’.

Final Word
It concerns me that from evidence posted on blogs, presented at conferences, written in articles, and replayed by clients, experts in ITIL, are indeed expert in what is in ITIL, but not with respect to unclear or ambiguous statements, or poor advice. Leveraging ITIL requires effort and careful analysis to separate out the good, from the bad, and just plain ugly statements.

Are you getting this type of decipher from your consultants, or are they representing the ITIL guidance as the definitive statement, ‘de facto standard’ best practice framework for IT Service Management?