Login
Studying ITIL Foundations: What I learned and what I questioned
Working in information technology, I have been aware of ITIL for a while but had never formally studied it. I attended a three-day training course and passed the ITIL Foundation exam. Here, I share my reflections and my review of ITIL.
ITIL (Information Technology Infrastructure Library) originated in the 1980s, developed by an agency of the UK government as a way to standardise IT service management practices. It’s now owned by AXELOS and used globally across a range of industries, including Higher Education. The University of Edinburgh uses ITIL to structure aspects of organisational governance as well as many of its processes. I was curious to learn about ITIL as I felt it would help me make sense of the way some things work within ISG.
Read more about ITIL:
I studied the ITIL 4 Foundation course, which covers concepts like the Service Value System, value co-creation between provider and consumer, the four dimensions of service management, guiding principles, and key ITIL practices like the service desk, service request management, incident management and change management. Going through the course and completing the exam, I came away with several reflections about ITIL and its application to modern digital services.
First rule of ITIL: It’s not supposed to just be about IT (but it mainly is)
For a discipline with IT in its title, it was surprising to learn that ITIL is actually intended as a more generic service management framework, supposed to be applicable to non-technical as well as technical services. ITIL’s IT roots were clear, however, as many of the examples intended to ground the abstract concepts related to management of very traditional technical services, and it was hard to visualise practices like deployment management applied to non-technical realms. Conversely, it was difficult to visualise ITIL flexing to be applicable to the management of emergent technical services, such as machine or AI-based services with rapidly evolving operating models.
Service dominant logic, continuous improvement and systems thinking were familiar
Many of the ITIL artefacts are expressions of service value, based on a fundamental concept that value from a service can only come if it is co-created. In other words, if a service is not used, it cannot create value (no matter how good it is). I’d previously learned about Service Dominant Logic, (described in 2004 as a marketing concept by Stephen Vargo and Robert Lusch), so it was interesting to make the connection between these two disciplines. Whereas Vargo, Lusch and others focus on value dimensions, and the interplay between operand and operant resources, however, ITIL delineated service value through models like the Service Value System and the Service Value Chain.
Continuous improvement was another key ITIL focus, but guided by artefacts like Service Level Agreements and practices like Service Request Management, and motivated by efficiency and compliance focused targets rather than user-focused improvement drivers like UX or CX.
Systems thinking was another thread running through ITIL, however, it seemed limited in its use to describe sequences of inputs and output from different activities in value streams – without inclusion of Soft Systems Methodology (described by Peter Checkland in 1989), universally useful as a way to diagnose problems.
ITIL’s terminology tended to overwhelm the logic and the purpose
Naming things is hard and changing the names of things can lead to even more confusion. When it came to the words used in ITIL, it seemed that those who developed ITIL had thought long and hard about what to call the models, processes, practices and so on. For the uninitiated coming to ITIL fresh, however, it was natural to question why things were named in certain ways and to forget and mix up the terms, as well as question the absence of certain concepts. There seemed little scope to mould the rigid ITIL glossary to real-life scenarios, instead it seemed at risk of institutions trying to fit ITIL rather than the other way around.
Considering this conundrum, I was reminded of work I began a while ago to reduce jargon in Drupal, and of my ongoing work to shape the Web Sustainability Guidelines to be universally applicable. In both instances I had learned of the difficulty in choosing the right words and phrases to meaningfully describe abstract concepts, and therefore could appreciate the length of time it could take small changes to take effect in such a well-established standardisation mechanism as ITIL.
Read about my work on Drupalisms in this blog post:
De-jargoning Drupal – working with the community to open up Drupal’s terminology
Read about my work on the W3C Web Sustainability Guidelines in this blog post:
