How to make IT change management work for everyone
Change management is often a point of friction in IT organizations. This is because it can act as a blocker, causing delays and frustration, but not adding enough value to offset the difficulties caused by deferring and sometimes denying proposed changes. Organisations often hope to reduce delays and friction by improving the efficiency of their change management process, and this can be helpful. But all too often the result is still an “us and them” situation, with one set of people trying to get changes implemented, and another set of people blocking them.
I think there may be a better approach to change management. Instead of just focussing on the step where a change requires approval, change management needs to be actively involved in planning the whole, end-to-end, process.
Making change approval more efficient
Many organizations have made great improvements to their change management process simply by increasing their efficiency. This can be enough to reduce friction and help conflicting groups to work together with fewer issues. Typical approaches to achieve this include:
- Using standard changes. These are well-defined, low-risk changes that are pre-approved. This means that people don’t need to wait for permission to make these changes. They just follow the agreed process and make them. Examples of standard changes could be replacing a PC or printer with a newer model, increasing the amount of storage allocated to a service, or creating a standard account for a new user.
- Delegating change authority. This means someone who is able to respond faster than a typical change advisory board (CAB) has the authority to approve lower risk changes. For example the infrastructure manager may be allowed to authorize installation of firmware updates to non-critical servers and storage.
- Using change models. This means pre-defining the steps taken to implement a change, so that you save time and effort every time that change has to be reviewed, approved and implemented. For example, there may be a standard process for deploying operating system security patches, so that everyone knows which servers are updated first, and what testing is required.
These things all help to make change approval more efficient, but they don’t fix the underlying conflict.
Making change approval part of an end-to-end process
When I think about how to improve IT service management, I often start with the ITIL Practitioner guiding principles. If you’re not familiar with these then please read about them on the Axelos web site.
Two of those principles are Focus on Value and Work Holistically. What they suggest is that thinking about “change authorization” or “change management” isn’t quite good enough; we need to think about something much wider than that. We need to understand that change management is part of a business process, not just an IT one. The goal of the process is to deploy IT functionality to support our customers; change management is just one necessary step along the way. So clearly, we need to view change authorization as part of that end to end workflow. And when we design that end-to-end workflow we must include change authorization as part of the wider process, instead of as a separate, add-on ITSM activity.
The best way to do this is to follow two further guiding principles, Collaborate and Keep it Simple. If you take these ideas seriously they should help you to create a process where changes simply flow through into production without the need for delay when they need to be approved.
Here’s a practical example. Let’s suppose that, when they are ready to deploy a change, you currently ask people to submit a “request for change” (RfC) to initiate change management. You then start to assess the change, by thinking about the risks, the urgency, and the benefits it will create. You may decide on a minimum level of testing needed, or decide to reject a very risky part of the change while accepting the rest. The chances are that there would be far fewer delays, and much less friction, if submitting the RfC happened automatically, and much earlier in the lifecycle of your change; and this would allow you to start the assessment much earlier. Following this approach you would already have authorized the change by the time it is ready for deployment. The diagrams below highlight the difference between a typical change management process and the one I’m suggesting.
Figure 1 - Typical change management process with RFC submitted after testing
Figure 2 - Suggested end-to-end process
This suggested new process has not removed any activities, it has just optimized the flow by performing the change assessment in parallel with other activity, so that change management is no longer acting as a brake on the overall process. Combine this with suitable automation, and other suggested improvements such as use of standard changes, delegated change authority and change models, and the result is a streamlined process, with conflicts reduced, collaboration facilitated and a sharper focus on helping customers to succeed.
One organization I worked with achieved something very similar to what I am describing here. The first step was to assign a single process owner for the end-to-end process. The process owner did not manage the activities, or the people, but was responsible for the design of the process, the tools and the metrics. Since they could only achieve this by collaborating with the people responsible for all the other steps, they developed a solution that was optimized for everyone, and thus easily accepted. No additional effort was needed to submit an RfC because the required data was already available as part of previous activities, and the RfC was submitted automatically.
What about Agile and DevOps environments
The suggestions above are just as appropriate for organizations that use two-week sprints to develop new functionality as for organizations that use the more traditional waterfall approach. The time for all of the steps may be much shorter, but the idea of carrying out a change assessment in parallel to the other work, to reduce friction and avoid potential delays in deployment is just as valid.
In a very fast moving DevOps organization there may be 10s or even 100s of deployments every day, but you should still carry out a suitable assessment of each change before it is deployed. This may not involve the same types of RfC forms and formal meetings as in a legacy IT organization, but the principle still holds – before you deploy new functionality you should always assess the risks, benefits and urgency. The only variables are who does this assessment, and how they document their findings.
If change management is a source of friction or conflict in your organization then you’re not alone, but it is possible to fix this. Think about what your real goals are, and design an end-to-end process that works for all the people involved, with a clear focus on delivering value to your customers. Optimize your change management activities, and try to carry them out in parallel with other activities rather than at the end, so that they don’t introduce friction and delay into the process.
As always, I’d love to hear about your experiences. Do let me know what happens when you try the ideas in my blogs.
Image Credit: tracyshaun