What is change enablement / management?

The ITIL 4 body of service management best practice guidance offers a clear purpose statement:

… to maximize the number of successful service and product changes by ensuring that risks have been properly assessed, authorizing changes to proceed, and managing the change schedule.

Source: AXELOS, Change Enablement ITIL 4 Practice Guide (2020)

Where a change is “The addition, modification, or removal of anything that could have a direct or indirect effect on services.”

There are four common reasons why change happens:

  • To correct something
  • To prevent something
  • To stay compatible (because something else has changed)
  • To add, enhance, or remove a capability

Importantly, change enablement, provides a formalized way to consistently handle the changes required to improve IT services, IT and business operations and outcomes, and ultimately customer experiences and outcomes.

What is change enablement/management?
What change enablement/management isn’t

What change enablement / management isn’t

In the case of change enablement or change management there are two similar, but different, ITSM capabilities that need to be seen, and treated, differently to change: ITSM capabilities that need to be seen, and treated, as different to incident management:

  • Service request management - there might be confusion between service requests and change requests. It’s important to ensure that low-risk requests are treated as service requests rather than change requests (via a standard change approach) to avoid unnecessary bureaucracy and delays to provisioning.
  • Organizational change management - which relates to people change rather than changes to the IT infrastructure, services, or processes. Importantly, though, such “IT changes” might need organizational change management to help ensure that people change needs are addressed.

What change enablement / management entails

Change enablement in ITIL 4 is far less complicated than change management was in ITIL v3/2011. The differences are covered in a later section.

The new ITIL 4 change enablement guidance includes the following two change processes:

  • Change lifecycle management
  • Change optimization

Change lifecycle management includes the following activities:

  • Change registration
  • Change assessment
  • Change authorization
  • Change planning
  • Change realization control
  • Change review and closure

The change optimization process is concerned with continually improving the change enablement practice, change models, and standard change procedures.

What change enablement/management entails

The need for, and benefits of, change enablement / management

Modern business needs change, and there are many drivers of change. Some are internal such as new products and services, revised ways of working, mergers and acquisitions, or correcting technology issues. Some are external such as legal or regulatory changes. Organizations need formal change capabilities that balance speed, risks, costs, and business value to deal with this constant flow of change.

The benefits of change enablement/management reflect these needs:

  • Protecting the business operations and continuity of service
  • Ensuring that governance requirements are met
  • Improved change visibility – from the communication of the schedule of changes to dealing with expedited or emergency changes quickly
  • Increased speed of change - thanks to change models and change-enabling automation
  • Improved risk avoidance and impact assessment
  • Improved change prioritization and scheduling
  • Improving employee experience and the business’s perceptions of IT
  • Reduced change related costs including efficiently enacting changes, minimizing the need to back out failed changes, and reducing the business costs of change-related issues and failures
benefits of, change enablement/management

Change enablement management in ITIL 4
vs. change management in ITIL v3/2011

The ITIL 4 Service Value System
  • ITIL becoming service management rather than ITSM guidance
  • Being organized in practices rather than processes
  • The introduction of the service value system

ITIL 4 also includes some changes specific to change management

By renaming change management to change enablement, ITIL 4 avoids the confusion with people-related change practices and better positions the guidance to enable better business outcomes.

ITIL 4 also blends in key DevOps concepts, including:

  • Safe-to-fail testing
  • Continuous integration and delivery (and greater use of automation)
  • Feedback loops

ITIL 4 change guidance also includes how different levels of complexity affect change needs. The diagram below is taken from the AXELOS Change Enablement ITIL 4 Practice Guide:

TIL 4 different levels of complexity

Another key difference with the ITIL 4 change enablement guidance is with change-related roles. A new change authority role has replaced the change advisory board (CAB) model previously espoused by ITIL. Where changes can be assessed and authorized by peer reviewers and automation.

How to start with change
enablement / management

