The (Ongoing) Evolution of the ITIL Request

April 27, 2009
By Rob England

From no standing at all to an equal peer of Incident, the humble Request has grown in importance with each new version of ITIL, writes ITSMWatch columnist Rob England (a.k.a., The IT Skeptic).

Two years ago, we looked at the evolution of the ITIL Request here on ITSMWatch. Since then, discussions on my blog have reshaped some of the ideas. Let's revisit them:

In ITIL v1, there was no recognised “process” for Incident Management, just a function called Help Desk, which was responsible for “first level incident support, advice and acts as a day-to-day contact point for users of IT services”. So, only Incidents were recognised as a processed object

In ITIL v2, Incident Management became a recognised process. (Whether or not this is a correct use of the word process is a discussion for another day). Mentioned in passing was the possibility of a call being a Service Request rather than an Incident, at which point the process branched to ... well, nothing. The Service Request branch hung into space, dangling wires and reinforcing steel into the void. Service Request process was never defined.

What came first was never defined either. When someone calls, is the call an Incident until proven to be a Service Request? Or is it a Request until it reveals itself to be an Incident? Or is it something else (a call, a contact) until it yields to classification? This was left to the implementers (or software vendors) to decide.

v3

Now ITIL v3 elevates the Service Request to equal billing with the Incident. In fact, if importance can be measured by number of pages then Service Requests get slightly more of the “Peas Book” (Service Transition) than Incidents do.

This is a great step forward but I believe it is not the final word. v3 still delineates between Incident and not-Incident as the two categories. That is, Service Requests are some kind of miscellaneous category for everything that is not actually an unexpected interruption to service. The two processes are quite separate. This does not fit well with my experience of reality. Admittedly, my reality has a few kinks, but in this case I speak on behalf of clients who feel the same way. For many service desks, Incidents are not the main part of their function.

I predict that ITIL v4 (if there is one) will finally recognise that the service desk deals with generic Requests/Tickets/Issues. These Requests have multiple categories or classes. Each class is a variant of a more general process that applies to all of them, in much the same way as there are several categories of Change, which all undergo variants of the general Change process.

I published a list in the article two years ago. Since then, I realised that the list had missed one―Fault. So, I thought I'd update the list for you. This revised list is constructed based on the concept that each class of request exists because it is a variant of the core Request Fulfilment Process, e.g., Complaints will be dealt with differently to Proposals. Different people and groups, different procedure, different reporting, different service levels. That is, I derived the different classes or categories based on the process being different. If two types of request use the same process then I decided they are synonyms.

New Taxonomy

After discussions on the blog, I also decided they needed to be re-grouped into a newly named hierarchy. I came up with three groups:

Action: I'd like to say “Service” but man is that an exhausted word!

Support: not everything will be/needs to be fixed so not Repair

Input: the user is contributing

Here is my taxonomy of these new Request classes:

Action -

Provisioning

Booking

Ordering

Change

Work

upport -

Incident

Fault

Help

Advice

Input -

Proposal

Suggestion

Feedback

Complaint

Let’s elaborate a little on what some of these mean:

Provisioning: User requires access to a service or part of a service, e.g., a security permission, a menu option, a token, a digital certificate, a client install, a desktop device, a phone, etc.

Booking: Scheduled attendance at training, seminar, meeting, reservation of a resource, annual leave.

Ordering: Books, desks, catering, stationery, travel.

Change: as defined by Change Management, typically means change to a configuration item (CI). Some organisations allow users to open RFCs directly, others have some form of prior request entity.

Work: tasks that falls outside change management. Run a report. Move a PC. Install a projector.

Incident: an unplanned interruption to an IT service or reduction in the quality of an IT service.

Fault: failure or detected imminent failure of a CI; no service impact (yet). Only users within IT would be expected to report these, or an automated tool. If confirmed, it will spawn a Problem. This class was much debated on the blog. An Incident is by definition something that has already impacted the Service, a Fault hasn’t. Both have varying priorities and urgencies and impacts. But the processes differ. If you are uncomfortable with this, ignore me and treat Incident and Fault as synonyms. Twelve is a nicer number of classes than 13 anyway.

Help: correcting data arising from user error (NOT from a Problem). Restoring a deleted file, untangling a mess.

Advice: how do I … ? Should I … ? Which is the best way to … ?

Proposal: the service desk can be a front-end to the demand component of project portfolio management. Think of it as a Request For Project.

Suggestion: idea, requirement, request. Something less formal or evolved than a proposal but might lead to one.

Feedback: praise, reported experience, remarks.

Complaint: poor experience. (Of course, Complaint had to be #13.)

Based on the principle of distinguishing classes by differing processes, the first three classes (Provisioning, Booking, Ordering) could well break into a number of subclasses. There are other types of contacts to the Service Desk that aren't requests at all. The classic is a follow-up on a request. Feedback that doesn't require action would also not be a request.

Once we come to see an Incident as just one class of a more general Request, then the service desk’s Request Management process will make more sense and map better to reality. SLAs will define responsiveness in terms of the classes of Request. (I think restoration of service should be defined as part of the Availability Service Level Objective, not the Responsiveness Service Level Objective). Management of Incidents (the restoration of service, incident matching) may still fall to a specialist Incident Manager, or it might be part of the role of the Request Manager.

Incidentally (no pun intended), I still encounter examples of SLA objectives for Restoration of Service. Outages will be prioritised based on their severity, but they will be restored as soon as they can be restored and no sooner. “Priority 1 incidents must be resolved within one hour” is like saying “Fires must be extinguished within three minutes” or “Missing climbers must be found within an hour”.

We’ll find them when we find them. It makes sense to define responsiveness by severity/priority/impact, but not restoration. That is, we define how much resource will be assigned to it, how the communications plan changes, how escalation and supervision will be heightened, and other aspects of how we respond. We can’t promise timeframes.

From a narrow focus on restoration of service, the understanding of the service desk has grown with each revision of ITIL, and with it the importance of the Request. Extrapolating the trend suggests that next time ITIL is revised the Request will truly have its day.

Along with the IT Skeptic, the IT Swami is an alter-ego of the author, who resides on the IT Skeptioc Blog and offers prognostications about IT’s future to the few who listen.