In ITSM, a change is defined as the addition, modification or removal of anything that could have an effect on IT services. Change management is the process responsible for managing and controlling the lifecycle of all changes. To do this, change management supports the assessment, prioritization, authorization and scheduling of changes. Change management is an enabling process, so beneficial changes can be made to systems and services, with minimum disruption to them. The scope of change management includes IT applications, networks, servers, desktops, laptops, tools, architectures, processes, organizational structures and operating instructions. Changes to any of these should be managed using a consistent change-management approach and must include:

  • Ensuring the change is recorded somewhere
  • Assessing the change for risk to existing services
  • Approving the change if needed
  • Checking the success or lack of success of the change
  • Reviewing the positives and negatives of the change-management process, so improvements can be made

The roles in change management

It is important to understand the different roles in change management. For some types of managed changes, the same person may be in these roles. Teams may also be in these roles, as all team members share the responsibility for the particular change-management task. The three main roles in change management are:

Change authority

The change authority is an important figure in change management. This is the person or persons who is responsible for granting approval for the change. In a good implementation of change management, this responsibility will vary depending on the type of change, the details of the change, the risk of the change failing, the impact of any failure and the system to which the change is being applied. There will be several different change authorities, which should be defined in a change management policy. Examples of change authorities are a change-advisory board (CAB), a change manager and an IT support technician. The concept of change authorities helps to share the responsibility for approving changes among more people than just the “change manager.” Using different change authorities will avoid delays in implementing changes and help to manage any overloads in the change-management process. 

Change owner

The change owner is the person who wants the change to happen. The change owner is accountable for the success of the change, even when someone else is managing the change or is responsible for its implementation. The change owner is responsible for requesting the change, often using a standard form known as a request-for-change (RFC). When the change owner is not also the change authority. as defined in the change-management policy, the change owner is responsible for presenting the RFC to the appropriate change authority for approval. This could involve representing the change at a CAB meeting. The change owner is often the product owner, with responsibility for that particular service, especially when the change being made and managed is to the service functionality or architecture. 

Change reviewer

Others, but not all, may need to review changes before they can be approved. The conditions under which changes require independent review will be defined in the change-management policy. Some changes are low risk and repeatable, but not all of them fall into this category. If a PC is plugged into a network socket, then that’s a change, but you wouldn’t expect the engineer to initiate a formal Request-For-Change and have someone else review it before the engineer completed this simple task. If a change was submitted with a considerable amount of new functionality, however, then it’s a good idea for the service-desk manager to review the change to ensure his or her staff is aware of the new functionality and when it will be deployed.

What are the different types of change in change management?

There are three different types of change in best-practice change management: emergency changes, standard changes and normal changes. It is important to understand their differences.

Emergency change

An emergency change requires urgent approval that cannot wait for the normal cycle of the change-management process. An emergency change, therefore, is a change that must be managed and applied to resolve or prevent a high-severity incident, where the fix is urgent and the impact to the business of not applying the change is very large. In good change management, changes must not be defined as emergencies just because someone forgot to submit the change to change management for approval within the agreed time period. It is normal practice to have a separate variant of the change-management process to manage emergency changes. Emergency change-management processes typically have specific requirements for approvals and recording the change that supports the urgent management of the change. The change authority for managing emergency changes is often the major incident manager, who may agree all of the change-management paperwork can be completed after implementation of the emergency change.

Standard change

A standard change is both low risk and repeatable. It has been successfully managed and executed many times. Examples include managing the connection of a PC to a network, applying routine malware updates and minor software patches. There should be a variant of the change-management process that defines how standard changes are treated. The change-management policy should include the definition of what is a standard change for a particular organization and how the changes are to be managed. The manager responsible for change management should maintain a complete list of the agreed-upon standard changes. The management activities for the execution of every standard change should be recorded, but there is no requirement to initiate an RFC for them in the change-management process. In the management of standard changes, the change owner is often also the change authority, meaning the change can be executed without additional approvals from others in the change-management process. The use of standard changes is a good method to stop the change manager and the CAB being overloaded with many low-risk changes. 

