The Essential Guide To ITIL Change Management

Anthony Orr

Anthony Orr, ITIL Author and Examiner

For more than thirty years, Anthony Orr has worked in various IT strategy, managerial, consulting, advisory, marketing, and technical positions. Anthony is author of the ITIL v3 2011 publications and the ITIL MALC exam book, as well as a Sr. Examiner for the ITIL v2, v3 and Cyber-Resilience certification examinations. He has published numerous podcasts, videos, booklets, white papers and articles, and he has recently published a white paper, Synergies between ITIL and DevOps, with AXELOS. Having lectured at universities around the world, Anthony is also a frequent speaker at industry events such as itSMF, HDI, and Pink Elephant.


When you think of ITIL, you may think of a rigid set of processes and procedures that define how your organization goes about delivering services to its internal customers. However, those who truly immerse themselves in ITIL understand the framework is anything but rigid; in fact, the ITIL life cycle is both dynamic and ever-changing. Change Management, perhaps most notably, is powerful and far-reaching, in that it supports every stage of the ITIL life cycle. When thinking about Change Management, it is important to recognize there are strategic, tactical, and operational changes that need to be defined and managed to support your organizational service goals. Herein lies the keys to success.

At its most fundamental level, Change Management is related to the organization’s understanding of risk. While Risk Management teaches us to accept risk, ignore risk, reduce risk, or exploit risk based on business strategy and our capabilities, Change Management is all about managing risk to your organization. In this guide, different types of changes are discussed. The key to effective change management is defining change types by risk tolerance, and the appropriate levels of validation required by the IT organization.

In my many years of ITIL experience, I have met only a few organizations that didn't struggle with Change Management. For many of companies, it was an issue of not truly understanding its definition. Very commonly, organizations implement just one or two aspects of the process and call it Change Management. For example, some companies doing only Change Approvals or Post Implementation Reviews call their process Change Management. Other organizations don’t have a solid grasp on the differences between Change Management and Release and Deployment--or don't have a genuine understanding of what Release and Deployment is. Generally speaking, this is a symptom of their levels of maturity with the process itself, and as they delve deeper into best practices, their Change Management processes begin to take shape and make a real impact.

As with all the ITIL processes, there are many challenges relating to Change Management. Leveraging educational opportunities, expert consulting, and best-of-breed technology can help improve the process and the service outcomes for the business, as well as improve initiatives with DevOps, Big Data, IOT, Cyber-Resilience, Digital Transformation, etc.

As you read through the content in this guide, keep in mind the value to the business of doing what is essential for your organization, and doing it right by leveraging people, process, technology, and suppliers to meet your objectives. Service excellence is a journey that never ends and must be practiced and honed continually. And don’t forget to celebrate your successes!

Anthony Orr: The Do's and Don'ts of Implementing IT Change Management

The Essential Guide to ITIL Change Management

In this brief video, ITIL Author and Examiner, Anthony Orr, shares best practices and common mistakes relating to implementing IT Change Management within the enterprise. 

The Change Management process is designed to help control the life cycle of strategic, tactical, and operational changes to IT services through standardized procedures. The goal of Change Management is to control risk and minimize disruption to associated IT services and business operations.

Note: Organizational Change Management (OCM) is sometimes confused with Change Management. However, OCM deals with the impact new processes and changes in organization structure have of people. OCM and Change Management work together because organizational structure influences behavior of people and process.

The Goal of Change Management

The goal of Change Management is to establish standard procedures for managing change requests in an agile and efficient manner in an effort to drastically minimize the risk and impact a change can have on business operations.

Benefits of Change Management

While no best practice, framework or methodology can assure 100% success, Change Management can help manage risk and safeguard the IT services you deliver and support against unnecessary errors. Maintaining reliable business systems is essential for the survival of any organization in today’s competitive market space. Adjustments to any element within the IT infrastructure can disrupt service value and negatively impact productivity. Structured and planned change helps to minimize the potential risk that comes with infrastructure changes. At the same time a well-structured and planned Change Management process comes with significant business benefits.

Some of the benefits that result from Change Management include:

  • Improved IT to business alignment
  • Decreased adverse impact on business operations
  • Improved visibility into IT change
  • Prioritized responsiveness to change
  • Adherence to government and other compliance regulations
  • Improved risk management
  • Reduced service disruptions and system downtime
  • Increased staff productivity
  • Faster change implementation

The Role of Change Management within Service Transition

