Are Practices Still Important in ITIL 4?

ITIL^® 4 has been around about a year and you might be asking yourself are the practices, previously processes, still as relevant? Before we get too far into it, let’s look at the fundamental difference between a process and a practice.

A process is simply that, a set of activities that are executed to accomplish an objective. So, as it applied to ITIL v3 in many cases, that’s what the processes accomplished. When we speak to a practice in ITIL 4, we are talking about how the practice is viewed on a larger scale than simple activities. We are looking at it via the four dimensions of service management. This larger view ensures that the practice is more of a capability rather than just a set of activities.

So, what makes the practice different than the process? For those that have been using the ITIL processes in the past, you know that they were very activity oriented in that they outlined what to do, how to manage, how to measure, and who was meant to do what as far as roles ad responsibilities went. Some might say that the processes of old were more prescriptive. This worked well for those that were not able to have some level of consistency, although where it lacked was in the ability to achieve value for your organization overall.

Another challenge with the way the previous versions of ITIL operated, in my opinion, was that the processes that were widely adopted were very operational focused and not overly strategic. You would find that the processes were utilized by pockets of IT teams focusing on specific IT operational activities which didn’t make them particularly scalable. This generally meant that when new ways of thinking or working came along, the process had to be bent to accommodate, which limited a team’s ability to be effective as possible and co-create value within their organizations.

In ITIL 4, there is more focus placed on the overall business and technology and how it works with organizations. The introduction of the four dimensions of service management in ITIL 4 sees the practices as a capability rather than a simple process or activity.

That sounds great, so how do you apply this to the real world?

I recently worked with an organization who was, in their words, “defining and establishing best practices to improve IT service.” As they had a familiarity with ITIL, they had reached out and asked if I could help get them up to speed in that area. They were particularly interested in the incident management practice. They felt that this was an area that needed some improvement as it was causing some strain between IT support and the business. I linked up with their technology teams to take a closer look at where ITIL 4 could help.

Because I was looking at this as an ITIL 4 incident practice I began by breaking this down using the four dimensions of service management and focusing on the following:

• Basic outline of the incident management practice
• The activities for incident management as it applies to the value streams
• Any considerations for partners and suppliers
• How organizations and people are involved in incident management
• How information and technology support incident management

Basic Incident Practice

When we talked with the team about the incident management basics, we went through the table stakes of the practice such as the purpose of the practice. In their case, it was to minimize the negative impact of incidents by restoring service as quickly as possible. We also defined the difference between an incident and a major incident. We clarified through definitions any other terms that might require it.

Another item of importance was the scope of the practice. In our review, we clarified what made an incident and what did not. In the cases where something was not an incident, let’s say a problem or a request, we had linkages in the reference material to those practice documents as well. To wrap up the basics section, we outlined what success looked like by running through the practice success factors with some key performance indicators. For the most part, you might have found the same information in a previous ITIL v3 incident document, because it is still important.

Value Streams

The key in value streams is to understand that no single practice exists alone. This is something that, while it makes sense, may take some getting used to.

The key in value streams is to understand that no single practice exists alone.

We looked at it like this:

Even though almost everyone was on board with the fact that incident management was to resolve incidents, we had to educate them on the fact that, to do this effectively, they had to consider the big picture. Incident resolution required loads of other practices to be effective, including change enablement, service desk and event management, to name a few. People also had to realize that, in the other practice reviews, incident management might come into view for those practices.

The other thing we documented and shared as part of the incident practice was all the processes or activities that were part of the practice. There were some eyebrows raised around this. They would ask, “Aren’t we already reviewing the process?” You can see where the wording can get a bit confusing. The tone that we set at the beginning was that the processes within the incident practice allow us to turn inputs into outputs only. With this group, we determined that we had only two processes to include in the practice. We had an incident handling process and an incident review process. These were documented and reviewed with staff quarterly so that we could make improvements over time.

Partners and Suppliers

While many of the services this organization delivered was through their own internal resources, they were not all done this way. Because of this, it was important to first identify and establish close cooperation with any partners and suppliers to improve communication and ultimately improve decision making.

Organizations and People

This is where we talked about all the roles that applied to processes or activities within the practice. They weren’t jobs, and in some cases, a person could take on multiple roles. This was something you might have seen in an older version of incident management with a RACI diagram attached. The difference here is that we are talking about this in a broader sense of organization and how we work with them in this dimension. Since this company wanted to get a better handle quickly on incidents with fewer hierarchal escalations, we took on a flat team structure for incident resolution. This allowed us to collaborate better. But to ensure that there was trust and safety in this type of collaboration we needed to outline a “no fault or blame” culture within the practice. This allows the teams to focus on the issue, correct it, and learn from it without a fear of being blamed.

Information and Technology

In the information and technology area, we looked at how we use information to manage incidents. In many cases, I found that there was always valuable information about our services, customers, policies, architecture, and design, but we weren’t using it to our advantage. I found that even when this information existed, we just didn’t know where it even was. What a waste! So, we endeavored to better understand this information.

As far as technology, we looked at all the tools we were using to manage incidents, not just for tracking but all the events and oversight into what was making the incidents happen in an effort to reduce or eliminate the incidents in the first place.

The Bottom Line

So, are practices still important in ITIL 4? I say, yes. In fact, if applied right, they are more important than ever. The key here is that the practice is established to deliver value while keeping it simple. Years of doing this has taught me that, no matter if we call it a process or a practice, if we aren’t engaged and working together collaboratively, then it won’t produce the results we are looking for.

Ryan Ogilvie has been working in the service management space since 2006. A keen student of the service management ecosystem, he first started blogging after feeling a responsibility to share what he’d learned to a wider community. While his professional focus is IT service management, his experience has taught him that leveraging a variety of frameworks and communication styles will enable your business to meet its business outcomes. Follow him on Twitter @ryanrogilvie.