What You Need to Know About Change Enablement

Change enablement is the practice that deals with IT change, transitioning new services or their supporting components into your production environment effectively, efficiently, and safely. It’s also one of the trickiest practices to get right. We often get it wrong by either going in too hard with restrictions, making it challenging to innovate, or we’re not careful enough, which causes service disruption to our businesses and end users. The introduction of ITIL 4 brought a focus on change. It has a new name, is now practice-driven rather than purely a process, and is aligned with the service value system. But what does that mean for stakeholders of the new and improved change practice? This article will look at the following:

• What has changed with ITIL 4?
• How to design for an improved colleague and customer experience
• Practical guidance on how to run Change Advisory Boards (CABs) within your organization with the support of the DevOps 3 ways.

This blog by @Joe_the_IT_Guy looks at everything you need to know about change enablement. From what's different with change in ITIL 4 to running successful Change Advisory Board (CAB) meetings. #ITSM #ServiceDesk #ITIL4 Share on X

We live in an ITIL 4 world

ITIL has existed since the 1980s, so a new version would always be a big deal. The latest version of ITIL has brought some changes to the change practice. Firstly, a name change from management to enablement is a small but crucial detail. Change management was always about controlling and protecting the production environment and the business from there. But that sort of perspective can always act as a blocker. From ITIL 3, we’ve focused on delivering value and removing blockers, so it would make sense to see that reflected in the change practice as the ITIL framework continues to evolve. By renaming the practice to change enablement, we’ve made it easier for our colleagues to innovate and engage with the process rather than trying to work around it because it is too complex or challenging.

Another aspect of the ITIL 4 change guidance is recognizing that change activity needs to flow to align with the business and deliver value. The change enablement practice acknowledges the role of automation in making change activity more efficient. While a change can still be triggered manually by raising a request in your IT service management (ITSM) tool, there is also more emphasis on automation. For example, through Artificial Intelligence (AI), tier 0 support, reactive support as a response to incident management activity, or proactive support when aligned with event management.

Here @Joe_the_IT_Guy shares practical guidance on how to run Change Advisory Boards (CABs) within your organization with the support of the #DevOps 3 ways. #ITSM #ServiceDesk #ITIl4 Share on X

How to design for an improved colleague and customer experience

Prep work is everything. In a previous job, I had a colleague who used to say to me, “The more we practice and prepare, the luckier we get.” The same can be said for effective change enablement, especially through the lens of customer and colleague experience or CX. So how do we design improved colleague and customer experience? We lean into best practices. Here are some ideas:

• Recognize that change enablement is now practice rather than process-based, and therefore include ideas from each of the four dimensions of service management:
  • Organizations and people
  • Partners and suppliers
  • Information and technology
  • Value streams and processes

Why is this so important? Well, look at it like this. The new practice is about people, partners, knowledge, and experience, as resources as well as the process and tools so that best practice continues to evolve, as well as adapt to the needs of the organization.

• Lean into continuous delivery and flow. Change must flow to align with the business and deliver value. Technology can be used to effectively create an automated pipeline to support continuous integration and delivery, enabling most steps of the change control practice to be automated, including the impact assessment and approval stages – stages that have historically caused delays due to process or environment complexity.
• It’s all about the value that we can add. Another change from ITIL v3 to ITIL 4 is transitioning from the service lifecycle to the service value system (SVS). The SVS is a crucial part of ITIL 4 and facilitates value co-creation. It shows how all an organization’s components and activities work together to create value. The SVS has interfaces with other organizations and thus forms an ecosystem through which it can create value for those organizations, stakeholders, and customers.
• Set out your change enablement practice and way of working. Map out your workflows and capture any touch point with other practices, such as incident management to resolve incidents or configuration management to help with impact assessments.
• Establish a framework for change enablement. Change is more than a practice. It is a living, breathing entity that will help your organization grow and improve. When designing your practice, develop a framework for enabling changes that leans into business or organizational change management so that your change activity has the appropriate support with communication and training. This will help end users and customers prepare for changes and adapt quickly.
• Build in continual improvement. Carry out reviews of how your change practice is performing so you can look at what is working well (and expand it) and work on any pain points.

'Change is more than a practice. It is a living, breathing entity that will help your organization grow and improve. When designing your practice, develop a framework for enabling changes that leans into organizational change management'. -… Share on X

Improving CABs with DevOps

In ITIL 4, there is a shift towards more collaborative and flexible approaches to change approval. The traditional change advisory board or CAB meeting, where stakeholders meet regularly to assess and approve changes, is no longer the default way to get your change approved and scheduled. Instead, the updated guidance emphasizes the importance of appropriately involving relevant stakeholders in the change process for the specific context and complexity of the changes being made. That being said, I am still very much #teamCAB. Not for every change, but I think there is still a need for CAB sessions and the value they bring in keeping the IT organization connected and in sync with the outcomes needed by the business. Used appropriately, CAB meetings can still help manage changes because they provide a structured forum for discussing and reviewing proposed changes, identifying potential risks and impacts, and gaining stakeholder consensus. They can also offer oversight and accountability for the change enablement practice. So how do we strike the right balance between agility and accountability? Well, for my money, the new ITIL guidance is much more aligned to the DevOps 3 ways, for example:

The new ITIL guidance is much more aligned to the #DevOps 3 ways says @Joe_the_IT_Guy. Here he explains how. #ITSM #ServiceDesk #ITIL4 Share on X

• The DevOps 1st way; increase flow and systems thinking. In other words, increase speed and reduce blockers. ITIL 4 introduces the concept of the change authority to facilitate change approval. Introducing the idea of a change authority means that people have more flexibility on support, for example:
  • Standard changes
  • Delegated authority
  • Business exceptions

This doesn’t replace CAB, but it takes some of the load. This means that the CAB can focus on what it was initially designed for – the serious stuff that needs to be carefully reviewed, sanity-checked, and scheduled by multiple teams and stakeholders to ensure that the proposed work is worth the risk and can be implemented in a way that best supports the business.

• The DevOps 2nd way; amplify feedback loops. Shortening and amplifying feedback loops means that quality issues can be fixed directly at the source avoiding defects and rework. Used effectively, feedback loops can significantly increase overall service quality. This can be applied to the CAB process by introducing peer reviews of implemented changes so any wins can be celebrated (and the same approach can be used elsewhere) and lessons learned can be captured and acted on.

• The DevOps 3rd way; creating a culture of continual experimentation and learning. If you want to build a successful change organization where people feel empowered to experiment and learn, you must develop a culture where experimentation is normal expected behavior. Make it clear to your people that a key part of the process of trial and improvement is that CAB is a safe space. Not only is it OK to speak up – but it is also actively encouraged! Set expectations early – update the meeting terms of reference – shout it from the rooftops if necessary but let people know that CAB is a safe space. Tell your people there are daft questions and that it’s OK if you make mistakes as long as they’re identified, handled quickly and effectively, and learned from.

That’s my take on change enablement. What do you think? Please let me know in the comments.