ITSM Change Management Best Practices

The work to transform service designs into consumable services comes with inherent risks to existing services. IT Service Management (ITSM) Change Management is an approach that ensures that changes to services and their components are controlled and meet the organizational needs. The word “control” may sound restrictive, but that comes from a need to find a balance between enhancement and stability. The bad taste of a failed change that disrupts services takes a long time to get rid of. Just ask CrowdStrike, who recently executed a content configuration update that affected over 8 million Microsoft devices across airports, retailers, hospitals, and financial institutions globally.

Stakeholders demand different things when adding, modifying, or removing service components. Some want agility and throughput, while others focus on risk control and compliance. A one-size-fits-all approach doesn't work in modern environments, so organizations must find the right mix of change management practices to meet business goals. This article will explore five ITSM change management best practices that enhance change management in a digital environment.

Summary of ITSM Change Management Best Practices

The table below summarizes the five best practices for ITSM change management that this article will explore in detail. 

ITSM Change Management Best Practice #1: Define a Change Management Policy

A change management policy is an organizational governance tool that defines the rules of the change management practice. It is a strategic tool that provides direction in terms of the “what” and the “why” rather than the “how” of managing IT changes. The change management policy should be clear to all stakeholders and concisely define its objective, scope, and importance. The clarity and accountability of a well-written change management policy facilitates smooth approval processes, policy implementation, and risk management.

According to the ISO 20000 standard for service management, the key elements of a change policy are:

• Scope: Not all components of a service need to fall under change management, so the organization specifies what needs to go through the process. Areas that an organization may consider out of scope include documentation, cloud applications, test environments, and user devices.
• Categories: The categories of change provide clarity on the level of assessment and approval required before implementation. Examples of categories include:
• Standard changes: These are low-risk, pre-approved changes that can be managed as service requests or fully automated.
• Normal changes: These are changes of varying risk that require approval depending on assessment criteria.
• Project changes: These are managed differently as stand-alone service design and transition activities. They are treated as normal changes where they interact with existing service components.
• Emergency changes: These are changes that require expedited approval or post-approval due to the need to address an incident or security breach.
• Evaluation criteria: The policy outlines the criteria to determine what changes could have a major impact on services or customers. Many organizations use impact, urgency, and priority tables that specify the different scales and map them to approval levels. For instance, a change that has the highest priority may require approval from the head of IT as well as stakeholders in risk and information security functions.

Priority matrix based on Urgency and Impact (Source: USM)

A change management policy provides details of the requirements a change request should fulfill before being considered for approval. Typical content includes:

• A rationale for the change.
• A deployment plan that includes a rollback (or back-out) plan that covers the risk of failure or incidents.
• User acceptance testing (UAT) test results.
• Guardrails for handling IT change requests across the change lifecycle.

The approval levels should be specified to limit unnecessary bureaucracy while facilitating speed and compliance. The policy should also detail the consequences of noncompliance.

ITSM Change Management Best Practice #2: Streamline Change Review and Approval Processes

The change management process that the organization should come up with should not adopt a one-size-fits-all approach for change review and approval. The ITIL 4 framework defines a change authority as a person or group responsible for authorizing a change.

Ordinarily, a change request should be approved by the team that has the most knowledge of the nature of change and its impact on live services. Some organizations operate in large and complex environments, so they constitute a separate group termed the Change Advisory Board (CAB) that reviews changes that have multiple dependencies and have a risk of conflict with others. However, the CAB has been blamed as one of the bottlenecks to efficient change approval processing when it is a gate for all normal changes. In these cases, a CAB can introduce delays and limit change throughput. The evolution of ITIL from v3 to ITIL 4 modified the name of the change management process to the change enablement practice to try to address the issues caused by bureaucratic approval structures.

Organizations should define different change models that specify the requirements for authorization of different change categories based on risk, priority, resource, and cost considerations. The models should inform the delegation of the change authority to the appropriate level and guide where authorization may be required manually, automatically, or skipped altogether. For example, each service may require its changes to go through a service owner/stakeholder approval, while a head of enterprise risk might need to approve changes evaluated as having the highest risk level. Change models should be defined in the change management policy and ITSM change management tool workflow to direct change requests to the best-fit model. For example, a change that will result in major downtime affecting most users has significant compliance risk or does not have a straightforward rollback approach should have its model designed with higher authorization requirements.

As part of Continual Service Improvement initiatives, organizations should review change and approval processes regularly to ensure they do not become stale even as the business evolves. For example, a specific normal change that has been executed several times without issue may result in it being recategorized as a standard change and only requires review if the operational environment changes. Where agile and DevOps techniques have been adopted, organizations should transfer approval ownership to the product teams or platform teams closest to the change. The CAB should constantly question the rationale for bringing changes to it, and review criteria should be regularly assessed to ensure only complex or risky changes require the involvement of a cross-functional body for approval purposes.

ITSM Change Management Best Practice #3: Make Change Communication Clear and Visible

Communication is essential for effective ITSM change management. Many incidents resulting from a change could have been avoided if relevant stakeholders were given advance notice. Communication happens throughout the change lifecycle, as highlighted below.

