ITIL and Change Enablement

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

What is the purpose of the ITIL Change Enablement methodology?

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?

Three types of changes and three types of change authorities

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

• Switching to a new accounting system
• A business acquisition

Why the Change Schedule is so important⁶

1. Used to help plan changes
2. Assists in change communications
3. Provides information to help avoid change conflicts
4. Assigns resources

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

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

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 Factors⁸

1. Picking no more than three CSFs and three KPIs for each CSF.
2. Prioritizing the CSFs that most address your situation.

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 responsibilities⁹

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

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 change¹⁰

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

Conclusion: Yes, you need a Change Enablement tool

• 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