When ITIL® 4 Foundations was released, many of us were surprised to learn that Change Management had become Change Control. The logic behind the switch however made sense. For years, ITIL® Change Management and Organizational Change Management had been a source of confusion.
With Organizational Change Management now being a practice within ITIL® 4, the confusion was likely to continue. I experienced this when I was hired into a company with the title of Director of Change Management. Shortly after assuming the role, I found that the changes I was expected to provide direction over were not changes to the services or service components, but rather the changes needed to transition the organization from being paper-based to one where the business functions were managed using SAP.
While the high-level goal is the same (move from a current state to the desired state) the skills needed differ greatly between the two. Where Change Management/Control focuses on changes to products and services, Organizational Change Management focuses on managing the behaviors and attitudes of people to ensure that the organization can successfully transform and implement the needed improvement initiatives.
So, while the switch away from Change Management made sense, the choice of Change Control was counterintuitive. Control implies exercising restraint or reducing the incidence of something while the purpose of the Change practice, according to ITIL®, is in part to “maximize the number of successful changes….”. Many, especially those in the DevOps community, found the use of the word “control”, in relation to change, was sending the wrong message. The folks at Axelos listened and, following the ITIL® Guiding Principle “Progress Iteratively and with Feedback”, have now changed (no pun intended) the name to Change Enablement.
If you have already taken ITIL® 4 Foundation Training and learned the name as Change Control, all is not lost. While the name has changed, the purpose, the types of changes, (Standard, Normal, and Emergency) and the basic activities within the practice now known as Change Enablement remain the same:
Change Review and Closure
What does seem to be changing for many organizations, however, is the frequency and speed with which changes must be performed. One of the drivers behind ITIL® 4 is the need for organizations to increase the speed in which they respond to changing business needs. With the integration of other frameworks and methodologies like Agile and DevOps into the ITIL® framework the approach to “Change Enablement” is likely to evolve for many organizations, primarily in the way that changes are authorized. Many organizations are finding that a weekly Change Authorization Board (CAB) meeting no longer meets their needs. ITIL® 4 Change Enablement recognizes this state that “The person or group who authorizes a change is known as a Change Authority.” ITIL® 4 goes on to state that in “high-velocity organizations, it is common practice to decentralize change approval, making the peer review a predictor of high performance.” For many organizations this means allowing some changes to be authorized by a Product Owner in an Agile or SCRUM team; Only changes that are complex or involve multiple groups are reviewed and authorized as part of a larger CAB.
In the end, it is not whether you call it Change Management, Change Control, or Change Enablement that matters, but rather that you can effectively and efficiently implement beneficial changes that provide the value needed while protecting the business, customers, and users from any adverse effects.