ITIL says that IT change management should evaluate changes before anyone starts designing or building them, but most organizations don’t start change management until they are ready to deploy the change. I don’t think either of these is right.
Most IT organizations have a process for managing IT changes. This usually involves taking steps to ensure that the change won’t cause things to go horribly wrong. To initiate change management someone logs a request for change (RfC), and the change is then reviewed to ensure that appropriate testing is carried out, that security and other risks are considered, that compliance and other constraints are taken into account, etc. The change management process also schedules changes – to try and prevent conflicts – for example, where one change involves the use of the same resources as another.
One big difference I see between organizations is the timing of the RfC, the point in the change lifecycle when they expect an RfC to be raised.
Most of the IT organizations I see don’t raise an RfC until after they have built and tested the change, and it is at this point that the change management process kicks in to evaluate the change before authorizing deployment to a production environment.
However, according to ITIL (the world’s leading best practice framework for IT service management), organizations should be raising an RfC before anyone designs or builds a change, allowing change management to consider the costs, risks, and benefits before authorizing design activity to proceed.
So which of these is right? What should you do?
You probably won’t be surprised to learn that I think both approaches are wrong. Raising an RfC after the change has been built is far too late to be helpful; and raising it before anyone starts working isn’t going to happen because most organizations have other processes for making investment decisions, they don’t use IT change management for this.
Every organization I work with makes investment decisions, but very few of them call this IT change management because investment in IT changes does not take place in a vacuum. They evaluate all investment opportunities, including IT initiatives, to ensure they are aligned with the goals of the organization, and to prioritize them with other possible investments. These investment decisions are taken by different people in the organization, depending on the type of investment:
In other words, it’s simply not practical to ask most organizations to raise an RfC before deciding to invest in IT changes, and it simply isn’t going to happen.
In most organizations IT change management is not engaged until after the build and test is complete and someone wants to deploy the change. This results in a very inefficient process where everything stalls while change management evaluates the work that has been done and decides whether the change is safe to deploy. Change management is then viewed as an obstacle to change and not a change facilitator.
But if change management is not involved before investment decisions have been made, and raising an RfC is done after the design, then build and test is inefficient and leads to friction. So what can we do?
The trick is to stop thinking about it as an either/or issue, and instead to think about raising an RfC as early in the change process as you practically can.
The problem that faces any change management process is quite easy to understand. How do we evaluate changes fast enough to avoid unnecessary bureaucratic delay, but thoroughly enough to avoid compromising security and integrity of IT services?
Some of my previous blogs offer ideas for making change management more efficient:
I have written about how the change management process can be made more efficient, by using automation, standard changes, and change models to optimize the flow and reduce contention for change management resources. I have also emphasised that evaluating a change does NOT mean you have to arrange a change advisory board (CAB) meeting with lots of managers sitting round a table to discuss changes they may not even understand. Instead, you identify which changes need authorizing, how they need to be authorized, and who has the authority to authorize them.
But even the most efficient change management process takes time, which is why one of the best ways to reduce friction, and reduce delays, in change management is to submit the RfC very early in the change lifecycle.
Even if you don’t use change management to make the investment decision, and even if you don’t yet know when you’re going to be ready to deploy the change, you can submit an RfC with the information you have as soon as you start on the design and build work.
When you do this, you give the change management team time to:
Ideally, regardless of how you initiate changes, and how the resource and funding decisions get made, you should design a complete value chain that takes ideas and transforms them into value for your customers.
Then automate as much of this value chain as you can. This could include automatic submission of an RfC at the appropriate time, with no need for anyone to fill in a form because all the information is already available in the tools that automatically submit the RfC. Most of the RfC evaluation can then be carried out by the tools, and any manual review that is needed can be carried out a long time before anybody is ready to deploy. That way you get the best of all worlds. Every change is evaluated to ensure that it meets your organizational goals for security, risk and compliance, but change management doesn’t delay any deployments.
What triggers an RfC in your organization? Does it happen early enough in the change lifecycle? And when it does happen, does it help you to get things right, or is it just a gatekeeper that delays deployment? Have you thought about how you could use tools and automation to reduce delays, and ensure you meet your goals?
As always, please let me know if you try any of the ideas in my blogs.