ITIL 4 Practitioner: Change Enablement – change with customer value in mind

Thanks to changes in technology, e.g. widespread use of cloud computing, increasingly agile ways of working, and the changing nature of customer demand for digital services, the rate of IT change has moved to seconds, hours, and days rather than weeks, months and years.

And what organizations need today requires the type of support that matches that different rate of change.

Therefore, the ITIL 4 practice of Change Enablement is – as opposed to Change Management – focused more on enabling and supporting than preventing things from happening.

Historically, change management – which included the Change Advisory Board (CAB) that was often sadly and wrongly morphed into a Change Approval Board – has been perceived as a brake on change. Change enablement, while still involving control and having an eye on risks to maintain a stable environment for high-quality services, is about enabling changes in a controlled fashion; creating guardrails to allow change at the speed of business demand.

But what is the importance of risk assessment, change authorization and managing the change schedule in an Agile/DevOps world?

Managing change = caring about customer value

In large organizations there are many dependencies between teams and technologies. Products rely on platforms and those, in turn, often on external service providers while the customer is interested in a well-working end-to-end service with limited interest in the details of technical complexity and limited patience for service degradation.

There are many technology changes where a single team can complete the analysis, schedule the work and deliver the results with limited impact on other teams and services. In these cases, many highly-formalized steps to manage change can be skipped, performed in a lightweight manner, or fully automated. A one-off change with unknown risk and a limited blast radius carried out in a controlled environment can also be approved in these situations. Learning the limits and risks of the system is important.

But, in most scenarios, the impact of change is likely to be felt by customers. And it should be felt by customers – why else would the change be made? So, it’s necessary that changes and their potential risks are understood, planned for and supported. The aim is for change to be an improvement, not a problem. Equally, this applies to platforms and products, where change affecting other teams needs to be coordinated.

In an agile product development environment – where this discussion is about agreed business-focused change roadmaps and priorities – many changes can be automated, with controls in place so nothing is deployed or released before the “stars have aligned”. For example, does the platform functionality exist for a new product feature or is additional funding needed to make it happen? Are the products ready for the change in the platform API or are changes to the codebase required?

When done well, automation offers the ability to track quality and spot problems before they happen. And if an organization cares about customer value, experience, predictability, properly managing dependencies, and not creating additional pain, then change enablement is there to help. All service providers have change enablement in place – the question is whether this is done well.

ITIL 4 Practitioner: Change Enablement

By studying and certifying in the ITIL 4 Practitioner: Change Enablement practice – as part of the ITIL 4 Specialist: Plan, Implement and Control combined practice module – practitioners will improve their ability to see the big picture, understand the end-to-end value streams, and navigate novel situations with many unknowns. They will also hone their skills in risk management, dependency mapping, tooling selection, design of automation, stakeholder management and value-focused collaboration.

Complementing other practices in ITIL 4 Specialist: Plan, Implement and Control

The capability to ideate and deliver services that a business needs is supported by ITIL 4 practices including Service Configuration Management (tracking the relationship between configuration items and what could be affected by change) and Release Management/Deployment Management (taking something from design to release and co-ordinating with other releases for maximum customer benefit).

However, these concepts are all overseen by Change Enablement as an overarching practice. Changes taking place at different levels and in different parts of the organization need to align to bring the expected benefits and delight, rather than upset, customers.

Change Enablement is focused on the outcomes of change; understanding why certain changes are planned and creating a mechanism from ideation to delivery with guardrails to streamline execution. Even if release/deployment take place later in the workflow, the Change Enablement practice looks ahead at the whole lifecycle to make sure each stage is considered from the outset.

And this practice applies to all types of change in the organization including new software features, how to use service management, how to fund activities, etc. Not all change in the service provider’s organization is technical.

Practice success factors – why?

Practice success factors (PSFs) ensure that a practitioner using an ITIL practice is doing so effectively.

So, what makes each of the four PSFs in Change Enablement important?

1. Changes realized in a timely/effective manner:

Speed of change for the sake of speed is not necessarily an objective. Changes should happen at a pace that makes sense to the organization. The practice emphasizes the required pace needed and helps to align controls and other enabling factors, e.g., not pushing change into a live environment before it’s necessary. Optimizing for speed beyond business demand would result in wasted resources.

2. Minimizing the negative impacts of change:

A service provider needs to minimize any negative effects of change being passed on to customers. The latter should see change as mostly beneficial and pain-free. That’s the job of the service provider: providing a delightful service experience and dealing with risks so that the customer doesn’t have to.

3. Ensuring stakeholder satisfaction:

It’s not enough to execute change technically well if it doesn’t meet stakeholder objectives. Are stakeholders satisfied with the platform, technology, release and functionality? You will know this only if you have identified and understood the potential value for stakeholders and created successful change.

4. Meeting change-related governance/compliance:

Some controls and procedures are there to enable the smooth delivery of change but, also, organizations – such as banks – may be governed by external rules and regulations. Change Enablement can help smooth the process of putting in place the controls needed to deal with these compliance aspects.

Overall, the Change Enablement practice enables service management professionals to balance the many, and sometimes contrary, stakeholder requirements while supporting change that leads to intended outcomes for the organization.