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 Practise has not changed. This article will thoroughly discuss where and how Change Enablement became the practise of visionary IT departments.
What is the purpose of the ITIL Change Enablement methodology?
To maximise the number of successful IT changes by ensuring that risks have been appropriately assessed, authorising changes to proceed, and managing the Change Schedule.1
This purpose is a powerful statement about Change Enablement:
- Maximise successful changes. To enable the business to react quickly to changing business conditions, the IT organisation must be able to handle more and, especially, more business-initiated changes.
- Accurately assessing risks. By assigning the types of change to the appropriate change authority, Change Enablement optimises risk evaluations and increases the probability of successful changes.
- Authorising changes to proceed. By using change authorities, we increase the speed of change authorisation.
- 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 organisation 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:
Low risk: They never cause an incident.
Pre-authorised: 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.
||High risk requires thorough planning and execution by Project Management executing the Service Value Chain.
||Change Advisory Board (CAB). Input by other Practises.
||Change must be implemented as soon as possible to resolve an incident.
||Emergency Change Advisory Board (ECAB).
Inputs to the Change Enablement Practise
There are 34 ITIL Practises, and none stand alone. Each Practise has inputs from all the other Practises and outputs for all the other Practises. The ITIL Practises are a finely balanced matrix that only works well when all Practises contribute. Each of the 34 ITIL Practises has links to the Change Enablement Practise.
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:
- Used to help plan changes
- Assists in change communications
- Provides information to help avoid change conflicts
- Assigns resources
Deployment Management Practise uses the Change/Deployment Schedule when moving changes to the live environment. In addition, operational Practises 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 practises:
- Assign all deployment/change-related incidents to the Project Manager in the change project. This is called the Early Life Support phase.
- Use Deployment Management Practise guidance to inform all users of the situation and perhaps the workarounds.
- Incident Management Practise 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.
Problem Management Practise:
- Ensures they have a problem record created for this deployment.
- Assists Incident Management in linking all related incidents to the problem.
- Works with Project Management to determine a fix and or workaround.
- Continuous Improvement Practise works with all involved Practises 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 practise calls for Change Enablement BHAGs (Big Hairy Audacious Goals)7
. The following two examples are only the beginning:
IT shall have 80% of all changes to be Standard changes!
- Standard changes, being pre-approved, are efficient for both the Practise and the business.
- 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.
- Standard changes increase user productivity.
- Standard changes are the least costly of the three types of change.
- Automating Standard changes to the point of no human intervention.
IT shall strive for zero defects changes!
- Recognising that every incident is a design flaw, each IT department uses Problem Management to reduce recurring incidents.
- Departments will use IT Practises, 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:
- Desktop support looks at all their different changes.
- Determines which ones could be standard changes.
- Determines the best way to create error-free changes.
- Documents and trains staff to do the change.
- Keep modifying the SOPs and work instructions until they are perfect.
- 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).
- Repeat until 80% of all desktop changes are Standard changes.
- 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, practise, plan, project, or other activity is to succeed. Key Performance Indicators (KPIs) measure the achievement of each Critical Success Factor. For any Practise, there are many CSFs and KPIs. Best practises call for:
- Picking no more than three CSFs and three KPIs for each CSF.
- Prioritising the CSFs that most address your situation.
The following are two main Change Enablement CSF goals:
Responding to business and IT requirements for change helps IT align the services with changing business needs while maximising 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.
Minimise 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 categorised 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 practise is to publish it on the intranet so everyone in the company can find their responsible representative:
Generic Practise owner roles:
- Continuous improvement of the Practise
- Defining the Practise strategy
- Assisting with Practise design
- Defining appropriate policies and standards
- Periodic auditing
- Communicating to everyone to ensure awareness
- Reviewing opportunities for Practise efficiency and effectiveness
- Implementing improvement opportunities for including in the Continual Service Improvement (CSI) register
- Making Practise improvements
||As a member of an IT department (e.g., service desk), representing Change Enablement in the department and ensuring the department follows practises primarily related to increasing the number of Standard changes and reducing change incidents.
||Every IT department should have qualified change practitioners to carry out their changes.
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)
There will usually be different change authorities for each change category. They perform the following:
- Review specific categories of RFC
- Formally authorise 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 unauthorised changes
||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 specialising 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 practise 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 Practises
Change Enablement integration with other ITIL Practises
Anything that changes the live environment must go through Change Enablement. Since all 34 Practises make changes, they will interface with Change Enablement. Here are a few examples:
||This is why we are changing.
|Information Security Management
||Change Enablement puts security requests into the live environment.
||Change Enablement uses Knowledge Management to store documents on best practises, 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.
|Organisational Change Management
||Changing any user-facing service must also address how to encourage of the organisation to adapt to the changes. This partnership is all about ensuring quick acceptance. (See John Kotter's eight steps at the end).
||When the organisation must change the portfolio for whatever reason, Portfolio creates the change proposal.
||Drives all change types using the Service Value Chain.
||This Practise 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 Practise, Change should clarify the cost of making changes, ROI, TCO, etc.
||Suppliers and supplier output carry out many IT changes. For greater change efficiency, Change uses supplier resources.
||This Practise is responsible for coordinating all the suppliers involved in developing and delivering products and services to support change initiatives.
||Ensures that the Change meets SLA warranty-availability goals.
||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.
||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.
||Change integrates with Event Management to gain efficiency in handling emergency changes.
||Problem Management, when performing root cause analysis, identifies known errors. Problem Management creates an RFC for permission to change the live environment.
||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 optimise all value streams.
|Service Catalogue Management
||In a best-practise organisation, automating the Service Catalogue 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 unauthorised changes. SCM must not change the CMS without an approved RFC, and all Configuration Items (CIs) should link to an authorised change (RFC).
||This Practise 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.
||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 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 organisation to change10
Dr. Kotter's seminal book defines a framework for leading change.
We have devoted this entire article to ITIL's best change practises, which are the hard skills for making operational changes.
However, in his book, Kotter lays out the soft skills necessary to successfully change an organisation. Without understanding soft skills, your chances of success decrease.
- Create a Sense of Urgency. Inspire people to act — with passion and purpose — to achieve a bold, aspirational opportunity.
- 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
- 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.
- Enlist a volunteer army. Large-scale change can only occur when massive numbers of people rally around a common opportunity
- Enable Action By Removing Barriers. Remove the obstacles that slow things down or create roadblocks to progress.
- Generate Short-Term Wins. Wins are the molecules of results. They must be recognised, collected, and communicated — early and often — to track progress and energise volunteers to persist.
- Sustain Acceleration. You can guarantee success in complex changes by not skipping any steps.
- Institute Change. Articulate the connections between new behaviors and organisational 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 organisation. 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
- Dashboard provides actionable information to help better organise and streamline your IT change management process and workflow
- ITIL-compliance out of the box, and is highly customisable 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
- IITI® Foundation ITIL 4 Edition, AXELOS Limited 2019, p. 118
- Ibid, p. 119
- Ibid, p. 119
- ITIL Service Transition, TCO, 2011, p. 65
- Ibid, p. 65
- Ibid, p. 120
- Jim Collins, Good to Great, Why Some Companies Make the Leap and others Don't, 2001 adopted to discovering ITIL best practises for running IT organisations.
- Ibid, Service Transition, pp. 88-89
- Ibid, Service Transition, pp. 226-229
- John P. Kotter, A Sense of Urgency, 2008