IT, Customer and User – A Bermuda Triangle

ITIL has a long history of being less than concise, sometimes downright ambiguous. ITIL ‘dinosaurs’ like myself my fondly remember the sleep inducing ITIL v1 books mainly due to its sometimes incomprehensible mumbo-jumbo and its apparent lack of structure, especially across the books. Or how about the v2 books where the chapter definition of a Release, did not reflect the one in the glossary of terms in the back?

Although v3 and 2011 are a lot better there is still some ambiguity and\or unclarity the use of terms and definitions, especially across the books. Personally for instance I find it a shame that the terms ‘utility’ and ‘warranty’ aren’t used outside the Strategy book (for impact\urgency classification, testing & evaluation, KPIs …).

I often say that certain sections in the book (and Service Strategy would be the main example of this) require you to read those two or three or more times. Every time you read it you’ll get a better understanding and develop a better ‘view’ of how it fits with the rest of ITIL. Thus eventually you build your own understanding or model of ITIL and its processes. Another good explanation is the old analogy of the ITIL processes as tectonic plates: they move, shift, bump and overlap each other. It is up to you to define the boundary between them (for instance between Demand Management and Business Capacity Management, Business Relationship Management and Service Level Management, Service Improvement Programs and CSI, Change Management and Transition Planning & Support, …).

One of the enduring ‘misunderstandings’ is that of Customer vs. User. The definition is simple enough though. A Customer is someone (i.e. an individual) who represents the business (i.e. a group, team, function, unit). On behalf of the business they will make decisions (in Service Level Management, in Change Management, …), but they will need to pay for those decisions. In other word a Customer is a decision-making, budget-holder.

The User by contrast is someone who uses the IT (Service). As such they only represent themselves and do not specifically make decisions or pay for those. Hence the difference between Request Fulfilment and Change Management. Request Fulfilment deals with predetermined, pre-costed, standard requests from the User, whereas anything new, different or unknown has to go through Change Management (and the CAB and most likely the Customer).

Roughly speaking Operations deals with Users (as it is business-as-usual and only limited decision-making is required, within specific parameter), whereas Strategy\Design\Transition involves the Customer for definition and decision-making (although the User will need to be involved, if only for someone to represent their interests and points-of-view).

Note though that most Customers will also be Users, as they normally will have a desktop\laptop\mobile phone or other IT device that they use. Even IT staff can be considered Users as they are also using IT devices and services. 

So, the Customer will decide (through Service Level Requirements) that they want an e-mail service with specific utility, for 5 days-a-week, at 99.9% availability, with a capacity for 1,500 users, storage for 7 years (i.e. warranty) etc. etc. Through the service level negotiations this will be agreed, with the IT Service Provider in an SLA, including costs and charges. Once Design and Transition are completed, the IT Service Provider will now deliver this service to the Users and they can use it (as defined by the Customer).

Now, if there is something wrong with the service (i.e. unavailable, no storage-space …) the user should notify the IT provider, through the Service Desk (incident management or request fulfilment, …). But if the Users want something which is outside the current agreed service, they should not notify (or rather as it is in most cases: complain) to IT, but instead bring this to the attention of the Customer, who can then negotiate the service change with the IT provider.

And here is where the Bermuda Triangle analogy comes from, as this line of communication is often missing. If Users do not directly communicate with the Customer (or vice versa) that IT gets stuck between a rock and a hard place. On the one had they have to deliver the agreed (with the Customer) service (often cut down on cost) but have to live up to the expectation of the Users (based on phenomenal quality).

Therefore it is in the IT provider’s interest to establish the lines of communication between Customer and Users. This can be done by performing User Satisfaction Surveys (and reporting this to the Customer), creating User Focal Groups (as part of Design), routinely performing User Acceptance Testing (in Transition) and involving the User in CAB, Post-Implementation-Reviews and CSI.

Ultimately we all want the same thing (service that deliver value to the business), but sometimes we not only approach it from different angle, but from different planets.

the ITIL Zealot