Normal change

A normal change requires management but is not a standard or an emergency change. There should be a particular variant of the change-management process to manage normal changes. An organization will typically create a normal change as its first change-management process, which is then used as the basis to create the management processes for emergency changes and standard changes. In a normal change-management process, the change owner submits an RFC to the team responsible for change management a minimum number of days before a planned implementation date. This allows the person or team responsible for change management sufficient time for an initial assessment of the change, and then, if necessary, distributed to stakeholders and ITSM specialists for review. The change and the review comments are then presented to the change authority for approval. This could be at a meeting of a CAB or the change manager might approve it. The change-management policy should define the change authorities for normal changes. Normal changes should be included on a schedule of changes showing all changes being managed. 

 

What are the principles of best-practice change management?

Change management is a process, but unless everyone is focused on its important principles, there is considerable risk change management will add overhead, but provide no value to an organization’s business outcomes.

Change management as an enabler

Without focusing on the principles of change management, it can be perceived as an obstacle to making desired changes. Change management must be able to process changes at the pace the business requires. To assist in maintaining this pace, change-management practitioners should be proactively engaged in the development lifecycle, offering advice and guidance to ensure the change can progress through the change management process without any delays. Proactive engagement will also help the people involved in the change management process to understand the contents of a change, avoiding unnecessary questions at any approval stage, which can delay the deployment of changes.

Change management delivers success for users

Following this principle will help to ensure the change-management process adds value to an organization and does not become just a “box-ticking” exercise. Change management is not an agreement of the change requirements with users, or building, testing or deploying the change. These are the responsibility of the related release-management process, not change management. Good change management, however, can help to ensure changes work as intended by checking those responsible for each phase have approved their part. This should include confirmation of the testing of the change and its deployment method, the completion of any necessary training and the change owner is satisfied the change is ready to be deployed.

No blame culture, with collective responsibility

In best-practice change management, no one should be blamed if a change fails. Change management should ensure a failed change is investigated, so lessons can be learned in advance of the next change, but without assigning blame. The individual or team responsible for change management should have good working relationships with the many people and teams who are part of the lifecycle of a change, from inception to actual use. Everyone involved in the end-to-end workflow of managing the change must act as if he or she is a member of the same team with the same goal. To avoid blame in change management, all those involved in the lifecycle of a change should take collective responsibility to ensure the change works, and with a shared goal to satisfy the customer.

Large proportion of standard changes approved without a CAB

Achieving a large proportion of standard changes compared to the total number of changes is a change-management goal. These standard changes will be recorded, approved and executed without any involvement from a CAB. Achieving this principle is a good indicator of mature change management, as it demonstrates trust between IT and ITSM, and a culture that focuses on the purpose of change management and not just following a change-management process.

What are the activities of a change-management process?

Change management includes a number of activities and sub-processes. It is important these are considered for every type of change. Noting the detail and execution effort for each of these change-management activities will vary according to the type of change and its characteristics. For example, for a standard change, the change-management activities for RFC creation, review, change evaluation, assessment, approval and closure are all completed at the same time, often by the change owner.

Create and record RFC

The change owner creates an RFC and records it in the location defined in the change-management policy. An RFC provides the information required to manage the change, including a description, required date and the name of the change owner. The change-management policy may require additional information for normal and emergency changes, including assessments of risk and impact and back-out plans.

Review RFC

Some change-management policies require an initial assessment of an RFC for a normal change to verify all required information has been provided. If any information is missing, then an RFC can be rejected and returned to the change owner.

Assess change

Depending on the outcome of the evaluation, an RFC may need to be circulated to the reviewers identified in the change-management policy, so they can conduct their assessment of the change. When the change manager is the change authority, as defined in the change management policy, then he or she can conduct the assessment.

Approve change

The change authority defined in the change-management policy will either approve or reject the change after considering the outcomes of any assessments, any clashes with other changes and the information presented in an RFC. The approval or rejection should always be recorded in the location, according to the change-management policy.

Review and close RFC

