ITIL and Change Enablement

How can your all your departments in your business benefit from the ITIL Change Enablement framework?

Change Enablement vs Change Management: What's the difference?

With the ITIL 4 release in November 2018, Change Management became Change Enablement, with a few months as Change Control. The reason was that Change Management never "managed" or "controlled" anything. However, the purpose of this Practice has not changed. This article will thoroughly discuss where and how Change Enablement became the practice of visionary IT departments.

What is the purpose of the ITIL Change Enablement methodology?

To maximize the number of successful IT changes by ensuring that risks have been appropriately assessed, authorizing changes to proceed, and managing the Change Schedule.1
This purpose is a powerful statement about Change Enablement:
  1. Maximize successful changes. To enable the business to react quickly to changing business conditions, the IT organization must be able to handle more and, especially, more business-initiated changes.
  2. Accurately assessing risks. By assigning the types of change to the appropriate change authority, Change Enablement optimizes risk evaluations and increases the probability of successful changes.
  3. Authorizing changes to proceed. By using change authorities, we increase the speed of change authorization.
  4. Managing a schedule of changes. The change schedule helps to reduce change conflicts and increases the speed of the business alignment.

What is the definition of a change in IT?

The addition, modification, or removal of anything that could have a direct or indirect effect on services.2
A change could be software, hardware, documentation, or anything else an organization decides to track in the Configuration Management System (CMS). If it is in the CMS, you must submit a Request for Change (RFC) and get approval before changing anything. No exceptions!

Three types of changes and three types of change authorities

To increase efficiency, ITIL defines three types of changes and three approval authorities3:
Change Type Change Definition Change Authority Change Schedule?
Standard Change
Low risk: They never cause an incident.
Pre-authorized: Once certified, no need for further manual approvals.
Well understood: Detailed work instructions, trained and certified personnel.
The Change Manager defines Standard change requirements.
Once the user meets the criteria, these RFCs receive automatic change approval in the future.
No
Normal Change High risk requires thorough planning and execution by Project Management executing the Service Value Chain. Change Advisory Board (CAB). Input by other Practices. Yes
Emergency Change Change must be implemented as soon as possible to resolve an incident. Emergency Change Advisory Board (ECAB). No

Inputs to the Change Enablement Practice

There are 34 ITIL Practices, and none stand alone. Each Practice has inputs from all the other Practices and outputs for all the other Practices. The ITIL Practices are a finely balanced matrix that only works well when all Practices contribute. Each of the 34 ITIL Practices has links to the Change Enablement Practice.
A Request for Change (RFC) initiates all change activities. The RFC is a formal proposal for a change4 and includes an overview of the proposed change.
Submitters use RFCs for request submission; they are not used to communicate a business decision or to document the change details.
The Change Record is a record containing the details of a significant change5. Portfolio Management usually submits Change Records and the highest levels of strategic business leadership. Each Change Record documents the lifecycle of a single change and spawns RFCs when the time is right. Change Records reference the Configuration Items (CI) affected by the change. In addition, a Change Record should present the business reason and the consequences of not doing the change.
Examples of Change Records are:
  • Switching to a new accounting system
  • A business acquisition
They may not be typical, but the project's significance precedes regular changes.

Why the Change Schedule is so important6

There are four main benefits of publishing the Change Schedule:
  1. Used to help plan changes
  2. Assists in change communications
  3. Provides information to help avoid change conflicts
  4. Assigns resources
Deployment Management Practice uses the Change/Deployment Schedule when moving changes to the live environment. In addition, operational Practices may use the Change/Deployment Schedule. The Service Desk, on launch day, will use the Change/Release Schedule to help when they receive calls related to the changes or outages.
The following are best practices:
  1. Assign all deployment/change-related incidents to the Project Manager in the change project. This is called the Early Life Support phase.
  2. Use Deployment Management Practice guidance to inform all users of the situation and perhaps the workarounds.
  3. Incident Management Practice should guide the Service Desk in how to process incidents related to the change or deployment. They should all have a particular incident field called Change Related Incident, making it easier to calculate user lost productivity caused by the project and to report to Continuous Improvement and Problem Management by looking for the root cause of failures.
  4. Problem Management Practice:
    1. Ensures they have a problem record created for this deployment.
    2. Assists Incident Management in linking all related incidents to the problem.
    3. Works with Project Management to determine a fix and or workaround.
  5. Continuous Improvement Practice works with all involved Practices to assist in returning to normal operations and collect reasons for errors to avoid recurrence.

