Let’s talk about adopting ITIL. When we get our hands on a new approach, framework, or method, it usually doesn’t take long before we forget the reasons behind, and context for, its existence; and make “implementing” this new shiny thing our goal, confusing ends with means. This pattern quickly leads to tribal wars over phraseology and technical details, often losing sight of the higher-level objectives and thus resulting in unrealized business value with somehow-green status reports.
This challenge is also common when it comes to adopting ITIL, where organizations have often lost sight of this being a service management framework, with a focus on customer value and continual improvement, and treating it as a process management framework instead. Apparently, this approach also requires a rigid application of every line from the ITIL books, for all processes, complete with all the described roles defined as job positions.
The paint-by-numbers game when adopting ITIL
This extreme process focus and the treatment of the ITIL books as a heavy manual have made many of the ITIL adoption attempts look like playing the paint-by-numbers game, where there is expected to be one correct way of connecting the dots. To be fair, compare this to anything else that is currently being “implemented” in large organizations – the challenge is not unique to adopting ITIL. So, the “correct” application of guidance has become a worthier goal than solving the problems or achieving the objectives of the guidance being there in the first place.
In these environments, tribal wars are common – to continue with the analogy, it’s not just the sequence of lines to be drawn, but also the color and the thickness of these that can be debated as being right or wrong. In extreme cases, the attempts of adopting the guidance resemble mysticism. This comes with the belief that if we align all possible parts exactly right – according to the prescriptive guidance from expensive import tea leaves – it will all click together, and many wonderful things will then happen as if by magic. Often, these attempts in organizations are packaged into multi-year projects with detailed plans per process, but no plans for people. Or for value.
Keeping the goals in mind when adopting ITIL
In my experience, when dealing with challenging or “stuck” situations, taking a pause to reassess the objectives before moving ahead is usually the most successful approach. Often, it requires answers to “why”-type questions on a more granular level too. Where, for example, “Why do we think this specific thing should be done?” or “Why do we think this specific thing should be done in that specific way?” can reveal a lot about assumptions that might not have any rooting in reality. For example, why do we think we need the change advisory board (CAB)?
I’m not saying that having a group of people to advise on the risks and benefits of a proposed change is a bad idea, but what’s the specific problem we’re trying to address, and what’s the best design for that solution? There’s no one correct way to design a CAB, nor is the CAB always required.
As part of this exercise to realign, we can also reassess the way we look at the ITIL guidance. We should not treat the described 26 processes as discrete units, where paint-by-numbers is a viable approach – it’s not. We must also understand that a lot of what’s described in the ITIL books as processes is not, in fact, process. There are practice areas that include, among other things, processes for sequential work. Some people call these practice areas capabilities, and while that is an improvement over “process,” it still comes with baggage.
In the simplest of manners, when I discuss these practice areas, I often describe them as things to take care of when adopting ITIL. The context, of course, is the delivery or co-creation of customer value, using the concept of “service” as a vehicle and a management layer. We are managing services, which are there to deliver value, and we need to design, run, and improve them to provide the expected experience, without losing sight of expected value.
Forget about the details (for now)
The arguments about the design of the lines in the paint-by-numbers game can be endless, but none of that matters if the objectives of what is drawn are not met. While on the highest level the objective of service management is (improved) customer value, different building blocks that enable this have their own specific objectives that contribute to the high-level ones. It’s also important to remember that the building blocks work when used together, not in isolation. A mismatched piece might look great on its own, but when it can’t be used as a building block for something bigger, then it’s useless.
To start from where we are, let’s stick with the concept of “processes” as a catch-all for practice areas for a little bit longer, and take a look at the ones described in ITIL. The following is a list of some of the most commonly discussed (and often either over-designed or missing in reality) processes and concepts from ITIL. I’ve added the description of their objectives the way I often start describing them.
- Incident management: when something bad happens with the service, make sure the customer is kept informed and the service is restored as quickly as the customer requires it to be
- Problem management: in predictable contexts, try to understand the conditions that have led, or could potentially lead, to incidents and investigate opportunities to improve service design
- Change management: ensure there is a common understanding among all stakeholders of both the expected benefits and the potential risks of proposed changes
- Capacity management: keep matching capacity provided with capacity required
- Availability management: ensure the customer can use the service when and how they expect to
- Change advisory board (CAB): a group of people who can help the person accountable for carrying out the proposed change to assess the benefits, risks, and potential solutions
- Continual improvement (formerly CSI): keep investigating the opportunities to improve services, service management artefacts, and ways of working to keep up with changing customer needs
To successfully meet these objectives when adopting ITIL, many questions need to be answered – but by keeping the objectives simple at the start, it’s easier to keep checking back as to whether the solutions based on those answers still make sense.
The “how” of every process or concept matters only when the “why” is successfully addressed. Whenever we add or remove pieces of the process, or change the way something is done, we need to keep the “why” in mind. Otherwise, we continue down on the path to Continual Service Irrelevance.
I know that many of the ITSM.tools readers work in organizations that started adopting ITIL several years ago. I encourage you to start where you are, and ask – for every process, procedure, and artefact you have in place – what is its purpose and whether the current design is fit for what needs to be achieved. Do not do kick this off as a project or a program, though – focus on small steps, quick wins, and sustainability. In other words, focus on CSI.
Want more? Here are informative ITIL 4 service value system and ITIL 4 service value chain articles.
Kaimar Karu
After commencing his studies in philosophy in the late nineties, Kaimar decided to add a practical element to his life (and to pay his bills) by turning his hobby into a career. His roles in technical support and software development led to the world of project management, and he took on the task of setting up a PMO for a government agency. After successfully delivering several key EU projects with his awesome team, Kaimar moved to IT service management (ITSM) to help organizations worldwide become better at delivering customer value. Before joining AXELOS, where his role was to oversee the product strategy and development for ITIL, PRINCE2, and the rest of the Best Practice portfolio, including co-authoring ‘the best ITIL book out there’ – ITIL Practitioner – Kaimar spent three years working with Skype on improving their ITSM and operational capabilities.
One Response
Good pointers on how to go about the ITIL adoption process…