ITSM Wars, Episode VII: The Standard Change Awakens
A long time ago, in an IT department far, far away….
It is a period of unrest for developers and operations teams.
IT management, in an effort to gain control of unruly infrastructure changes and prevent unplanned outages (as well as stop getting yelled at by the CEO), implemented the ITIL® process of Change Management. While problems caused by changes have dropped well below the industry average of 80%, IT staff has grown tired of having to wait for a month to make a simple change, only to have it scrutinized by the evil Darth Change Manager and the Imperial Change Advisory Board.
Even now, users grow frustrated and restless with IT’s lack of flexibility to meet their demands, sowing the seeds of change for Change Management…
By yours truly from Dreamland
While it’s unlikely that the creative writers at Disney would actually adapt my new script, for Star Wars Episode VII, it does reflect my feelings from a conversation I had at the Interop conference in New York a few weeks ago. To give a quick summary, a developer I spoke with wasn’t happy with the current change management process that his IT department implemented a few months back. Some of the reasons:
- It was required to give a month lead-time to submit a change.
- When creating a change request in the system, all known information had to be added to the form before it would ever go onto the change calendar, resulting in changes being submitted at the “last second” and without planning around other changes.
- Additional approvals and a complicated change advisory board (CAB) process created a bottleneck on putting changes into production.
- Even the simplest of changes had to follow the same scrutinizing process required by a complicated downtime, resulting in simple requests from the business taking over a month to implement.
In summary, while the change management process was helping to minimize risk, it wasn’t achieving the second goal of allowing IT to work efficiently. In fact, the only thing the process did was cause everyone to submit last-minute, emergency changes due to the lack of flexibility.
Introducing the Standard Change
While a change management process is meant to reduce risk, there’s also a powerful subprocess mentioned in ITIL (the ITSM best practice framework) called standard change, which helps improve the efficiency of IT by allowing commonly performed changes to be implemented with a minimal amount of bureaucratic overhead. There are two criteria for a change to be considered standard. They are:
- It must be a low risk to disruption of services
- It must be a repeatable change with defined procedures
The idea of a standard change process is to allow the common, low risk activities to be implemented without long periods of reviews, and without requiring multiple approvals that can slow down the pace of new deployments.
Reducing the Risk
Change management is all about risk reduction. This can be accomplished in two ways. First, by scrutinizing every change to ensure that there won’t be an impact to services. While such a method is effective, it also creates the bureaucratic headache of a long period of time to push a change request through the process.
The second way to reduce risk is to simply make the changes that:
- Have pre-defined procedures in place
- Are proven to have low failure rates
- Can be made on services that are designed with high availability, especially those that have cloud or virtualized components.
These types of changes, which are the described standard changes, meet the second goal of change management: to allow IT to meet demands from the business.
Setting the Standards
Now you know that the idea of standard changes is to help IT quickly change with reduced risk, the next step is to start building your change management process to incorporate standard changes. Since each organization functions differently, there are no “quick-fixes” for everyone, but there are a few general steps that can help your process:
- Establish what types of changes are considered to be standard.
Typically, standard changes are common practices such as regular maintenance, low-risk data changes, or even changes to high-availability environments that have failover mechanisms.
- Build a process to identify standard changes and to have an initial review to authorize a change to be standardized.
The process should include the submission of artifacts, such as procedures, as well as historical information that indicates the low-risk practice of the change.
- Update your change management process to allow the submission of standard changes.
Standard changes should still be reviewed by the change advisory board (CAB), but the submission process should be simple with a minimal amount of approvals.
- Update your ITSM solution to use templates for approved standard changes.
Based on the definition of standard changes established by your organization, the templates should pre-fill as much information as possible.
- Create your environment around the idea of standard changes, and not vice versa.
While the first step is to identify common activities that can be considered standard changes, the final step in maturity is to start modifying your IT environment to allow as many standard changes as possible. Such activities involve creating standard procedures, utilizing virtualization and cloud technology, and automating the common IT changes to minimize labor and improve efficiency.
Preparing for the Future of IT
I’ll be honest, I also have my own personal reason to consider using standard changes. While it’s great to improve efficiency and reduce risk during change management, thanks to cloud and virtualization technologies, there’s a growing trend to automate IT operations. With automation comes the requirement to create procedures to quickly deploy new resources into production. It’s these changes that are pushing IT to centralize workflow around standard changes as the primary workflow option. Currently, the term “normal change” is used to describe the regular change management procedure, complete with CAB review and the usual scrutiny. In the future, normal changes will be considered “abnormal,” and standard changes will be the “new normal.”
Additional Resources
As I already mentioned, the change management process is key to having IT meet business demands while minimizing risk during implementation and changes to IT systems. If you’re just starting out down the change management improvement journey, I recommend you check out Stuart Rance’s blog on Defining Metrics for Change Management, which can help you build a baseline from which to improve your change management process.