Many RFCs are closed as soon as a change has been implemented. If a change fails, then before an RFC can be closed, a review should be conducted to identify any required improvements. This can include recommending amendments to the change-management process or the change-management policy.

 

Who should approve changes in best-practice change management?

In best-practice change management, there will be a number of change authorities who are authorized to approve certain types and classes of change. The approvers should be defined in the change-management policy and can include the change owner, the person executing the change, local management, the change manager, the CAB and the executive board of the organization. For standard changes, the change-management policy normally defines the change authority as the change owner or the person executing the change. For emergency changes, the approver is usually the major-incident manager who is responsible for the incident requiring the change. Local management often approves changes where the scope of the change is limited to just one part of IT, with no risk of affecting users. This approach can be usefully employed in DevOps environments, where the product owner or the scrum master acts as the change authority, in effect, acting as a change manager. The CAB should be involved in change-management approvals only if a change has a large impact or high risk; requires a service outage; or is complex, requiring the involvement of multiple teams. Final approval may be required from an organization’s executive board for very high-risk and very large-impact changes that could significantly and adversely impact the day-to-day business of the organization.

Common mistakes in change management and how to avoid them

Organizations that focus on the mechanics of change management, but ignore its principles and intended outcomes, are likely to make mistakes. These mistakes can be avoided through intelligent design and application of change management.

Change management delays the implementation of new developments

Unless the change-management process is designed in conjunction with the development function, focusing on avoiding delays and bottlenecks, the change-management process will delay the implementation of new developments customers want. Your design for change management has to give control but not at the expense of speed. Conducting weekly CAB meetings and using it as the change authority for the majority of changes is one common reason for this mistake. The CAB becomes a bottleneck, which causes delay. This mistake can be avoided by defining multiple change authorities in the change-management policy, reserving the CAB only for high-risk and large-impact changes, and holding CAB meetings at short notice when required. Your design for change management has to give control but not at the expense of speed.

Bureaucracy, paperwork and lack of trust

In many organizations, change management is considered bureaucratic, requiring much paperwork. Focusing on just the change-management process and not its intended purpose will harm the business, ITSM and rest of IT. The change-management process must be designed from the perspective of the change owners, so they can easily and quickly request a change. Standard changes should be used for all low-risk, repeatable changes as these will ensure effective use of the change-management principles. The change authorities should be designed to minimize the number of needed changes for a CAB. Workflow technology should be used instead of emails and paperwork. Change-management processes must be kept as simple as possible. The CAB must be carefully designed and managed, so the change-management process is free of bureaucracy.

Bypassed authority

People and how they think and behave are the most important elements of successful change management. Twenty per cent of implementing best-practice change management should focus on introducing processes and technology, but 80% on changing the attitude, behavior and culture (ABC) of people in an organization. Introducing change management requires people in a company to be a part of an overall change-management system instead of approaching change management as a “maverick” activity. To address this mistake when implementing change management, establish and apply techniques to change the ABC in your organization.

Ignoring the human factors of change management

People and how they think and behave are the most important elements of successful change management. Twenty per cent of implementing best-practice change management should focus on introducing processes and technology, but 80% on changing the attitude, behavior and culture (ABC) of people in an organization. Introducing change management requires people in a company to be a part of an overall change-management system instead of approaching change management as a “maverick” activity. To address this mistake when implementing change management, establish and apply techniques to change the ABC in your organization.

Lack of continual improvement

A common mistake is to continue using the same change-management process and policy for many years without any review. Both should be reviewed regularly and after any failed change to ensure they are still appropriate and relevant. 

Improving the efficiency of the CAB in change management 

Without careful design, CABs can be one of the most inefficient parts of the change-management process, and for several reasons:

Technology can address these issues by deploying techniques to create a “virtual CAB,” improving the efficiency of the CAB and the overall change-management process. Workflow tools can automatically route RFCs on receipt to the appropriate reviewers. Collaboration tools, including social media and Web-conferencing platforms, can enable change discussions to occur before a CAB meeting. These tools can even be used to conduct the CAB, with no need for everyone to be in the same physical space. Technology enables virtual CAB meetings to be called on demand, including to manage emergency changes and support attendance by people in any location. 

