Neven Zitek ITIL® Change Management is one of my favorite – and, in my opinion, most exciting – processes within the ITIL best practices framework, and an important part of IT Service Management. By definition, a service change is any addition (installation), modification or removal of anything that has an effect on IT services. The scope of change management includes all IT services, configuration items, processes, documentation, etc.
The main objective of Change Management is to ensure that changes are recorded, evaluated, authorized, prioritized, planned, tested, implemented, documented and reviewed in a controlled manner. And since Change Management covers all processes across the Service Lifecycle, that makes it an extremely important and very exciting process. Well-managed changes are very rewarding in terms of ease of planning, minimizing service disruption and/or rework caused by failed changes. You can read this blog post to find out more about Elements of Change Management in ITIL, before we continue.
Let’s take a local network as a service example, as it’s very much on the infrastructural level, and all other services heavily depend upon it. Any network change can have a great impact on end users, or delivery of other services such as e-mail, file share or internet access. In a non-ITIL-enabled organization, the network administrator (or team of network administrators) will have to keep their internal records about everything that is connected to the network, including all clients, servers, their own networking equipment, and any guests, or third-party equipment, such as internet providers.
In a best-case scenario, the network team will keep basic records about their own networking equipment: how many nodes are installed, model number, internal configurations and maybe software versions. There isn’t any information about internal correlation within network service(s) or other information services that are dependent upon the network itself. And if such is the way of doing things on an organizational level, it’s very hard (often impossible) to plan, test and implement any change in a way that will not disrupt current services one way or another. Things get worse when key people leave the company, or are absent for any other reason (e.g. vacation, sick leave, etc.).
Service Asset and Configuration Management
Before we are able to implement any form of Change Management, first we must be able to tell which assets are used right now, in order to provide the service. According to ITIL V3, assets include anything that could contribute to the delivery of a Service. Any resources, people, money, and equipment (hardware & software) are considered to be assets of an organization. So, Asset Management is the tracking and reporting of the complete inventory and the ownership (who is responsible for the control).
If a component has to be managed in order to deliver service, than we refer to it as a Configuration Item (CI). CIs are typically IT services, hardware, software, buildings, people, documentation and SLAs. Information about the CI is rerecorded in the Configuration Record within the Configuration Management System. Creating and maintaining information about CIs and their relationship is called Configuration Management, and those relationships are stored in the Configuration Management Database (CMDB).
Any type of software CI, or software version that is approved and deployed, must be stored in a Definitive Media Library (DML). A Definitive Media Library is a logical storage area with all approved software installations, along with documentation and licenses (if applicable). Only software from a DML is acceptable for use in release.
Understanding the change – understanding ITIL Change Management
Now let’s get back to our network example. Say our networking, and other IT professionals, have identified all assets and their ownerships, gathered all CIs and their relationships, and now have a clear picture about all services, their relationships and dependencies. Suddenly, one network switch has to be replaced…
In order to make effective use of newly gathered data, and ensure future consistency and usability, our network administrators have to be aware that no one is allowed to walk in and simply replace equipment (that’s why it’s strongly recommended for all IT personnel to acquire at least the ITIL Foundation certification level) . Every change has to start with a formal Request For Change (RFC), and be directed to the Change Manager. Every change has to answer the following questions: Who initiated the change? (one of the network admins); What is the reason for the change? (the switch is not supported by the vendor any more); Is there a remediation plan? (yes, we’ll keep the old one in if the new one doesn’t work); and How urgent is the change? (not really, as the current switch still works).
The Change Manager and the Change Advisory Board – CAB (consisting of both business and technical perspective members), will now address the risks involved (downtime for all services for all users on the switch while being replaced – maybe to replace it by night to minimize the impact), resources required (new switch, plus professional to replace it, will have to be paid extra if working during night time), who is responsible for building (purchasing), testing and implementing the change (network admins will create a test environment and test the switch before the installation), and what is the relationship between this change and other changes (network monitoring software is being upgraded, maybe to reschedule switch replacement after software upgrade). At the end, CAB decided to reschedule this Normal Change, as it costs money, brings some downtime, and interferes with other changes, while bringing no visible benefits at this time.
As displayed in the example, by implementing the ITIL V3 Change Management process, we are achieving the promised goal: ease of planning, and minimizing service disruption and rework caused by failed changes.
Changes happen – whether you plan them or not
Meanwhile, our switch in question has failed, leaving one whole department without a network! Consequently, all IT services are unavailable, making them unable to do their work! Now there’s no time for a Normal Change procedure; we need a fast resolution of the issue, and what we need is an Emergency Change procedure. This process requires the Emergency Change Advisory Board (ECAB, previously named Emergency Committee in ITIL V2) – composed of the Change Manager and senior staff, who are able to authorize change itself in any aspect (financial, technical, business, etc.). In general, emergency changes are to be avoided, as they are more disruptive and prone to failure due to lack of testing, but procedures should be prepared for such an event nonetheless.
Now that our ECAB has approved the suggested switch replacement, the new switch has been acquired and is ready to install. Before implementation, at least some degree of testing is strongly advised. Completely untested change can sometimes lead to even more damage. But, after brief testing, the new switch is implemented and service restored. Due to the emergency nature of the service disruption, it’s acceptable that the emergency request for change logging is done retroactively.
However, there is just one more type of change within ITIL V3 Change Management that I’d like to mention, and that’s Standard Change. Let’s keep to our network example, and say that a new computer has to be connected to that new switch we’ve installed. The change itself is low risk, relatively common, and follows a well-known procedure or workflow. Such changes are pre-approved and may be tracked by a different mechanism, such as a Service Request.
If you’re considering change management implementation, check out this list of Free tools for ITSM. There are several completely free change management tools listed.
