If you’ve taken any sort of ITIL training prior to 2019, you have undoubtedly bumped into some mention of ITIL processes (Incident, Problem, and Change being the most common). If you’ve taken ITIL 4 Foundation, however, you likely noticed that much of the course material has shifted away from processes in favor of practices, value streams, and guiding principles. For those who have built their careers on implementing or improving ITIL concepts within their organizations, this is a pretty dramatic shift (see our ITIL 4 Complete Guide for an overview of the additional changes in ITIL 4).
There are plenty of good reasons for it, though, which we will explore further here.
ITIL Processes are not standard across organizations
One reason for the shift away from ITIL processes and their associated tools and techniques is that there is no one-size-fits-all when it comes to, for example, managing changes in an organization. There never was, and trying to give people examples of how to run particular processes had the unintended consequence of people just doing what the ITIL books prescribed – rather than doing the hard work of creatively thinking and talking through what makes the most sense for their teams, culture, organization, and most importantly, their customers.
How a lopsided focus on ITIL processes can be unhealthy
Another unintended consequence the authors of prior versions ITIL found was that organizations placed too much of a focus on building out a few ITIL processes, buying an IT Service Management (ITSM) platform to automate said processes, gaining a false sense of achievement that they were “doing ITIL,” and moving on to some other area of focus. Unfortunately, organizations that took this approach to process implementation often found themselves with unhappy customers in the end; they still viewed IT as nothing more than a necessary evil, their needs weren’t being met, and ultimately no real organizational transformation had taken place.
In large part, focusing too much on ITIL processes results in a myopic view of a much bigger system that needs to change and improve. So, where should our focus be? Here are three areas of focus in ITIL 4, namely that of Practices, Value Streams, and Guiding Principles that replace the emphasis on processes and help us take a more strategic view.
Shifting from Processes to Practices in ITIL 4
One of the biggest shifts in terminology in ITIL 4 is the renaming of processes as practices. It may seem like a small shift in semantics, but it’s actually a pretty big, and much needed, revision. Let’s start with the definition of each word:
Process:
1. A series of actions or steps taken in order to achieve a particular end.
Practice:
1. The actual application or use of an idea, belief, or method, as opposed to theories relating to it.
a. The carrying out or exercise of a profession, especially that of a doctor or lawyer
2. The customary, habitual, or expected procedure or way of doing of something (for example, “current nursing practice”)
3. Repeated exercise in or performance of an activity or skill so as to acquire or maintain proficiency in it.
I love the images evoked by the word “practice” because what often makes organizations successful is maintaining an ongoing focus on improving in all areas. Putting a process in place implies that the activity of creating the process has an end point. Whereas a practice is something we have to keep improving to remain competitive and continue to delight our customers.
The word “practice” also gives us the sense that we have to work at something like we would a sport, and that we will make frequent mistakes along the way – but that’s part of the learning and improvement process. A practice is something teams make a profession out of, honing their craft over several years. The same is true with any world-class service organization – Michelin star restaurants, top ranked Conde Nast resorts, and the like.
The 4 Dimensions of Service Management in the ITIL Practice Discussion
The ITIL 4 books debut a concept called the 4 Dimensions of Service Management, which does a nice job of demonstrating how having processes in place is only one of the many things to consider when approaching how we work. It offers a holistic view of the various areas that are critical to delivering real value.
Thinking beyond the boundaries of process mapping when it comes to managing change
In order to manage change effectively, organizations should look beyond process mapping and examine what it could mean for them more broadly. Here’s an example: Let’s say your organization is having issues with changes going sideways (which can cause teams to waste hours chasing their tails trying to figure out what caused a high priority issue). IT Leadership decides it’s time to take a good, hard look at the existing change process and update it to get balance restored. To do that, they create a diagram like the one below.
This is all well and good, but if the team stops here, they’ll be missing a ton of opportunities to make the overall practice of enabling changes much more powerful. What opportunities? Imagine how much more robust the change process would be if they asked a few of these questions:
How often should we be making changes?
- A weekly Change Advisory/Control/Action Board meeting is not frequent enough. You will want to talk with your customers and understand how quickly changes need to happen – Daily? Several times a day? – and figure out what that cadence should look like and how to best accommodate it. For example, many Agility-minded teams hold Daily Scrums so they can approve changes each day rather than making their customers wait an entire week (or more) to implement a change.
What level of risk are we ok with?
- This can vary widely from organization to organization. For example, we have a client that supports software on AirForce One. They have, understandably, very little tolerance for risk. Other organizations may not be held to that same standard when it comes to avoiding risk and may be ok with making, say, emergency changes that occasionally end up having to be rolled back.
What kinds of changes impact everyone and how do we best discuss them?
- Carrying the idea of Daily Scrums forward, I have also seen clients hold daily Scrum of Scrum meetings, in which an individual team discusses the changes they’d like to make, then one person attends a short meeting to discuss those changes that impact other teams, so everyone is involved in the discussion and decision.
Are there alternate change authorities we can use for certain types of changes?
- What types of changes can be peer reviewed and don’t need to go to a board of people?
- What changes can we automate or pre-approve so humans don’t even need to be involved?
- What changes can we split into smaller pieces to lessen risk in the first place?
How can we leverage tools that help us handle more changes and still maintain visibility into said changes?
How can we decentralize change decisions away from a single Change Manager and/or CAB to give more power to teams?
What’s the minimum documentation we can require and for what types of changes?
What critical systems should we lock down so that changes can’t happen in secret?
If we are using Agile, Lean, or DevOps concepts, has our change team (or leadership team, for that matter) gone through some basic training and/or talked with the teams practicing these methods to see how IT can best leverage ideas to make change happen more quickly while still keeping risk levels at an acceptably low level?
These are just some examples of questions that may be prompted by a bigger view into the other dimensions outside of the process itself.
Shifting from Processes to Value Streams in ITIL 4
My favorite concept brought forth in ITIL 4 is that of Value Streams, an idea that comes from Lean. IT is often so consumed with the behind the scenes details of running the day-to-day operations of IT that they miss the bridge that allows them to communicate more clearly with customers. Having an understanding of how Products and Services contribute to the organization as a whole and how the organization delivers value to end customers is essential. Instead of IT serving other business units (as shown in the first diagram below), the better way to envision Value Streams is how every business unit comes together to serve the organization’s customers (as shown in the second diagram).
IT in service to other internal business units:
IT and other business units serving the customer together:
Processes make up value streams, but they are one level lower than what is depicted here; and if we continue to focus solely on individual processes, we will miss the opportunity for a larger (and more productive) conversation with the overall organization. See our blog post for more information on Value Streams.
Shifting from Processes to Guiding Principles in ITIL 4
Another concept that students, customers, and practitioners alike have struggled with through the years is how to go about implementing ITIL concepts in their organizations. This was especially true in ITIL v3 training, where students learned a whopping 26 ITIL processes. It made the idea of implementation intimidating and confusing. In 2016, the ITIL authors published the first version of the Guiding Principles, and they’ve been further refined as part of the ITIL 4 books (see the diagram below). The reason these are so important, and in my mind, more important than covering the steps that support a particular process, is that, just like with the Agile movement, there’s the idea of “Being Agile” versus “Doing Agile.” ITIL’s Guiding Principles fit squarely into the “Being ITIL” category. Our mindset, values, and beliefs drive our actions in big ways, like how we approach ITIL concepts in the first place, as well as how we develop and, ultimately, deliver high-quality, valuable products and services that solve problems and move our organizations forward. How our processes look is a by-product of our Guiding Principles. You can learn more about ITIL’s Guiding Principles here.
ITIL’s Guiding Principles
Final thoughts – Expanding our view and changing conversations with those around us
For those of you who are nervous that ITIL 4 is moving away from ITIL processes, my hope is that you have found some ideas in this article to be helpful as you start to implement ITIL concepts in your own organization. Pulling Agile, Lean, and DevOps concepts into the ITIL books was something that was long overdue, and I’m glad to see the ITIL 4 books (and ITIL 4 training) more accurately reflect how modern organizations are currently working. The new concepts give those of us working in IT additional tools to drive meaningful conversations with our peers and clients. At the end of the day, we all want to do meaningful work for others, and ITIL 4 propels us closer to achieving that goal.