Change is the only constant, particularly in a rapidly evolving industry like IT. Software gets constant updates, new hardware gets launched, and frameworks evolve with trends. Staying up-to-date on these changes can help you stay ahead of the competition. But it's not always easy to get people used to these new changes.
It’s no surprise that change management has been a key aspect of ITIL. One of the things that changed with ITIL 4: “change management” became “change enablement”
This reflected the shift in the ITIL approach towards a best practices approach, more of how-to guide, instead of a set of standards. This has been ongoing since ITIL V3 when Axelos dropped the long form "Information Technology Infrastructure Library" in favor of just... ITIL.
Whatever you call it, the framework helped organizations maintain a minimum standard for the quality of IT services they offered. ITIL ensured both clients and providers had a clear picture of the scope of services and helped manage expectations on both sides.
As the popularity of ITIL grew, organizations outside the IT industry started recognizing its benefits and adopting it. Along with this, there has been a recent push in the IT industry to refine ITIL to focus on bringing better ROI. In tune with these developments, Axelos rolled out ITIL V3, which expanded the scope of ITIL, both in terms of what it can accomplish, and in where it can be applied.
Instead of focusing on processes, ITIL V3 revolved around the different stages in the lifecycle of a service. Continual service improvement also became a major part of ITIL, detailing what all can be measured, how it can be measured, how to analyze the measurements, and how to improve on these metrics.
And ITIL further went ahead on these evolutions with ITIL V4, becoming more of a best practices guide instead of focusing on the processes. Instead of how a process will be carried out and the steps involved in these processes, ITIL detailed how an organization and its clients can get the most out of them.
Among these, the shift from change management to change enablement clearly showcased these priorities. The change also reflects how it will be implemented; instead of someone else taking charge and implementing the changes, change enablement authorizes the employees to make the changes themselves. Change enablement gives the individuals in an organization the ownership to implement the changes.
So why the change?
The shift from change management to change enablement is not just a name change, but rather a shift in how ITIL views change.
Change management always was a top-down mechanism, with an individual or a small group of individuals making the decisions. The change managers or change authorities decided how the changes and how it would be implemented. Often the rest of the company may not even be aware of the need for the change or even the end goal of the change. For them the changes were purely mechanical, just following the instructions without the authority to drive the change.
For example, if a company was going to shift to new ERP software, the managers may give instructions to their teams on the actions they have to perform on the software. They may give instructions on how to log their hours or mark what they’re working on.
What this often meant is that without the push from managers, the team may not completely adjust to the new changes or adopt the new practices. Expensive software meant to improve efficiency or new policies instituted for efficient resource management may fail to catch on.
This is where change enablement comes in. Change enablement places a higher emphasis on clear company-wide communication. Employees are given the full picture, explained the need for the change and how it will benefit all the stakeholders. Team members are empowered to make the changes, given more autonomy as well as the tools and training to implement the changes.
Kaimur Karu, former head of ITSM at Axelos says "For successful changes, many things need to happen before and after the 'controllable' part comes in, at least in the often used sense of control. First, we need to create suitable conditions and clear the path for changes. All of this requires a sustainable approach in all aspects of the triple bottom line.” According to him, "While Change Management will not disappear - not everything in this world is uncontrollable and unpredictable - it is perhaps a sign of the times that we are increasingly often talking about Change Enablement instead. “
For example, when trying to build a cybersecurity culture within the organization, employees are taught the benefits of robust cybersecurity practices. They’re shown how a cyber attack on the organization can affect them all. And with constant motivation and support, it’s likely that cybersecurity practices become second nature to everyone in the organization.
When every team member is empowered to make the changes, when everyone is responsible for the change, the adoption rate tends to be high.
What does the change mean for IT teams?
The change in the name signifies how ITIL is taking more seriously the culture shift associated with a change. It’s placing the human factor at the forefront, leveraging the culture shift in the right direction. Change management focused more on the mechanical aspects, on rolling out a new software update or setting up a timeline for the change. The changes would be rolled out by a team or an individual, and the rest of the organization would just follow them.
With change enablement, the whole team is encouraged to actively participate, and the entire organization is given the complete picture and authorized to apply the changes.
The focus is on building a new culture with the new changes or rather tweaking the existing culture to incorporate the new change. The idea is that once it becomes part of the organizational culture, the new changes will change, and eventually everyone will adopt them. 
Another key difference with the new approach is the emphasis on champions for the change in the organization. They are early adopters who are excited about the change, who understand the benefits of the new system. The champions showcase the way and motivate everyone else to follow suit. They pass on the message to the rest of the organization.
Executive sponsorship is another key element with change enablement. Just like a champion, someone from the management has to visibly support the new system. Active participation of someone from the management will drive down the importance of the change to the rest of the organization.
There’s also a higher emphasis on technology with change enablement. Teams are encouraged to use workflow management tools for planning and tracking changes. They can use automation to implement faster changes without increasing the resources. For example, IT service desk teams are encouraged to use asset management solutions to roll out software updates to all the systems in the organization, instead of installing them manually.
Change Advisory Board vs. Change Authority
With ITIL V4, instead of designated people for change, the roles are spread out over the product development teams in product-focused companies.
And there’s less emphasis on a change advisory board. The change authority is given more autonomy to make decisions, offering more flexibility to organizations. Organizations can even use automation along with peer review to assess changes. As Kaimar Karu says: “Having the CAB review every single change request isn’t efficient, and it’s definitely not common sense, especially when their costs can run to tens of thousands of deployments per hour in some organizations”
Integration of DevOps with change enablement
ITIL V4 introduced DevOps concepts like fail-safe testing, feedback loops, and CI/CD to change enablement. ITIL skeptics have often viewed ITIL as the opposite of DevOps, seeing ITIL as a set of permissions and checklists which slowed down, while in DevOps it was more like, if you’re failing, fail fast.
And with modern-day enterprises, ITIL V4 has realized the importance of quick changes and deliveries. And some of these DevOps concepts are expected to bring speed to change enablement.
More technology
Another key difference between change management and change enablement is the increased use of technology. As we discussed above, the move is for encouraging faster changes and rapid deployments. Organizations are encouraged to use tools for tracking workflows and backlogs, tools for collaborative change reviews, and even automated change approvals and release management.
Distributed responsibility for change
Unlike change management, the responsibility for implementing the change is not centralized within a small group of people. Everyone affected by the change is responsible for the change, even if the decision to change and the scope of change may be decided by a small group. Change enablement decentralizes the changes, relying more on peer review instead of getting approvals for every change from the CAB.
Change management and change enablement best practices
Here are some best practices for ensuring a successful change
Get executive sponsorship
Support from someone in the top management will improve your chances for a successful change. It will showcase the benefits and importance of the change to everyone in the organization. If the management isn’t interested in the change, it’s tough to get the rest of the team to get with the changes.
Communicate well
Make sure the team is aware of their role in the change. Clearly communicate how the change will benefit the team and motivate them to shift. It’s important that the team understand how the change will directly impact them for a high adoption rate.
Use gamification to your advantage
While it may be tough to use gamification for rapid changes, it can certainly be helpful for creating long-lasting changes in an organization. For example, if you’re introducing new software, or introducing a new set of cybersecurity policies, gamification will ensure your team retains their practices for a long time and the change is more likely to be successful. With gamification, it’s best to use a carrots-only approach, rewarding the behavior you want to see, instead of punishing behavior you don’t want.
Test small, then scale up
For big changes, it’s best to test it in a small environment, perhaps within a small team, and see how it goes. It may still go a bit different when you’re scaling up, but at least you’ll have some idea of what to expect.
Automate changes, use technology
Automate whatever changes you can. If it’s related to software, such as new firmware updates or security patches, automated rollouts can reduce the resources you need for the change. You can also use automated workflows and software to track the changes, their progress, and their impacts.
Frequently asked questions
What is change management?
Change management is the process of handling changes in an organization. It could be anything from a new software patch deployment to restructuring the organization or bringing a significant change to the organizational culture. Up until ITIL V4, change management has been mostly the steps to bring in the change, or the checklists to cover.
What is change enablement?
Change management is the new approach to change with ITIL V4. Here the emphasis is on people, on empowering the team to drive change. Instead of setting assignments or simply telling them what to do, they’re informed about the importance of the change, how it will benefit them, what their goals are, and given the tools and training to lead the way to change.
FREE Enterprise Service Management CourseElevate customer satisfaction and optimize organizational performance.   |
