Understanding the Common Service Data Model (CSDM) in ServiceNow
The Common Service Data Model (CSDM) serves as a unified framework that helps organizations manage and illustrate their services and related data…
Change Enablement (the artist formerly known as Change Management) entered the ITIL vocabulary with the release of ITIL 4 in 2019. The name change signaled a meaningful shift in how change was meant to function within organizations, moving away from rigid process ownership and toward supporting the flow of work. Before getting into the details of the practice itself, it’s worth taking a moment to level-set on what Change Enablement was designed to accomplish.
In order for organizations to thrive in today’s digital world, the ability to deliver new, exciting products and services to customers—and do so quickly—is essential. With that said, one of the things we have to be sure of while delivering these products and services is that we are very clear (and protect ourselves) when making changes along the way.
The Change Enablement practice in ITIL 4 provides lots of recommendations and ideas on how to make frequent changes and, at the same time, lessen the chance that we’ll take something really important down as a result. It’s like putting breaks on a car; we don’t use our breaks all the time, but they are critical when needed.
Let’s first define what we mean by “change” in the first place. Here is the definition from the new ITIL 4 practice (with my own notes added in brackets): Change is the addition, modification, or removal of anything that could have a direct or indirect effect on [technology-supported products and] services.
When we make changes in our often highly-connected organizations, we have the potential to impact other teams, services, applications, customers, etc. Here’s where the Change Enablement practice can help.
At the end of the day, the way in which we manage change needs to benefit our organization and, ultimately, our customers. We should not introduce crushing bureaucracy or force teams to wait for approvals, thereby slowing the organization down. Further, we only need to focus on those changes that have a direct impact on delivering products and services to customers.
Our customers need to tell us how quickly change should happen; and we don’t have to have a traditional Change Advisory Board (CAB) in place to discuss all of our changes together. Changes can, and should, be reviewed by decentralized teams so work can continue to get done quickly and safely. More on that in the next section.
Here are three premises detailed in the practice (emphasis and notes added):
Here are a few, quick examples from our Senior Advisor, Mark Hillyard, on how Change Enablement transforms and enhances the Change Management process. If we consider the industry shift to high velocity development (and thus, higher velocity change) within IT, the ideas presented by the Change Enablement practice align with how software development teams are working.
Take, for example, a fully functioning DevOps environment that has embraced Continuous Integration/Continuous Deployment (CI/CD). This model eliminates nearly 100% of the human interaction involved in code releases to production environments. In the Change Management process from ITIL v3, this would be practically impossible to accommodate. The CAB would need to be meeting nearly continuously in order to review, authorize, and schedule every change. The very idea is crazy. Instead, by creating a tailored change authority, each autonomous development team could establish its own method of authorization. If deployment is truly continuous (many times per day), then a daily stand-up describing upcoming releases could serve as the baseline for authorization and scheduling. A team lead would act as the change authority, and the user stories (along with their acceptance criteria) included in each release would serve as the documentation, satisfying operational teams’ needs for transparency and knowledge sharing.
A less extreme example of this improved practice might include an Agile development team that has a stable frequency of change (releases every two weeks). This may seem like a system that could easily fit into the CAB model, but as the goal of Change Enablement is to ensure higher volumes of successful change, bogging a development team down in the plodding nature of CAB meetings would likely extend the project overall, and actually slow the development velocity (if not the frequency of change). This does not serve our customer very well, forcing them to wait on approvals rather than delivering on their timeline. Additionally, the people most suited to provide meaningful risk assessment are likely the developers themselves. Thus, it would make sense to create a change authority within the development team that can quickly analyze and schedule each change. Here, a sprint review prior to deployment would provide an excellent backdrop for assessment and authorization.
As you can see, Change Enablement has the potential to create significant efficiency within your organization.
For those of you familiar with ITIL v3’s Change Management process, here is a quick overview of some of the major changes to this practice.
The ITIL 4 Change Enablement practice introduces the idea of responding differently to varying levels of complexity, from the routine stuff (handled via the Standard change category) to the catastrophic stuff (handled via Emergency procedures). The diagram below shows the range of complexity and responses to change.
The idea of a CAB is de-emphasized in the Change Enablement practice. To quote ITIL guidance directly, “Changes require resources and introduce risks. This sometimes leads to organizations establishing complicated, often bureaucratic systems of change authorization, with formal committees that meet regularly to overview and authorize changes accumulated over the period. These are known as Change Advisory Boards (CABs). CABs often become bottlenecks for the organization’s value streams. They introduce delays and limit the throughput of Change Enablement.”
Not so flattering. The idea of the CAB has been, for the most part, replaced by the idea of having some sort of “Change Authority.” This may seem like a small change, but it’s actually a pretty big shift. Organizations are moving away from the idea of forcing their people fill out 2,485 pieces of information, wait for a weekly CAB meeting, and then have to defend their change to be able to make it (no wonder everyone hated submitting changes). The CAB concept is being replaced by peer reviews, automated testing and authorization, and daily stand-ups to approve team-level changes. Those that authorize changes are now called change authorities.
This definition leaves the door open as to how changes are authorized and by whom. Further, the practice recommends breaking changes into smaller pieces to lesson risk in the first place. As a result, changes can happen at the pace our customers need them, not the other way around (where customers are waiting for the CAB to approve changes).
ITIL goes on to say about the practice, “In product-focused organizations, job titles and job roles are not typically adopted for Change Enablement, as this practice is integrated in the day-to-day activities of product development teams and is automated wherever possible.”
Here are some additional ideas mentioned in the new ITIL 4 practice that I really like and have found to be helpful when approaching how we manage changes:
I also like that the practice includes simple workflow examples for handling different types of changes (e.g., when handling automated software changes) along with ideas on defining Practice Success Factors (PSFs).
If you took any sort of ITIL training prior to 2019, this practice (then referred to as a process) was called one of two things: Change Management or Change Control.
If you took your ITIL training before February of 2019, it was called Change Management. This is the verbiage that most people still use. However, there was confusion around the difference between IT-related Change Management and Organizational Change Management. And when ITIL 4 was released in February of 2019, the name changed from the Change Management process to the Change Control practice.
If you took an ITIL 4 Foundation class sometime between February and August 2019, you will have learned the term Change Control. Unfortunately, when ITIL 4 terminology was tested across a global audience, the phrase “Change Control” brought new confusion with it. The name didn’t resonate with many organizations, especially those embracing faster ways of working like Agile and DevOps, and it was assumed that Change Control had the potential to slow organizations down. So, the name was changed to Change Enablement to more accurately reflect the true intent of the practice. Having an efficient and effective Change Enablement practice actually helps organizations speed up how work gets done and still protects us from downtime and resulting issues when changes go sideways.
No, the irony is not lost on me that the name for the practice that discusses change keeps changing 🙂 But change is inevitable.