BHAGs for Change Enablement

Because Change Enablement is critical for continuous improvement and alignment with the business, best practice calls for Change Enablement BHAGs (Big Hairy Audacious Goals)7. The following two examples are only the beginning:
  1. IT shall have 80% of all changes to be Standard changes!
    1. Standard changes, being pre-approved, are efficient for both the Practice and the business.
    2. Standard changes do not require any Change Enablement overhead. No detailed planning. No CAB discussions. Because they never cause incidents, there is no need for Standard changes to be on the Change Schedule.
    3. Standard changes increase user productivity.
    4. Standard changes are the least costly of the three types of change.
    5. Automating Standard changes to the point of no human intervention.
  2. IT shall strive for zero defects changes!
    1. Recognizing that every incident is a design flaw, each IT department uses Problem Management to reduce recurring incidents.
    2. Departments will use IT Practices, including Change Enablement, Project Management, Release and Deployment, Problem Management, and Continuous Improvement toward a zero-defect goal.

Practical steps to accomplishing BHAGs

BHAGs start with senior IT management. Each IT department manager's goal must include BHAGs and holding department heads accountable. For example:
  1. Desktop support looks at all their different changes.
  2. Determines which ones could be standard changes.
  3. Determines the best way to create error-free changes.
  4. Documents and trains staff to do the change.
  5. Keep modifying the SOPs and work instructions until they are perfect.
  6. When perfect, request the Change Manager to make this a Standard change (e.g., easy to learn, easy to follow, no risk, and increased user satisfaction).
  7. Repeat until 80% of all desktop changes are Standard changes.
  8. Regularly publish department progress to demonstrate how Standard changes are working to increase productivity and, as a byproduct, promote IT department rivalry.

Change Enablement Critical Success Factors8

A Critical Success Factor (CSF) defines what must happen if an IT service, practice, plan, project, or other activity is to succeed. Key Performance Indicators (KPIs) measure the achievement of each Critical Success Factor. For any Practice, there are many CSFs and KPIs. Best practices call for:
  1. Picking no more than three CSFs and three KPIs for each CSF.
  2. Prioritizing the CSFs that most address your situation.
The following are two main Change Enablement CSF goals:
  1. Responding to business and IT requirements for change helps IT align the services with changing business needs while maximizing value.
    • KPI - Increase the percentage of changes that meet the customer's agreed requirements for quality, cost, and time.
    • KPI - The benefits of change (expressed as "value of improvements made" + "negative impacts prevented or terminated") exceed the costs of the change.
  2. Minimize overall business risk.
    • KPI - Reduction in the number of disruptions to services, defects, and re-work caused by inaccurate specifications, poor or incomplete impact assessment.
    • KPI - Reduction in the percentage of changes categorized as Emergency changes.

Change Enablement roles and responsibilities9

The following are examples of the various roles for Change Enablement. Each company should document these in great detail for their business needs. The best practice is to publish it on the intranet so everyone in the company can find their responsible representative:
Roles Responsibilities
Practice Owner Generic Practice owner roles:
  • Continuous improvement of the Practice
  • Defining the Practice strategy
  • Assisting with Practice design
  • Defining appropriate policies and standards
  • Periodic auditing
  • Communicating to everyone to ensure awareness
  • Reviewing opportunities for Practice efficiency and effectiveness
  • Implementing improvement opportunities for including in the Continual Service Improvement (CSI) register
  • Making Practice improvements
Practice Manager As a member of an IT department (e.g., service desk), representing Change Enablement in the department and ensuring the department follows practices primarily related to increasing the number of Standard changes and reducing change incidents.
Practice Practitioner Every IT department should have qualified change practitioners to carry out their changes.
Change Initiator Many people outside and inside IT may create RFCs as part of their responsibilities:
  • Identifying the requirements for a change
  • Completing and submitting a change proposal if appropriate
  • Completing and submitting an RFC
  • Attending CAB meetings to provide further information
  • Reviewing changes when requested by Change Enablement, and specifically before closure as part of the Continuous Improvement review
  • Enter improvement ideas into the Continuous Improvement Register (CIR)
Change Authority There will usually be different change authorities for each change category. They perform the following:
  • Review specific categories of RFC
  • Formally authorize changes at agreed points in the change lifecycle
  • Participate in the change review before closing changes
  • Attend CAB meetings to discuss and review changes when required