Managing major changes

In a major change, a large number of configuration items must be introduced or changed at the same time, for example, a major application upgrade that needs a hardware expansion and significant user training or a change with a very high risk or very large impact to the users of the services. An example of the latter is when the implementation of the change requires management of an extended outage during working hours. The steps to approve a major change will be very similar to the usual change-management process, but a major change often requires more attention and approval from a higher level of an organization. A major change, therefore, must be considered much earlier in the change-management process, and more information is required than is requested in an RFC. A change proposal can be used for the initial stages of a major change. This change proposal is an early communication about the change, so the risk, impact and feasibility can be assessed before any significant investment is made.

How can you receive approval to implement change management?

The first step to obtaining approval to implement change management is to gather some data and evidence about the impact of not having an effective change management process. These can be obtained from users, IT and the service desk. Analyze all of the service outages and disruption during the last 2 or more years that occurred after a change had been made. If you can’t obtain any historical evidence, then start collecting it from today. Most organizations without change management will have experienced at least one high-impact failure following the release of a change. Once the evidence has been gathered, estimate a cost of the impact to the business and IT. This can be calculated according to the number of minutes lost and the average cost of a worker. Add the cost of the time IT spent recovering from the failures when it could have been working on improvement projects. Lost business may be another cost factor, for example, customers who visited other online systems. The costs of implementing change management can then be justified by contrasting them with the total loss incurred due to failed changes.

How can you best implement change management?

The first step to implementing change management is to understand fully how changes are currently managed, so you can keep what works well and make informed decisions on areas of priority. This is achieved by identifying a baseline and consulting with everyone involved in the lifecycle of managing changes. Once the baseline has been established, discuss the expected outcomes from implementing change management and reach an agreement with stakeholders of the business, IT, development. This will help senior management to maintain focus on why change management is being implemented within the organization. Once an agreement on outcomes has been reached, the activities to support the necessary changes in attitude, behavior and culture (ABC) should start and continue throughout and beyond the change-management implementation.
There are then two options to implement change management: a phased approach or “big bang.” The choice of option will depend on the baseline position for change management, the resources available for implementation, the rate of changes currently being managed and an organization’s appetite for risk. 

Phased approach

In this approach to implement change management, a small start is made and lessons are learned, and then the scope is expanded. The initial scope of change management can be according to service, for example, introducing the new change-management approach for all changes to a service; by the type of change, such as major changes first; or by IT function, such as application changes. A phased approach for change management can require more time to complete, but if you start with a small scope, then you can test your change-management approach and adjust easier. According to other companies’ experiences, a phased approach is usually more successful.

Big bang

During a “big-bang” approach, change management is implemented to all services, types of change and service providers. This entails higher risk and can require considerable effort to make it work during the early days. It is also more difficult to adjust your change-management approach if you must make improvements. This approach is more often used in small organizations or where it is imperative to use it, for example, for regulatory compliance to a deadline when there isn’t enough time for a phased approach.
Good change management starts with the first step. Organizations are advised to make a start, however small. A good approach is to start a phased approach by selecting an area where change management can make a visible and positive difference. It is highly likely some mistakes will be made, which is normal when introducing a process or policy as complex and all-encompassing as change management. It is important to learn from your mistakes and be prepared to adjust your change-management process, policies, training and education. 

Good change management starts with the first step. Organizations are advised to make a start, however small. A good approach is to start a phased approach by selecting an area where change management can make a visible and positive difference. It is highly likely some mistakes will be made, which is normal when introducing a process or policy as complex and all-encompassing as change management. It is important to learn from your mistakes and be prepared to adjust your change-management process, policies, training and education. 

Other IT Resources

BLOG

Top 10 Tips for ITSM Tool Selection
EBOOK

Fixing the disconnect between IT and Business with Self-Service
BLOG

4 Techniques for an effective Problem Management
BLOG

Managing SLA and Customer Expectation – Part I