When starting with change enablement - or change management if this term is preferred - there are many necessary, “common sense” steps to take. These include:

  • Clearly stating the purpose and intentions for change enablement/management - this starts with a scope document and an agreed policy that reflects what’s expected of people
  • Adopt best practices with caution, focusing on what will work best for your organization, culture and operations
  • Balancing speed and risk by understanding the corporate appetite for risk, including the policy related to change freezes
  • Using organizational change management tools and techniques to ensure that everyone impacted by change enablement/management knows why it is needed and what it is
  • Getting buy-in through business justification, expanding on the “why” in quantifiable benefit terms
  • Recognizing that the introduction of change enablement/management requires investments in people, processes, and technology
  • Following the ITIL 4 guiding principle of “starting where you are” by acknowledging that your organization is likely already doing some change management activities
  • Taking an end-to-end view of change enablement/management, not just the request for change (RFC) process
  • Delegating authority for change decisions as per the latest ITIL 4 best practice guidance - this is where an owner for each area can approve changes
  • Delegating authority for change decisions as per the latest ITIL 4 best practice guidance - this is where an owner for each area can approve changes
  • Ensuring that people are adequately trained in change enablement/management practices, including what constitutes a change versus business-as-usual needs, retraining as needed
  • Making it easy for people to engage with change enablement/management practices - for example, raising changes using clear and instructional forms
  • Using change models for different types of changes, for example, a “non-standard change” needs a different approach to a “pre-defined and pre-approved change” based on risk and potential impact
  • Using change models for different types of changes, - for example, a “non-standard change” needs a different approach to a “pre-defined and pre-approved change” based on risk and potential impact
  • Employing standard changes for pre-approved, low-risk, and usually small, changes such as restarting servers in the test environment
  • Minimizing CAB use - if an organization is using the standard change and delegated authority models effectively, then the CAB will only need to deal with the most complex of changes
  • Treating emergency or expedited changes differently but still using an agreed approach - no matter how well your change enablement/management capabilities are working, there will still be changes that need to be fast-tracked with risks managed appropriately
  • Measuring performance from the get-go with appropriate change metrics that highlight both successes and improvement opportunities
  • Using continual improvement techniques to improve change capabilities over time - for example, adopting elements of DevOps to increase change velocity while maintaining sufficient control
How to start with change enablement/management
How ITSM tools help with change enablement/management

How ITSM tools help with change enablement / management

Change management capabilities have long been a staple of ITSM tools. It’s not uncommon for ITSM tool vendors to demo their solution using an IPC approach - where:

  • An incident is logged (the I)
  • A problem record is created from multiple incident records (the P), and
  • A change request is created to address the root cause of the problem (the C)

There are separate change management tools available, but most organizations prefer to use the native change capabilities of the corporate ITSM tool that’s already employed to deliver against a variety of service management needs.

This approach benefits from the ability to move incident data into a problem record seamlessly and then into an RFC. Plus, this gives change enablement access to workflow automation, notification and reporting to assist in process execution. This can assist with classification of changes, change-model routes, approvals and facilitating other procedural needs.

In addition to these capabilities, there are some key change -management -specific capabilities required of fit-for-purpose ITSM tools, including:

  • The ability to cater to various change approaches - this is the use of different change models and associated processes based on change risk and potential impact. For example, handling standard changes that are low-risk and pre-approved and can often be executed without human intervention using automation. Or a fast-track route for handling emergency or expedited changes.
  • Risk-based change assessment tools - these are built-in capabilities for assessing the risk and impact of changes. This capability often involves forms to capture and communicate the potential risk to key stakeholders. Organizations may also wish to visualize change impact using business function or business service perspectives.
  • Published change schedules - his is the ability to present the forward schedule of change to all affected parties so they know what changes are planned and when Organizations might want to see functional views of the change schedule. For example, what will impact human resources (HR) operations in the next quarter, or they may want to make the change schedule visible in other operational tools such as Microsoft Teams.
  • Collaboration support - while the enablement of workflows is an ITSM staple, the growing adoption of digital operations and increased remote working in recent years also necessitates collaboration support. Collaboration capabilities might be delivered via corporate services such as Slack or Microsoft Teams. Still, some ITSM tools also offer native capabilities such as chat, virtual workspaces, and document repositories for change discussions and decision-making.
  • Links to other ITSM capabilities, in addition to the basics such as deployment management, IT asset management, release management, risk management, service catalog management, configuration management, financial management, service level management, service validation and testing, and supplier management

More recently, ITSM tools have been introducing artificial intelligence (AI)-enabled capabilities - leveraging machine learning and natural language understanding (NLU) - to improve their change enablement/management capabilities. These technologies can assist with things like change categorization or the assessment of risk.

Frequently Asked Questions

Change Management is the practice that prepares and supports individuals and organizations adopt and utilize change in order to reach their desired outcomes.
With ITIL 4, Change Management became Change Enablement. 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.
Change Management surveys are tools to collect feedback from employees within the change management process.
The ADKAR® Model is a change model that represents five milestones a person must achieve in order to change. It’s the first step an organization must take to change successfully.

The five phases of individual change are:

- Awareness of the need for change
- Desire to support the change
- Knowledge of how to change
- Ability to demonstrate new skills and behaviors
- Reinforcement to make the change stick

Evaluate InvGate as Your ITSM Solution

30-day free trial - No credit card needed

Get Started