An organization’s maturity can often be measured through their change management process. Most mature organizations have a strong change management process in place, and it goes unstated that many not-so-mature organizations tend to ignore change management until they hit a realization.
From my perspective, change management is the most important process in ITIL®. Not only is it used in the service industry, but change management and its principles is also adopted in the development world.
Change management is the chief controller for all infrastructure, applications and involved environment. Any changes to these will have to go through a process. It is a grim reminder that nothing can be done just-like-that.
A Brief Introduction to Change Management
Change management, as the name suggests, controls the changes in the service environment. Changes proposed, either to hardware or software, have to go through this process. In short, administrators are not allowed to make changes to servers and applications at will; their actions are governed by a process.
The process simply says that the proposal to make a change in the infrastructure or an application must be put forth before an expert committee, called the change advisory board (CAB), who holds the authority to either approve or reject the change. The expert committee consists of representatives from all domains who hold a stake in the service like security, server team, client, government representative, and of course the change manager who heads the process and acts like a judge in a trial court.
To explain the concept further, I am going to provide an example scenario where a server team identifies a flaw in a certain configuration, and proposes a fix, which involves upgrading the operating system. As I stated earlier, they cannot go ahead and upgrade the OS whenever they feel like it.
The server team puts forward a plan to upgrade the OS. The plan contains analysis to check current infrastructure compatibility with the new OS. The team identifies possible risks and challenges that they could encounter when going through the upgrade. For every risk, the team would draw up a mitigation plan. One of the common steps to take if a change doesn’t go according to plan is to roll back the change. This step is called as the backout plan. The upgrade is sometimes tested in a test environment if available and results are included in the plan as well.
The proposal to upgrade the OS is put forth before the CAB who study the analysis, and the risks involved. The security manager provides the analysis from a security perspective and gives his consent. A client representative looks at it from a financial perspective; whether the OS is a good return on investment and whether the proposed downtime to do the upgrade suits the business. So, in essence, every member on the CAB will have a say on the change.
When the CAB gives the OK, the server team plans and executes the OS upgrade during the downtime provided.
The whole idea behind this process is to ensure that all angles are looked at before any change is done to the infrastructure or applications.
Importance of Change Management to Organizations
If an organization wants to have control over its infrastructure and applications, having strong change management in place should do the trick.
Suppose you return from work and find that the TV has moved to a new position and a number of other items have been moved around. Maybe some of the movements made are noted down somewhere for your reference, but the important thing is that everything that has been done has been done without your consent. How would you feel? Forget the feeling; do you think you are in control of your own house? This is the exact position of an organization that is not supported by a strong change management process.
Disruptions just don’t happen out of the blue. They have to be caused by someone or something. It is a fact that most incidents occur due to failed changes. Why do changes fail? Before I touch upon changes failing, why do we need to make changes at all?
You might have heard this quote: Change is the only constant. This is a quote by Greek philosopher, Heraclitus, and he was referring to changes in life. But, it stands true for services as well. No service can claim the status quo by putting a stop to all changes; it just doesn’t happen like that.
Let’s Consider a Server
OS is loaded and applications are running just fine. Just when you think that things are stable, an OS update shows up telling you about a bug that has been fixed or maybe a security patch for a new virus in town. For those who work on servers, this is run of the mill. So, changes are necessary to keep the services running, and this takes place in every technology, be it servers, databases or application. Such changes have to be done without question. Change is inevitable!
It is possible that things could go wrong, albeit precautions are in place. This causes disruptions to services. which are nothing but incidents in ITIL®. A good change management in place can never completely eliminate incidents but could reduce it by a good extent. Change management simply works because we are doing a 360-degree review in terms of service, and all stakeholders are involved to ensure that their expertise is put to good use.
How Change Management Affects Finances
Nobody likes disruptions, especially customers. Service disruptions bring down the business activity. Business means money, and disruptions translate to loss of business.
When I was working as a service manager for a major insurance company, I was made privy to information on the losses the company incurred because of downtime on their web applications. The figures were in the thousands for every minute lost, and it gave me a whole new perspective on why the business would fall under my responsibilities every time an application went down. I performed an analysis to figure out where the incidents were originating from, and I was not surprised to find that the majority were a result of changes not going as planned. I involved some people, including the change manager and the issue was sorted out within a couple of months. This did reduce the number of incidents by a great deal.
I attended a session on ITIL® implementation sometime back. I had some years of ITIL® implementation experience at this point in time. I caught up with the trainer during one of the breaks, and asked a question that was lingering in my mind since the training began. I wanted to know which ITIL® process to implement first if I was going for a fresh implementation. Change management, he said. I didn’t ask further, nor did he bother to give me clarifications. It took me a few more years to understand why change management was implemented ahead of all other processes – especially incident management.
It is indeed true that many organizations go for change management first, as it directly impacts their financial turnover. It is a process that is considered to be top-of-the-league, and the people in charge of change management (generally) have at least 10 years of ITIL® experience before they are appointed to this position.
ITIL® is a Registered Trade Mark of the Cabinet Office.