Plutora Blog - Agile Release Management, DevOps, IT Governance, Software Development
ITIL V4 Change Management in 2020: Everything You Need to KnowReading time 15 minutes
Change. Love it or hate it—and let’s be honest, most of us hate it—it will always be a big part of working in IT.
IT service management (ITSM) requires solid change management capabilities. Change management helps align IT activities with business objectives. We can even say that change management is the key factor to transform your organization from a regular service provider to a business innovator. That’s why frameworks like the Information Technology Infrastructure Library (ITIL) exist. ITIL’s goal is to align the services a business offers and the expectations of a client using these services.
If you’ve ever tried to get a change approved or even implemented, you’ll likely know about the struggles that go along with it. In order to smooth this process, let’s explore the best practices the ITIL framework proposes related to handling changes. This post will take you on a tour through change management, the different levels of changes, and how to communicate these changes accordingly. Finally, we’ll break down a case study where we apply change management to DevOps.
After reading this post, you should feel confident implementing new changes to your existing IT service infrastructure.
Let’s get started with a soft introduction into ITIL.
What is ITIL?
ITIL is a framework which provides a set of best practices related to IT service management and continual improvement of IT-enabled services. The framework has been around for the last 30 years and has continued to adapt to today’s standards. Now, ITIL version 4 uses all of its evolved ITSM practices to be more compatible with the lean, agile, and DevOps movements.
Let’s first explore the definition of a change according to ITIL v4 principles.
A “Change” in Layman Terms
So, what is a change? It’s simply moving from one state to the next. As far as ITIL is concerned, it means that we’re moving to a new state in a way that affects IT services or its components. In this context, a change is an approved event, and the person doing that approving is the same one that oversees the change management process. Later on, we’ll learn that this person is referred to as a change authority.
There are a few ways change can be initiated.
The first type of change comes in the form of a change proposal. This is a thorough, detailed description—one that includes a business case and a proposed schedule—of the change you want to make to a service. You’ll want to share the financial ramifications of the proposed change, too. Change proposals are bigger projects than our next form of change initiation.
The second way you might get a change rolling is to submit a RFC—a request for change. This one’s a bit more formal, but anyone can submit one, as long as the change you’re requesting isn’t an emergency. Often, a stakeholder or service user will submit a change request. In order to formalize this request, an organization should have a standardized change request form that people can fill out.
What Is Change Management?
Change management plays an important role in the domain of service transition. It’s part of ITIL’s framework, and it offers best practices for service building, deploying, and transitioning.
Change management helps to minimize the risks for operational IT services. Plus, it makes sure an organization documents every change by identifying different levels of changes and specifying how to handle them. Some changes require minimal authorization while others require a detailed report about finances, benefits, and risks.
Let’s read more about the items that make up change management.
What Does Change Management Include?
It’s necessary to understand some of the most important elements that make up change management. In this section, we’ll discuss change authority, change types, and change communication.
Clarifying the Responsibilities of a Change Authority
First of all, let’s discuss the roles and responsibilities that come with change management. The next section will explain the different change types.
To understand these types, we need to know what change management roles exist and the responsibilities of those roles. The people who fill these roles can approve different levels of change requests.
1. Change Requester
The change requester is the person or entity that opened the initial change request. Note that the change requester can’t approve their own change request.
2. Change Advisory Board (CAB)
The CAB is made up of individuals that have knowledge on different domains related to a change. A particular change request may need a change advisory board that includes a marketing manager, financial officer, and technical lead to assess the impact of a particular service change. For example, the marketing manager may have input on how this change will affect their marketing strategy and learn what work is needed from their side to prepare for this change.
But the board doesn’t just have to be composed of internal folks. You might have stakeholders or consultants weighing in. In fact, you might even invite some of your more important customers—total outsiders to your company!—to be on your CAB.
Additionally, some companies prefer to establish an emergency change advisory board (ECAB) in case an emergency change arises. However, as you’ll read later, in the “Emergency Change” section, your pool of change reviewers should be flexible.
If an incident happens during the weekend, it might be hard to gather the ECAB. In that case, often only one manager or supervisor will approve the change to resolve the incident as quickly as possible.
3. Change Authority/Owner
The change authority is the one that oversees the processes behind change and all that entails. This person has the power to reject change requests that don’t contain sufficient information. The change authority also leads CAB meetings and gets change requests in front of the right people on the CAB.
So now that we understand who’s involved in change management, let’s talk about the different change types.
Exploring the Different Levels of Change
ITIL v4 defines different levels of severity for new changes:
Let’s talk about each of these levels.
Some changes are risky, but a standard change isn’t. These types of changes are so routine that they don’t need further investigation. They’re simple and straightforward changes that everyone understands. A standard change is one that occurs frequently—so frequently that there’s documentation around it and it doesn’t need authorization.
However, when first creating a standard change, the CAB will assess the involved risks. It’s only after they perform this risk assessment and confirm that there’s sufficient documentation that they can decide whether to accept or reject this request to put a standard change in place.
Example: OS upgrade
- Straightforward and frequent change.
- Documentation needed.
- No further authentication required.
Next, we have a normal change. A normal change is one that’s not standard but also isn’t an emergency. Maybe you want to make a big change to your website. That’s a bit riskier than a standard change.
As with standard change, you’ll need authorization by the CAB. But unlike the standard change, you’ll have to go through the entire change management process for each normal change. That can take time.
Example: Website change or performance improvement
- Important change to service/IT infrastructure.
- Full change management review.
- Requires final authorization from CAB.
We classify a change as a major one if that change means a lot of money is at stake (or if it’s otherwise quite risky).
To make a major change, you’d definitely want to be able to justify the risk. That means weighing the risks with the benefits, as well as laying out all the financial ramifications, in a detailed proposal. Both management and the CAB will be taking a hard look at that proposal.
Example: Migration from one data center to another
- Management and CAB authorization.
- Detailed report/proposal needed.
- High-risk change.
An emergency change means there’s an urgent situation and a change needs to be implemented as quickly as possible. An emergency change often resolves a major incident. However, due to the hasty nature of these resolutions, emergency changes have a higher risk of failure.
There is no standard emergency change process, so companies will make their own. The authorization of emergency changes will also be different for each organization and case. However, if you’ve ever been in an emergency, you already know how important it is that the authorization of the change is fast and simple. That’s why companies don’t have as rigorous an approval process for emergency changes.
In fact, an emergency change doesn’t always require the approval of management or the CAB. Anyone in an emergency will want to implement the change as quickly as possible. Therefore, this type of change can be authorized by management or even through peer review.
Let’s say an incident occurs at night or during the weekend. It’s not easy to get approval from the entire management staff or CAB. With limited staff availability, the pool of eligible approvers should be flexible. Only then can you be able to quickly resolve emergency changes.
According to ITIL v4, it’s even possible for an emergency change to get verbally approved. When this happens, you’ll always want to record the change after the incident has been resolved. It’s important to keep track of what changes have occurred and why they were resolved in a particular way.
Example: Fix for security breach or server outage
- Resolves incident.
- High risk of failure.
- Urgent change.
- Flexible pool of approvers.
We all know that communication is key. This statement is especially true when communicating changes across the organization. A change is never completed until it’s been communicated to all affected stakeholders.
It’s safe to say that communication is essential to enable any change initiative. Let’s see how we can effectively communicate changes.
How to Communicate a Change
Some organizations like to send out an email to all affected stakeholders, teaching them how the change impacts them. Often this email also tells them in what way they’ll have to do things differently. Many may argue that this form of tempered, intellectual, facts-based communication is an ideal way to transmit the message. However, a cold-seeming email may have the opposite effect, leading to more resistance.
Effective change communication focuses more on the emotional and personal aspects of the change.
Certainly, every change communicator experiences resistance once in a while. In truth, no email format exists to solve the problem of resistance. Some change communicators believe that spamming their colleagues with emails explaining the change multiple times will make them change their mind. In fact, we need a more personal approach that targets each individual emotionally. When we can convince an employee that this change will positively impact them, they’re less likely to resist.
Best Practices for Change Communication
Now that we’ve learned how to communicate a change, let’s list some of the best practices for change communication.
1. Don’t Use a One-Size-Fits-All Communication Strategy
It often happens a senior manager shares a change and expects that everyone will just understand and accept it. This is not always the case. But that’s not necessarily because the change is bad. It might just be because the change should be communicated in a different way.
The message should be tailored to your audience. If your change affects both the marketing and the development departments, it makes sense to write two different emails explaining the details applicable to them in particular. This way, you make sure you communicate the right information to the right people.
2. Express and Encourage Trust
Trust is essential for successful change communication. A change must be supported by management and the CAB in order to gain the trust of employees. If there are internal struggles, it will show. This will eventually lead to doubts among the employees about the upcoming change. Therefore, make sure to communicate a change transparently and honestly, and express trust in the good of the change.
3. Use a Variety of Communication Means
Here’s another strategy: try to diversify in your use of communication means.
For one thing, instead of bombarding your employees with emails, try to be a minimalist. One concise email is much more effective than 10 follow-up letters.
Some other means of communication include
- Team meetings.
- Small group sessions.
- Video conference.
- One-on-one meetings.
OK. So now that we know how to strongly communicate a change, let’s get practical. Let’s apply change management to the domain of DevOps.
Change Management and DevOps
ITIL remains a framework that defines best practices. However, some argue that ITIL is too much about processes. Let’s find out how change management can be applied to DevOps.
Change management helps to define a formal way of requesting changes. It also helps assess the risk of a change request. The DevOps team needs to know how a new change will impact the current IT services. For that, you need to employ agile change management.
For example, what if a report concludes that there’s a risk that a new change will impact the IT services currently running? The DevOps team will probably decide to first deploy this service to a test or separate environment to further assess the impact.
It’s worth mentioning that the change management process and tools may affect the efficiency of your DevOps team. It puts an extra workload on your DevOps team. After all, they have to learn about the whole change management process.
Change management requires that every change request comes with documentation about the possible outcomes, risks, and benefits. This helps the DevOps team keep track of all changes and formally document them.
Besides that, change management also defines how the DevOps team has to communicate changes. This is an opportunity for them, as it forces them to learn how to speak to all affected departments.
When there’s an emergency change within the DevOps team, only a select number of people have the required knowledge for assessing the risks involved. You can see why it can be hard to get an emergency change approved in a timely manner. Considering this, change management can be a threat to existing IT services.
But if you always have one member of the CAB on call, you can alleviate that risk.
Example Change Management for DevOps: Avoid Manual Changes
Especially for DevOps, automation is king. Therefore, we could come up with a new change request that restricts any employee from using SSH to the servers. This would mean that the DevOps team has to come up with ways to automate every aspect of their pipeline and daily tasks.
For example, let’s say your service turns out to have problems. So you try to consult the logs for this specific service. Instead of SSHing into the server, you force users to use a log aggregation tool that offers better functionality for searching and filtering logs.
Of course, it’s not always possible to follow this rule. For that reason, the change request should allow for an occasional SSH into the servers. But the DevOps team should think of ways to automate this exception.
In another example, a DevOps employee notices that their server is running out of memory. According to the new policy, they want to avoid manually allocating more storage space. He should use the APIs many cloud providers expose to first get notified when a server is using almost all of its available storage space. As a next step, the DevOps engineer should try to automatically allocate more storage space to this specific server using the cloud provider’s API.
See? It’s doable to align change management and DevOps.
Almost any problem can be automated. It’s all about following the new change request as strictly as possible. By doing so, the DevOps team will gradually save more time by automating most of its tasks.
How Is Change Management Used in Modern Organizations?
In a Forbes article, Paul Pellman, CEO of Kazoo, was quoted as saying, “The management of it shouldn’t be siloed in leadership. The biggest mistake I often see in change management is that company leaders often fail to involve managers in the process to embrace, promote and facilitate the changes that need to happen.”
To Pellman’s point, it’s a common misconception among leaders that collaboration is all about playing well with others. But in fact, change management is much more than just being nice. Change management is a creative process that involves your employees.
Therefore, your employees should provide feedback in brainstorming sessions or one-on-one meetings. This input should be used to design future change requests. These change requests should focus on reducing the workload for employees. Also, it should bring them more happiness!
Of course, some of the change requests should also be focused on increasing customer satisfaction or delivering improved services.
What to Remember About Change Management
If you decide to use ITIL change management practices, consider adopting a platform like Plutora that makes change management process more proactive and predictable, and remember the following key elements:
- Focus on employee satisfaction and improved IT services.
- Make sure that teams document every change request.
- Have systems in place to assess the risks of changes and try to reduce them.
- Communicate changes in a more personal and appealing way.
If you can keep that in mind, you’re in good shape to embrace change the right way.