Every IT landscape must change over time. Old technologies need to be replaced, while existing solutions require upgrades to address more demanding regulations. Finally, IT needs to roll out new solutions to meet business demands. As the Digital Age transforms many industries, the rate of change is ever-increasing and difficult for IT to manage if ill prepared.
The Information Technology Infrastructure Library (ITIL) provides a set of best practices for change management that makes it easier for IT professionals to roll out and prioritize changes efficiently, without negatively impacting customers or agreed-upon service levels. To stay competitive and avoid the stress of implementing changes without direction, it’s important to understand these guidelines.
Note that ITIL is not very prescriptive when it comes to how to implement IT processes. Many companies augment ITIL best practices with their own policies and processes, which reflect their own interpretation of the ITIL framework. This is specifically true for the IT change management process. Some of these policies and process may be borrowed from other best practice frameworks or regulations.
What is ITIL change management?
ITIL change management is a process designed to understand and minimize risks while making IT changes. Businesses have two main expectations of the services provided by IT:
- The services should be stable, reliable, and predictable.
- The services should be able to change rapidly to meet evolving business requirements.
These expectations are in conflict. The objective of change management is to enable IT service management to meet both expectations—to enable rapid change while minimizing the possibility of disruption to services.
Although change management is a process in the Service Transition phase of the lifecycle, the decision about whether to approve a proposed change is sometimes a strategic one, and therefore it is expected that the change management process will work closely with the portfolio management process as necessary.
Change management applies a formal process to accomplish change and therefore is sometimes thought of as making change more difficult by adding “red tape.” But a properly implemented change management process can enable a greater volume of useful change than would be possible without it. It does so in the following ways:
- By assuring that all proposed changes are evaluated for their benefits and risks, and that all impacts are considered.
- By prioritizing changes so that limited resources are allocated to those changes that produce the greatest benefit based on the business need.
- By requiring that all changes are thoroughly tested and that each deployment includes a back-out plan to restore the state of the environment in the event that the deployment fails.
- By ensuring that the configuration management system is updated to reflect the effect of any changes.
The change manager must always be aware of opportunities to make the change management process more efficient. There are two important tools for accomplishing this:
- Change models. It is extremely rare that a proposed change is not similar to changes made in the past. The change manager can develop a change model to standardize the procedure for implementing a specific type of change. This streamlines the process and reduces the risk of change.
- Standard changes. A standard change is a special case of a change model and applies to routine changes involving little risk. Standard changes are pre-approved, meaning that they do not have to be reviewed by change management and are typically treated as service requests by the service desk.
In deciding whether to authorize changes, the change manager is assisted by the change advisory board (CAB), which comprises experts in IT technology, finance, and the business.
ITIL change management overview
ITIL defines the best practices that IT organizations use to deliver value to customers via the concept of “services.” Companies and individual IT professionals who use ITIL are able to standardize the way they plan, deliver, and support IT services to their internal or external customers. One of the benefits of using a standardized best-practice framework is in ensuring that employees understand their roles and the procedures that they must follow to deliver services and provide a high level of customer support. Employee knowledge and performance tend to improve with the use of ITIL, and customer satisfaction is higher when customers know what to expect from service.
The ITIL framework is also intended to give IT support providers a more interactive role in businesses. Instead of providing support in the background, IT departments that utilize this framework are part of the businesses’ overall structure.
IT change management mission
The mission of the IT change management process is to implement changes in the most efficient manner, while minimizing the negative impact on customers when changes are implemented.
Key performance indicators (KPIs) for tracking the success of the IT change management process are:
- Successful changes: The number of changes that have been completed successfully compared to the total number of completed changes. The higher the percentage of successful changes, the better.
- Backlog of changes: The number of changes that are not yet completed. While this absolute number depends on the size of the organization, it should not grow over time.
- Emergency changes: The number of completed “emergency” changes. This absolute number depends on the size of the organization and should not increase over time.
Change management scope
The scope of the IT change management process is limited to change implementations that will cause:
- A service to become unavailable or degraded during service hours
- The functionality of a service to become different
- The CMDB to require an update
Other IT changes don’t usually require formal change management. Instead, they can be tracked as standard IT activities.
IT change management procedures
The IT change management process typically consists of different procedures:
Request for change review: Change coordinators use this procedure when they are dealing with requests for change.
- Change planning: Change coordinators and specialists employ this process to prepare the implementation plans for changes.
- Change approval: The change manager and approvers (e.g., customer representatives and service owners) follow this procedure to approve planned changes.
- Change implementation: Specialists use this process to implement infrastructure changes.
- Change closure: Specialists follow this procedure when they perform production tests after changes have been implemented, and change coordinators employ it when they close out changes.
These procedures vary slightly for different types of IT changes and risk levels.
Wherever possible, IT organizations should standardize and automate the way that they process requests.
Types of IT changes
There are different types of change requests, or change classes, that are typically managed in different ways:
- Standard changes are changes to a service or to the IT infrastructure where the implementation process and the risks are known upfront. These changes are managed according to policies that are the IT organization already has in place. Since these changes are subject to established policies and procedures, they are the easiest to prioritize and implement, and often don’t require approval from a risk management perspective.
- Normal changes are those that must go through the change process before being approved and implemented. If they are determined to be high-risk, a change advisory board must decide whether they will be implemented.
- Emergency changes arise when an unexpected error or threat occurs, such as when a flaw in the infrastructure related to services needs to be addressed immediately. A security threat is another example of an emergency situation that requires changes to be made immediately.
Latent changes, expedited changes, and no-impact changes are classes that BMC Remedy® ITSM software handles, though they are typically not listed in ITIL documentation.
Change management roles
Before you begin utilizing ITIL procedures, you will need to assign the following roles to your team:
- The change initiator recognizes and identifies the need for change. Your change initiator should be someone who works directly with support services tools. Members of your team who provide support services to customers may be best suited for this position due to their frequent interaction with the system.
- The change coordinator assesses requests for change that originate from incident management, problem management, release management, or continuity management. The change coordinator registers changes as needed to handle requests for change or receives change requests from other change initiators; determines the risk and impact for requested changes; prepares implementation plans by creating tasks; and monitors the progress of changes.
- The change manager is generally needed in mid-sized and larger organizations. If your IT department is part of a larger company, you will need to pick one or multiple persons to perform the role of change manager. These individuals are responsible for managing change procedures, receiving and prioritizing change requests, evaluating the risk level associated with requests, and keeping thorough records of the outcome of each change.
- The change advisory board is responsible for authorizing changes and further evaluating requests when the change manager determines that there is a high risk associated with these requests. The board takes into account the impact that a requested change may have on all affected parties. When these high-risk changes are brought to the attention of the change advisory board, the board will schedule a meeting with a detailed agenda to determine how to proceed.
- The approver decides whether to approve or reject changes.
- The change implementation team consists of the specialists on your team who are responsible for actually making changes. You will likely be part of this team and employees directly under you may also be assigned to implement changes. As an IT manager, you will often be responsible for overseeing changes.
ITIL change management process
This section reviews the various procedures that are part of the ITIL change management process. Once you understand the course, you will be able to proceed through the process without having to stop to determine what comes next.
Creating a Request for Change
If you are creating a request for change, you are responsible for documenting details that will help others understand what change needs to be implemented and why you are making the request. The initial change request submission often includes details about the risk and implementation steps, if the initiator already knows this information. However, this is not required information at this time.
Details that may be found in a change request include:
- Incidents that necessitate the change
- Description of how the change would be implemented
- The impact that the change would have on all associated systems
- A risk assessment
- Contact information for everyone involved in the change
- An outline of who will need to approve the request
- A backup plan to follow in case the change is not successful
Reviewing and Assessing a Request for Change
If you are responsible for reviewing a request for change, you will need to evaluate the request based on its practicality and priority. Your job is to determine whether the request is reasonable and to give feedback related to the request. If requests relate to problems that have already been addressed or are not practical to implement, they will be set aside.
Practical requests will be evaluated according to the originator of the request, the impact that making a change would have on the company, the estimated return on any investment made in relation to the request, and the resources that are needed to fulfill the request. You will also determine who would be responsible for fulfilling the request, and the implementers’ ability to dedicate time to making the change.
Planning the Change
Once a change request is made, you will need to plan the change as if it is going to occur. A change plan outlines the course that the change will take, the resources that are needed to complete the change, and a timeline for implementation.
Testing the Change
If a change relates to debugging software or otherwise changing a system, you may need to test the change before it is approved. A small-scale test will demonstrate the procedure to be followed in case the change request is approved. Testing the change also gives you the opportunity to work out any problems in the procedures that you have developed.
Creating a Change Proposal
A change proposal outlines the type of change, the priority associated with a change request, and the outcomes that could occur if the change is not made. Your proposal will be given to the person empowered to authorize the change, so it is important that you provides a thorough explanation of why a change needs to be made. For example, a change with a high-priority level may result in outages that will affect customers and result in revenue losses. The people who authorize changes must be aware of the severity of the impact if you do nothing.
Implementing Changes
Implementing a change is not a simple process. The change has to be built during the planning process, and implementation is just one step in the change management process. Once the change has been made, tests must be done to determine whether the desired results have been achieved. If the change is not successful, remediation methods may be used to determine what went wrong and to implement a backup plan to alleviate the issues that necessitated the change request.
Reviewing Change Performance
The post-implementation review is an essential part of the change management process. As an IT professional, you want to understand whether your change procedures are working as expected. This includes reviewing records to determine whether the change was successful or failed, and recording details about the time and expense of the change to determine the accuracy of estimates that were made before a request was fulfilled. Reviewing change performance gives you the opportunity to fine-tune your change management process for better results in the future.
Closing the Process
Once the change process is complete, you must be sure that the entire process has been documented in a database that all stakeholders can access. Once this documentation has been made, the process is closed out.