I had come across ITIL once before, when working as a consultant for a government agency. This was a long running gig, in which we were responsible for the whole IT provision. After a couple of years the word "ITIL" got bandied around but it seemed to make no difference to our delivery of services. This briefing explained why: it takes three to five years to successfully implement ITIL. Which is quite astonishing given that these days it is rare for an IT project to last more twelve months. ITIL requires such a lot of time to implement because it is a framework for thinking about service delivery rather than a set of procedures. ITIL covers the what and to a certain extent the why; of course, the real work is in the how. Identifying discrete processes and documenting them is what takes the time, particularly as each will probably take several iterations to get them right. One useful tip I learnt is that anybody who mentions "ITIL compliance" is talking through their hat. Being a set of suggestions ITIL has nothing to comply with2.
The reason why ITIL can specify such a long time scale is that it is actually targeted at internal IT departments delivering services to their company's users. This assumption reveals itself it a number of ways. For instance, ITIL has SLAs - Service Level Agreements (the definition of Normal Service and permitted deviations) - because an agreement suffices when we have an IT department dealing with their business colleagues. This is a very bad fit with the prevalent model of IT today - outsourcing and consultancy - which is wholly driven by contracts and contractual negotiation. The next revision of ITIL (due 2007) apparently will address this aspect of service delivery.
By codifying and standardising terms ITIL provides a useful way of thinking about things. For instance it distinguishes Incident Management from Problem Management. Incident Management is when our users cannot connect to the system because the listener is down; restart the listener and the incident is closed. Normal service has been resumed. Problem Management on the other hand is when the listener has crashed three times in the last month and we need to find out why; is it because we don't have a separate listener for the extproc?
Another useful distinction is User and Customer. Both are consumers of our service. The user is the person who actually, um, uses the service whereas the customer is the one who pays for it. This means that the user and the customer have different priorities. The user needs the service to carry out their job, so they tend to be interested in quality, especially reliability. The customer has a set of targets for their business which our service helps them meet. Therefore they are interested in value for money. This matters because it is the customer who specifies the service. ITIL assumes the customer talks to the user, but this is not always the case. Another difference is that the IT Department mostly deals with the user. When it all goes horribly wrong it is the user who phones the Help Desk not the customer.
I find distinction between user and customer helpful because it illuminates several of my previous development projects. As a consultant I am exhorted to regard all the staff who work for my clients as customers. This is a good thing. But it is useful to distinguish between the people who use the system and the people who will fund its development. Given free rein in the Requirement Gathering stage users will tend to ask for the moon on a stick. We need the customer to remind them of the harsh financial realities. Alternatively it is not unknown for customers to seek to use a development project to drive through business change, riding roughshod over their own users' requirements. This is a harder one to handle: they are paying for it. All the IT team can do is assert the need for the users to be trained in the new way of working as well the new system. I think now I could look at any requirement and determine whether it is a user's requirement or a customer's requirement.
These are political rather than technical issues and ITIL is not going to solve them. However, by identifying the issues and defining responsibilities for both technical and business roles it seems to provide a useful start. I'm sufficiently enthused to consider doing the ITIL foundation course.