Change Management is a critical process within the Service Transition publication, part of ITIL's Service Management best practice framework that includes guidance for building, deploying, and transitioning new or changed IT services into operation. Guidance is also given on how to retire services. The objective of Service Transition in the IT process lifecycle is to plan and manage changes to IT services, while minimizing risk and improving decision support to users and the business.

ITIL Service Transition processes include:

  • Change Management
  • Service Asset and Configuration Management
  • Release and Deployment Management
  • Knowledge Management
  • Service Validation and Testing
  • Change Evaluation
  • Transition Planning and Support
Icon Play Button

Learn how Cherwell tackles Change Management
Watch 6-Minute Demo

According to ITIL, a Change is "the addition, modification or removal of any authorized, planned, or supported service or service component that could have an effect on IT services." Most often, a change is an event that has been approved by the change authority, is evaluated and implemented while minimizing risk, adjusts the status of a configuration item (CI), and adds value to the business and its customers.

Changes can be brought about in two ways:

1) Change Request or Request for Change (RFC)

A change request is a formal proposal that can be submitted by a stakeholder in the organization or by a service user via the service desk, utilizing the request fulfillment process to alter a configuration item.

2) Change Proposal

A change proposal is a high-level description of a potential service introduction or significant change and includes the business case and implementation schedule. These proposals are normally created by the service portfolio management process in Service Strategy and are passed to the change management process.

**A service request that is normally handled by the service desk can be a change request. A service request can be a change request if the change affects an IT Service with an addition, modification, or retirement of components or configuration items of the IT service. Service requests are fulfilled using the service desk’s request fulfillment process and do involve the change management processes (and potentially the supplier management process). Many service requests are standard changes.

Types of Changes

1) Emergency Change/Urgent Change

An emergency change is one that must be assessed and implemented as quickly as possible to resolve a major incident. Emergency changes tend to be more disruptive and have a high failure rate, so they should be kept to a minimum. The exact definition of an emergency change should be defined in the change management policy.

2) Standard Change

A standard change is one that occurs frequently, is low risk and has a pre-established procedure with documented tasks for completion. Standard changes are subject to pre-approval in order to speed up the change management process. Change Models (a documented and repeatable plan for managing a specific type of change) that describe the process for handling recurring changes are often times created for standard changes. If the standard change type increases in risk to the organization, it may become a Normal Change.

3) Major Change

A change that may have significant financial implications and/or be high risk. Such a change requires an in depth change proposal with financial justification and appropriate levels of management approval. Each organization’s process for identifying and managing a major change will differ depending on the size and complexity of the business. A change in this instance may change from being operational to tactical, or tactical to strategic and require a different level of authority for the approval.

4) Normal Change

A normal change is one that is not standard and not emergency and typically requires an important change to a service or the IT infrastructure. A normal change is subject to the full change management review process, including review by the Change Advisory Board (CAB) and authorization/rejection.

Additional Change Requests may include:

  • Application Changes
  • Hardware Changes
  • Software Changes
  • Network Changes
  • Documentation Changes
  • Environmental Changes
Change Management Process Flow Diagram

Change Management Process Flow

ITIL provides a framework that is adaptable to meet individual organization’s service delivery and support requirements. Designing a standardized change management process that is sanctioned by management will aid in quickly, economically and effectively managing changes when they occur. The process can then be automated by service management support software. Change control is a subordinate element of the overall change management process designed to ensure changes are controlled, recorded, analyzed and approved.

A typical Change Management Process includes the following activities:

1) Create & Log the Request for Change (RFC)

A Request for Change is typically created by the individual, process or business unit requiring the change. Depending on the type of change, an RFC record will contain varying information necessary to make decisions for authorization and implementation of the change, including, identifying information, a description, configuration item incurring the change, a reason for the change, requestor’s contact information, type of change, timeframe, costs, back out plan and business justification.

2) Review Request for Change (RFC)

Each Request for Change should be reviewed and prioritized by the change authority for business practicality. These requests can be rejected and returned to the submitter or management as notification or in request of more detail. These unapproved changes should be monitored and closed as needed.

3) Evaluate the Change

Evaluating the change to assess the impact, risk and benefits to IT services is critical in order to avoid unnecessary disruption to business operations. For certain types of changes, such as major changes, a formal change evaluation takes place by the change evaluation process and is documented in a Change Evaluation Report. Impact assessment will consider the impact on the business, infrastructure, customer service, other services – both IT and non-IT services, implementation resources and currently scheduled changes in the change log. A Change Advisory Board (CAB) can also evaluate changes. The CAB can consist of various stakeholders such as the service owner, technical personnel, and/or financial personnel to help evaluate the need for the change.

4) Approve/Authorize the Change

Change requests commonly require authorization prior to implementation and each change requires authorization from the appropriate authority level depending on type of change (strategic, tactical, operational). This varies across organizations, but commonly depends on the size of the business, anticipated risk of the change, potential financial repercussions and the scope of the change.

5) Coordinate Implementation

Once authorized, a change request or the change record is handed over to the release and deployment process for coordination and collaboration with the appropriate technical and/or application management teams for building, testing and deploying the change. Each change should have remediation plans prepared in the case of an implementation failure. Once building and testing are complete, release and deployment should notify the change manager of the results and suggested implementation requirements. The Change Manager should schedule each CHANGE based on the suggested implementation requirements and the management of business risk. The Change Manager using a Forward Schedule of Changes (FSC) or Change Schedule will communicate to all stakeholders upcoming changes that may impact them. The FSC along with projected service outages (PSO), or expected deviations in service availability, will be taken into consideration when coordinating change implementation. Release and Deployment will be responsible for implementation and coordination of training needs.

6) Review and Close Change Request

Upon completion of the change, a Post Implementation Review (PIR), which is a review of the detail implementation results, should take place to confirm the change has successfully achieved its objectives. If successfully implemented, and the change was associated with fixing and error in service all associated problems and known errors should be closed. If not successful, the remediation plan should be activated appropriately.

A Change Management policy should also be defined to support the process. This policy might include, defining what an emergency change is; implied benefit of the process; encouraging a change and ITIL friendly business culture, establishing roles and responsibilities for various change management activities, restricting change management access to authorized staff, risk management and performance measurement.

Change Management interfaces with other ITIL service management processes across the service lifecycle, including Problem and Configuration Management.

1) Problem Management

In order to resolve problems, changes are often required to implement workarounds and to resolve known errors. Problem Management can submit a RFC to resolve an error in the IT infrastructure that is causing problems and incidents. Problem management can work using the normal, standard or emergency change process. In either case an RFC must be submitted.

2) Configuration and Asset Management

Change Management relies on configuration management information within the CMDB when assessing the impact of a change on the IT infrastructure. It is essential that Cis affected by the change are identified. Information associated with the impacted Configuration Item (CI) is also updated throughout the Change Management process.

3) Release and Deployment Management

Change Management manages the change and coordinates the build, test and implementation with the release and deployment process. These two processes are so integrated that they should look like one process because of the handoffs. This helps with serviced orientation and removing process silos or what is known as the “throw it over the fence” approach to implementation.

4) IT Service Continuity Management

In an effort to minimize and manage risks that can negatively impact the business, IT Service continuity ensures necessary IT services are resumed within their minimum agreed to service levels. There are numerous procedures associated with IT Service Continuity that require regular updates in order to maintain accuracy. These updates and changes are managed by the Change Management process.

5) Security Management

Each change that occurs will be evaluated for its impact on security.

6) Knowledge Management

Helps ensure decision support for changes. This include coordination and collaboration with other process areas for evolving data, information and knowledge for service oriented decisions.

7) Request Fulfillment

Users sometime request changes to IT services or to configuration items that need to be managed. Change management manages most of these changes as standard changes until or if the risk of the change necessitates the specific change to become managed as a normal change.

8) Portfolio Management

Portfolio Management will submit to Change Management Change Proposals for further processing.

Clearly defined roles and responsibilities lead to successful Change Management. Although each organization will determine their own requirements, the following roles are typically found in the Change Management team:

1) Change Requestor/Initiator

The individual or business unit requesting a change.

2) Change Advisory Board (CAB)

A group of business, financial and technical representatives who perform change assessments. The Change Manager/Authority is typically the head of the Change Advisory Board (CAB) and members may include customers, management, developers, consultants, technical staff and non-IT office staff. The group of representatives will vary depending on the type of change under consideration. Each CAB meeting is led by a CAB Agenda that prioritizes the change topics to be discussed. An Emergency Change Advisory Board (ECAB) may also be established to quickly assemble when emergency changes arise, this formation should be included in the policy. The CAB can also be used to improve the Change Management process itself.

3) Change Owner/Manager/Authority

The Change Manager or Change Authority is the owner of the Change Management process. This person reviews all change requests, rejects requests with insufficient information, leads CAB meetings, identifies relevant CAB members, creates and manages the Forward Schedule of Changes (FSC), acts as liaison in order to coordinate changes, reviews implemented changes, manages PIR, closes RFCs and delivers management reports. In some organizations there are Change Owners and Change Managers/Authority. The Owner is accountable for the process effectiveness and its improvement the Manager is accountable for the execution of the process. If only one role exist, that roles has all responsibilities.

Each ITIL process should be measured for success in reducing costs, increasing service value including availability and reliability. Identifying service consumerization trends, measuring the impact of changes and demonstrating a reduction in business disruptions due to change are important improvements that help link Change Management results to business goals.

Important Change Management KPIs and metrics for the Change Management process include:

  • Improvement in service marketability
  • Number of successful changes implemented
  • Reduction in the number of service disruptions
  • Reduction in unauthorized changes
  • Decrease in change request backlog
  • Incidents associated with changes
  • Average time to implement a change
  • Change success rate
  • Number of disruptions (Incidents, Problems) caused by failed changes
  • Frequency and Volume of change
  • Ratio of planned vs. unplanned changes

The rate of change has never been faster than it is today and implementing a quality change management process makes handling constant change much more manageable. Implementing any of the ITIL processes can be a formidable task and Change Management is not exempt – it is a considerable strategic project. Earning support from executive leadership and upper-management for change governance is critical in gaining the buy-in from the staff you expect to both implement and follow the framework. Change Management adoption has to be expressed in values for each stakeholder. It is also important to have a dedicated project management to coordinate implementation along with an IT Service Management solution in place to support your ITIL processes.

1) Build a business case

Change Management can be a difficult concept to grasp. Share the purpose and benefits of a well-structured change management process with all levels of the organization, gaining buy-in from organization leaders and working down the chain of command. Getting all stakeholders on board is fundamental to change management success.

2) Define a Change for your organization

Define the types and criteria for each type of change you will handle.

3) Define key roles and responsibilities

Clearly identify roles and responsibilities for all who are associated with the change management process, including the Change Manager, Change Advisory Board (CAB) members and executive sponsors.

4) Design your Change Management processes

Each type of change, identified above, will require a process that will aid in setting expectations for requestors and support staff. These processes can be implemented in your ITSM solution for automated management.

5) Define your key performance indicators (KPIs)

Identify the measurements that are important to your business stakeholders. Use these to demonstrate improvements and share these successes.

6) Implement continual service improvement

The change management process, people involved and technology used should be audited or reviewed for performance on a regular basis and improvements should be made to ensure operational efficiency.

7) Understand your risk tolerance levels

This can be based on organizational governance and/or maturity of the change management process in successful handling of the various change types.

For IT organizations evaluating Change Management software and/or IT service management suites that offer Change Management capabilities, the following features are important, if not critical, for effectively supporting key processes.

At a minimum, Change Management software should enable administrators to:

  • Configure change processes
  • Configure change categorization
  • Create, modify, resolve, and close change requests
  • Implement ITIL or other industry best practice frameworks
  • Document back-out procedures, installation, and turnover within an RFC
  • Link problems and incidents to a change request
  • Proactively notify stakeholders and change advisory board (CAB) when necessary
  • Use role-based creation, updating, and approvals
  • Support release and deployment management as part of the change process
  • Automate change creation when unauthorized changes are made to CIs
  • Create a forward schedule of change
  • Schedule recurring events, such as maintenance activities
  • Identify impacted Cis when making changes to a related CI
  • Create an RFC from an incident/problem record with automatic field population
  • Automatically notify appropriate person(s) when RFC is updated
  • Reschedule changes if conflicts exist
  • Configure automated approval workflow
  • Assign for multiple approvers
  • Set response timelines and automatically send reminders if necessary
  • Automatically progress requests through appropriate stages of authorization
  • Generate Change Management reports, KPIs, and dashboards
  • Integrate with Incident, Problem, Configuration, Release, and Service Level Management
  • View impacted CIs from within a change request
  • Access an automatic record of historical data in an audit log
  • Utilize flexible field configurations including, free text, drop down, date/time, attachments, screen captures
  • Generate unique record numbers associated with each change request

Popular ITIL Resources

Learn how Cherwell supports key ITIL processes

Learn how to simplify IT AND remain ITIL-compliant

Get expert help implementing Incident Management