Change Adisory Board (CAB) Members Any IT or business individual may join the CAB as a regular member or a guest:
  • Participating in CAB meetings
  • Authority to represent a particular group or IT department
  • Prepares for CAB meetings for their group (RFC, issues, etc.)
  • Reviews successful and failed changes
  • Reviews the Change Schedule to help identify conflicts
  • Reviews unauthorized changes
CAB Chair Single person assigned to call and manage CAB meetings. They ensure recordings of meetings are created, stored, and protected.
Emergency Change Adisory Board (ECAB) Members There may be many variations to the ECAB (Generic ECAB or ones specializing in specific corporate systems):
  • To expedite swift handling of emergency changes, the ECAB may require an automated RFC before practitioners begin restoration
  • After the emergency, a best practice is for the ECAB to review the input of all parties as part of continuous improvement's goal of reducing or eliminating emergency changes (i.e., the cause should not be a failure to perform regular maintenance)
  • ECAB members participate in continuous improvement with the Incident, Problem, and Service Desk Practices

Change Enablement integration with other ITIL Practices

Anything that changes the live environment must go through Change Enablement. Since all 34 Practices make changes, they will interface with Change Enablement. Here are a few examples:
Practice Exchange
Continual Improvement This is why we are changing.
Information Security Management Change Enablement puts security requests into the live environment.
Knowledge Management Change Enablement uses Knowledge Management to store documents on best practices, service reviews, and templates. No need to ever create a new form. The Service Knowledge Management System (SKMS) accuracy and inclusivity is the goal of Visionary IT departments.
Organizational Change Management Changing any user-facing service must also address how to encourage of the organization to adapt to the changes. This partnership is all about ensuring quick acceptance. (See John Kotter's eight steps at the end).
Portfolio Management When the organization must change the portfolio for whatever reason, Portfolio creates the change proposal.
Project Enablement Drives all change types using the Service Value Chain.
Risk Management This Practice is part of every change approval to ensure the appropriate reviews of risks to help prevent bad things from happening.
Service Financial Management Using the guidance of this Practice, Change should clarify the cost of making changes, ROI, TCO, etc.
Supplier Management Suppliers and supplier output carry out many IT changes. For greater change efficiency, Change uses supplier resources.
Service Integration This Practice is responsible for coordinating all the suppliers involved in developing and delivering products and services to support change initiatives.
Availability Management Ensures that the Change meets SLA warranty-availability goals.
Business Analysis Change works closely with Business Analysis to meet the business needs.
Capacity & Performance Management Ensures that the changes still meet SLA capacity and performance warranty goals.
Incident Management Change is always required to respond to incidents. Since all incidents mean lost user productivity, Change efficiency can help reduce incident interruptions. In addition, Change must avoid any change-related incidents.
IT Asset Management When Change moves assets within the live environment, they must ensure updates to the IT Asset record.
Event Management Change integrates with Event Management to gain efficiency in handling emergency changes.
Problem Management Problem Management, when performing root cause analysis, identifies known errors. Problem Management creates an RFC for permission to change the live environment.
Release Management Once a change is corrected, Release must test it to validate that the service change works. Release Management has a tight connection with Change and all processes, and they should optimize all value streams.
Service Catalog Management In a best-practice organization, automating the Service Catalog for standard changes is of the highest efficiency goals. The response is to fulfill Standard change requirements quickly.
Service Configuration Management (SCM) SCM and Change must work together to stop all unauthorized changes. SCM must not change the CMS without an approved RFC, and all Configuration Items (CIs) should link to an authorized change (RFC).
Service Design This Practice is responsible for the design of all products and services. Incidents, problems, and changes must provide feedback to Service Design. Ultimately, for most incidents, poor design is the root cause.
Service Desk The Service Desk is the Single Point of Contact (SPOC) between IT and users. Working with the Service Desk and the Change Schedule helps prepare the Service Desk for possible errors in the delivery of the change.
Service Level Management The Service Level Agreements (SLAs) often provide users with change windows. Change should make sure to follow the SLAs to meet user expectations.
Service Request Management Many service requests are Standard changes. Change, working with Service Request, can increase efficiency, automation, user communication, and user satisfaction.
Service Validation & Testing (SVT) SVT tests the change and the release many times throughout the development lifecycle. Change validates the test, permitting the next level of testing.
Deployment Management Deployment Management moves the tested release to the live environment. Supporting users during early deployment requires Change support during this time to increase user satisfaction during Early Life Support.

John Kotter's Eight Steps for transforming your organization to change10

Dr. Kotter's seminal book defines a framework for leading change.
We have devoted this entire article to ITIL's best change practices, which are the hard skills for making operational changes.
However, in his book, Kotter lays out the soft skills necessary to successfully change an organization. Without understanding soft skills, your chances of success decrease.
Dr. Kotter's 8 Steps to Change Transformation
ITIL Change Enablement, along with all the other Practices, is a perfect fit for implementing Dr. Kotter's eight steps:
  1. Create a Sense of Urgency. Inspire people to act — with passion and purpose — to achieve a bold, aspirational opportunity.
  2. Build a Guiding Coalition. A volunteer network needs a coalition of committed people — born of its ranks — to guide it, coordinate it, and communicate its activities
  3. Form a Strategic Vision. Clarify how the future will differ from the past and get buy-in for how you can make that future a reality through initiatives linked directly to the vision.
  4. Enlist a volunteer army. Large-scale change can only occur when massive numbers of people rally around a common opportunity
  5. Enable Action By Removing Barriers. Remove the obstacles that slow things down or create roadblocks to progress.
  6. Generate Short-Term Wins. Wins are the molecules of results. They must be recognized, collected, and communicated — early and often — to track progress and energize volunteers to persist.
  7. Sustain Acceleration. You can guarantee success in complex changes by not skipping any steps.
  8. Institute Change. Articulate the connections between new behaviors and organizational success, ensuring they continue until they become strong enough to replace old habits.

The benefits of the Change Enablement methodology

Visionary IT is all about change. It is about documenting value streams and encouraging people to follow the activities, workflows, controls, and procedures needed to achieve the agreed objectives. By measuring the results using balanced metrics, it is possible to see waste everywhere in every organization. It was just not evident in the noise.
When waste shows up, use Continual Improvement to define a clear path for change. Use Change Enablement following the eight steps for leading change. First, encourage the business to show its vision of what it needs to be successful. Then let Change Enablement quickly and effectively change to realign IT to the company vision.
"If you dislike change, you're going to dislike irrelevance even more."
- General Eric Shinseki

Conclusion: Yes, you need a Change Enablement tool

Giva is the platform of choice for change management / change enablement:
  • Dashboard provides actionable information to help better organize and streamline your IT change management process and workflow
  • ITIL-compliance out of the box, and is highly customizable without programming or consultants
  • Deploy and train in just hours
  • Approval process is simple to configure and use, with inline workflow help pages to assist
  • Simple and intuitive approach to Standalone Change Management
  • Interactive RFC monthly calendar provides an overview of the entire change management process
  • Easy to use change request, approval and change control workflows
  • Hardware & software assets can be linked to change requests
  • Weekly view of RFC calendar assures that changes do not conflict
  • Robust, fast & painless compliance reporting for higher quality decision-making
Footnotes:
  1. IITI® Foundation ITIL 4 Edition, AXELOS Limited 2019, p. 118
  2. Ibid, p. 119
  3. Ibid, p. 119
  4. ITIL Service Transition, TCO, 2011, p. 65
  5. Ibid, p. 65
  6. Ibid, p. 120
  7. Jim Collins, Good to Great, Why Some Companies Make the Leap and others Don't, 2001 adopted to discovering ITIL best practices for running IT organizations.
  8. Ibid, Service Transition, pp. 88-89
  9. Ibid, Service Transition, pp. 226-229
  10. John P. Kotter, A Sense of Urgency, 2008
Bart Barthold

About the Author

Bart Barthold

Bart Barthold is an independent senior ITIL instructor with years of experience in combining ITIL knowledge with practical expertise in running a world-class support organization. He has earned the certificate for the highest level of ITIL training - IT Service Manager, holds an MBA, and he has taught various ITIL certifications and hundreds of students since 2004.
Bart is known for his outstanding performance in IT service management and is a recipient of the Help Desk Institute's prestigious Team Excellence Award in 1998. He also finished second in 1997, making him one of the most decorated IT service managers in the industry.
Request a Live Demo
See It In Action
Assess Your Needs
Get the Tool
Try Giva's 30 Day Trial
Sign Up Today