One of the most annoying practice that I’ve learned ten years ago when I was a data center engineer is change management. Change management is a formal process that defines a set of procedures and steps to manage all changes, updates, or modifications to hardware and software (systems) across an organization. My personal definition of change management in IT is summarized in this simple phrase: “all the fluff that has to be done just to get the job done.”
As an IT professional who is highly productive and efficient, writing documentation about how a change should be implemented and getting it approved when I can simply make that change in less than an hour is annoying. I get to spend 2 hours writing a change request form that includes all of the changes that I need to make, with all the possible risks and rollback steps in case everything went wrong for a task that will take less than half an hour. It’s a total waste of time, hence, I was annoyed. I even argued with the team responsible for reviewing the change requests forms about the inefficiencies caused by the whole “process” given the fact that we still need to get the work done. The one thing that I didn’t do was ask why. Why was it needed in the first place?
Risk Mitigation: Every Business’ Goal
Being in business is risky. Ask every business owner and investor and they’ll tell you the same thing. The last thing that they want in a risky activity is to be exposed to even more risk. Which is why they take every possible measure to reduce the risk exposure. And when IT assets are utilized to help achieve business objectives, our job as IT professionals is to help reduce risks.
When an IT asset is used to generate revenue, the goal is to make sure that it keeps generating revenue. The e-commerce site needs to be protected, the application response time should be quick and has to be always available. That’s the idea behind the S.P.A. We secure the system, we improve performance and we make it highly available.
But IT assets don’t remain as they are. Databases grow, demand increases, vulnerabilities are discovered. As a result, we respond by making the necessary changes – we upgrade the hardware and the software. But those changes may introduce unknowns that may impact the way the IT assets behave. Introducing unknowns also introduces risk. And we’re back where we started. It’s a never-ending cycle and it’s a fact of life. We can’t escape it but we need to be smart about dealing with it. Enter change management.
The Process Is The Key
I’ve heard one of my previous customer complained about how their disaster recovery plan didn’t work after failing over to the standby. Their application could not connect to the database because of incompatibilities with the drivers used – a 32-bit driver was used instead of a 64-bit one. One of the initial question that I asked was, “do you have a change management process in place?” There was a long pause. I already knew what was wrong.
Part of change management is the identification of potential risks introduced to the existing IT infrastructure. But what a lot of IT professionals don’t realize is that it also builds the habit of “we can’t do that in production without approval.” Someone needs to approve the change before it gets done. Somebody will have to implement the change. Which simply means somebody will be held accountable. And when accountability is included in the process, we all take our jobs seriously. Part of that accountability is somebody updating the runbook/documentation to include the changes made to the system. Ah, the dreaded documentation.
Do you see a common theme here? Change management is actually forcing us to do the things that we IT professionals don’t like. And if we are forced to do something we don’t like, that something gets done. I remember comparing the runbook for all the different environments – UAT, staging, production, DR – for the systems I was responsible for. It wasn’t fun. My eyes hurt from reading a lot of text. I was still thinking that it was a total waste of my time. Until I was included in the team that performed regular disaster recovery exercises. I grabbed a copy of our DR documentation and simply followed the process outlined. I was surprised at how everything went well for somebody like me who was fairly new to the process. And all because we have a proper change management process in place. No wonder our team can afford performing regular DR exercises. I’ve been a believer ever since.
The Quality Of The Outcome Is In The Process
While I’m a big fan of automation, I always highlight the importance of having the right process. And if the goal is operational efficiency – be it in the IT team or the entire organization – having the right process is key. I strongly encourage that you evaluate your IT operations to see if you have a proper change management process in place. If you don’t have one yet, start by introducing small changes to have a change management process. If you already do, review how you can further improve your existing process. You’ll be surprised at the results that you’ll get once you start implementing it.