Communication with stakeholders is also required during updates to change models and the change management policy. These stakeholders encompass a wide range of individuals and groups, including IT staff, leadership, and, importantly, the end users who are directly impacted by the changes.

Due to the importance of change communication, the organization should ensure the responsibility is assigned to either a change manager or a change coordinator. The communication channel to be used should be the most effective from the stakeholder point of view. There is no point in using email when the team’s preferred channel is Slack. Using multiple channels can help overcome the challenges of meeting fatigue, email overload, and notification noise.

Organizations should adopt modern and inclusive approaches to change communication, including social media, collaboration tools, and automated notifications. As a result, all stakeholders, regardless of their generation or culture, are actively involved in the change process, contributing to a smoother transition and a better overall experience.

The change communication flow

Configuration information is a critical input in change management. The components that host the IT Service, such as applications, databases, network interfaces, and hardware, are termed configuration items, and their interconnections and relationships play a key role in how a change is executed and the impact when things go wrong. When IT change requests are related to associated configuration items, this should inform the relevant IT asset owners to participate in change assessment, planning, and execution activities. This process can only occur when the configuration management module that maps the IT components and their relationships within the organization’s ITSM solution is configured correctly, and notifications are sent when dependent configuration items are mapped to a change request.

ITSM Change Management Best Practice #4: Measure and Report Change Management Performance

It is a good practice for the organization to track how the change management process activities are performing against expectations. Business stakeholders are more focused on the change outcomes than the process, so IT must ensure that change management metrics link to customer satisfaction and business objectives. Some of the practice success factors that organizations should look to measure change management metrics against include:

• Validate that changes are realized in a timely and effective manner - An example metric is processing times across the change lifecycle stages for different change models.
• Minimize the negative impact of changes - Example metrics include the frequency and impact of change-related incidents.
• Ensure stakeholder satisfaction - For business, satisfaction is measured from the perspective of the realization of changes leading to business outcomes being achieved. For internal IT teams, satisfaction stems from how the change assessment, approval, and communication activities were carried out.
• Meet change-related governance and compliance requirements - The metrics here relate to the change management process activities complying with the change management policy and other stakeholder requirements, such as those concerned with risk management, information security, and business continuity.

Another dimension of performance improvement is assessing the maturity of the change management practice against a well-known framework from a body of knowledge (e.g., ITIL 4 or COBIT) or a solution provider. Maturity indicates to the organization how the process activities measure up to expected criteria and inform areas that need improvement. For example, higher maturity criteria include managing and tracking information on anticipated and actual negative impacts of changes in an integrated management system. Organizations can adopt the SolarWinds ITSM Maturity Model framework, which is aligned to 5 key areas of ITSM, one of which is change management, as shown in the table below. Carrying out regular maturity assessments can enable the IT leadership to monitor the progress of improvements to change management capabilities across every dimension.

SolarWinds ITSM Maturity Model for Change Management (Source)

Change records and metrics should be analyzed to determine trends in changes such as problematic configuration items, first-time success rates, or change processing timelines associated with different change authorities. Metrics should be presented to internal stakeholders via on-demand dashboards designed with target audience preferences. Teams should use what they have learned from these analyses to improve change management processes continuously.

ITSM Change Management Best Practice #5: Automate the Key Facets of Change Execution

Technology can help organizations standardize and streamline change management tasks so that they are performed correctly and consistently with limited or no human intervention. The automation capabilities within ITSM solution change management modules can be exploited to support the following process activities:

• Formalization and structuring of change assessment, which provides more accurate data to inform change authorization.
• Progression of status on the change record based on notifications sent by configuration items during deployment.
• Publishing and reporting of change KPIs.

Change Management Automation (Source: SolarWinds ITSM platform)

Automation can also be useful in detecting conflicting change requests, especially in a complex environment with large volumes of changes. By configuring automated checks within the configuration item database, IT system administrators and change planners can be flagged whenever planned changes within the same period involve the same set of configuration items, which is a potential recipe for change-related incidents. This process allows them to investigate the conflict and make an informed decision on whether to reschedule or proceed with change execution.

Organizations can also use DevOps technologies to automate change testing and execution. By integrating their ITSM change management modules into orchestration tools, a change approval can trigger the automated integration, deployment, and testing of service components. Benefits of incorporating DevOps technologies include faster execution, standardization by using deployment templates, higher throughput of changes, higher quality, and reduced risk. For example, one complex change that would be executed manually in one step can be broken down into multiple minor risk changes that are implemented automatically.

Final Thoughts

Even as organizations evolve to hybrid environments that have both on-premise and cloud-based IT services and infrastructure, ITSM change management remains a critical practice that should be carefully controlled to deliver the right outcomes to businesses and customers. Finding the sweet spot between innovation and stability will remain a constant headache for organizations processing an ever-increasing volume of changes. The risks of changes going wrong due to suboptimal change processing or execution activities remain significant.

The right processes and tools can be a game changer in supporting IT to deliver value to the business through change management. By investing in the above good practices, the ITSM change management practices can become more adaptive and agile to benefit customers by processing and executing more changes quicker without raising the risk of negative impact.

← Back to ITSM Best Practices Guide