ITIL change management is designed to be simple and streamlined, and when it’s done right, it is both. However, it’s often the most intimidating service desk implementation for a number of reasons. On the surface, some decision-makers see an overly-bureaucratic process, too bogged down in details, definitions, and approvals. In addition, the thought of ripping up the current practice (however ineffective) and putting in something new can be daunting.
There are a ton of educational resources available to define types of changes, how change management differs from (and relates to) release and deployment, what a change flow looks like, and different roles within the process according to ITIL. A quick search on “IT change management” will call up a number of guides and flowcharts.
While that is all valuable information, it can be very dense, and we will not discuss it in this post. Sometimes those definitions, titles, and flowcharts contribute to the intimidation factor. Instead, I would like help you identify some signs that your process might need improvement, and the benefits of building a change management strategy within your service desk solution. Once you understand the tangible rewards of a change management overhaul, the details of how to construct that strategy are much more consumable.
Why Build a Change Management Process?
Let’s think about all the possible IT changes that impact the organization: application changes, software updates, server upgrades, changing device models… there are almost infinite possibilities. There are routine changes and urgent changes that have immediate business impact. Depending on the size of an organization, these types of changes happen daily, or even multiple times per day.
There are formal processes for almost every other frequent occurrence in an organization, and IT changes are no different. Proper evaluation, implementation, and success of these changes are crucial to every IT department because they can impact so many different business units. Not only is success important, but so is efficiency. Painful approval processes and slow rollouts can cost an organization time and money. A well-designed change management process will minimize risk and service disruption for every change your organization makes.
Think about it this way:
If there are 50 changes per month and you can shave an hour off of your process, that’s 50 hours for your IT team, and 50 hours for your organization to operate with key upgrades. With an efficient process, the most impactful changes will be done more quickly, and there’ll be more time for some lower priority (yet, still important) changes that were previously kicked down the road.
If software changes are causing employees to submit tickets about installations or how-to questions, your team will spend valuable time troubleshooting these issues that could have been preempted during the change management process.
A well-designed change management process will minimize risk and service disruption for every change your organization makes.
Signs Your Process Can Improve
Again, before we get into the weeds with definitions and ITIL processes, ask yourself (and your team) these questions if you want to identify some areas to improve:
Are you logging every change request?
The practice of documenting every request will create a habit for requesters to justify the change and consider the scope and impact. It will also create a database of records for changes that have been considered, which will be especially useful in tracking approved changes or revisiting rejected changes.
Is the process dependent on email?
Email is inefficient for a number of reasons. If someone is out of the office, the change will be delayed. If the requester doesn’t realize that other parties need to approve the change, it’s an extra step (and an opportunity for a communication breakdown) to loop in the appropriate parties.
Are changes categorized and prioritized in an organized way?
Categorizing changes by scope and impact can help determine priority, which should determine the way a change is evaluated and implemented. Obviously, critical priority changes will be treated quite differently than standard requests.
What is the review and approval process, and is it automated as much as possible?
Are there different parties always involved in approvals for respective types of changes? Many organizations use a change advisory board (CAB). However you want to divide responsibilities, you should build workflows that push approvals to individuals or groups depending on the type of change request. This will make the entire process far less manual and time consuming without sacrificing the level of scrutiny required to minimize risk.
Are you aligning related changes?
If you’re making two different updates to a group of devices, you might be able to plan and implement those changes together. The more organized your process is, the less risk and/or disruption to your employees.
How does a requester track the status of a change?
Visibility is key, especially in an instance where more information might be required for certain approvals. If the requester can’t track the change, create an access point beyond email inquiries.
Are you tracking the impact on related IT assets, incidents, problems, and releases?
These are all closely connected. Changes have impact, which is why you’re making them. You’ll want to track any devices impacted by the change, plus any incidents or problems that might be related to the change, even after a change request is closed. These can all affect future changes, or even improvements with that individual change.
The best IT departments are constantly looking for ways to improve. Since today’s organization is so reliant on devices, software, applications, and other technology, IT change management plays a crucial daily role in business functions. It’s more important than ever to look for ways to maximize diligence and efficiency.
