What Have We Learned From ITIL?

I’ve been at least peripherally involved with IT Service Management methodologies at two institutions over the past decade. At the UW I was responsible for the creation of the first IT Service Catalog and began the process of creating a service request process. Here at Chicago one of my first accomplishments was finishing up the creation of our IT Service Catalog and selecting and procuring an ITSM tool. I’m now working with others to improve our implementation and use of that tool.

In that context I’ve been thinking about ITIL and how it fits with our evolving notions of agile development, DevOps, and what Gartner calls “bi-modal IT”. ITIL and other now traditional ITSM methodologies were built to combat the chaotic world of IT in the 1980s and 90s as information technology began to rule the world. ITIL offers standardized processes designed to give IT organizations control over their work and the environments they manage.

As is the way with methodologies, even though ITIL was meant as a set of methods you could pick from and tailor to your needs, it has been taken as more of a religious crusade. It’s not uncommon for IT shops to build up a massive set of bureaucratic processes based on the ITIL language that, instead of providing responsivene IT, become yet another way for IT to stand in the way of people getting work done.

I’m not a huge fan of ITIL and its methods, and I think it’s largely become an artifact of an older way of thinking about IT processes, but I do think there are some valuable lessons we’ve learned from ITIL over the years, and we shouldn’t overlook those in our rush to the newer ways of working. So I’m going to attempt to document some of the things I’ve personally found valuable from working with ITIL. Feel free to add to the list or differ in the comments.

• Incidents and Problems are not the same thing. Incidents are reports of someone having a hard time. Problems are things that have gone wrong and need fixing.
• Service Requests are not incidents – they are requests from people for the things that you regularly provide – the things in your Service Catalog. A request for a new email account is a service request. A request for a project to build a new email infrastructure is not a service request (unless that’s the business you’re in). Service requests should be able to be automated and not treated as artisanal creative work.
• Life goes better when you have some process to control changes in your IT environment. In the agile and DevOps world continually deployed changes are governed by automated tests and easy rollbacks, which are considered pre-approved changes in the ITIL world.
• It’s important to measure your service usage. Metrics can help plan for capacity, help understand how people are using services (and where there are issues), and help you know when it’s time to retire or replace a service instead of continuing to invest in it.

What else?