Change control is a very critical service management practice within ITIL. It is here that we can introduce improvements in services as well as other service management practices. A change is defined as the addition, modification, or removal of anything that could have a direct or indirect effect on services. This would typically include changes to IT infrastructure, applications, documentation, processes, supplier relationships, and any other critical components of the service. Although some IT organizations limit their focus only to hardware and software change control, it is important to remember that there are other elements play a significant role in service development and delivery, and changes to them can negatively impact customers.

The purpose of the change control practice is to maximize the number of successful IT changes by ensuring that risks have been properly assessed, authorizing changes to proceed, and managing the change schedule

It is important to distinguish change control from organizational change management. While organizational change management manages the people aspects of changes to ensure that improvements and organizational transformation initiatives are implemented successfully, change control is usually focused on changes in products and services.

Change Types

In ITIL, we usually identify three types of change that are each managed in different ways i.e. standard, normal and emergency changes.

Standard Change
  • A low-risk, pre-authorized change that is well understood and fully documented, and can be implemented without needing additional authorization.
  • Is often initiated as a service request, but may also be an operational change.
  • Requires a full risk assessment and authorization only during creation, or modification due to business change or occurrence of an incident.
Normal Change
  • A change that needs to be scheduled, assessed, and authorized following a standard process.
  • Involves change models based on the type of change determine the roles for assessment and authorization i.e. low level changes require local (team or supervisor) authorization while high level changes may require board level authorization.
  • Initiation is triggered by the creation of a manual or automated change request.
Emergency Change
  • A change that must be implemented as soon as possible without strictly following the standard process e.g. to resolve an incident or implement a security patch.
  • The process for assessment and authorization is expedited to ensure quick implementation, so scheduling and documentation is not a priority.
  • The change authority may be separate from what is standard or normal practice, typically smaller in number but with greater capacity to expedite approval.

Change Authority

The change authority is defined as a person or group who authorizes a change. This can be a team, supervisor, manager, CEO, board, customer or regulator depending on the nature of the change as well as the organizational approach and culture. It is essential that the correct change authority is assigned to each type of change to ensure that change control is both efficient and effective. There is no point constituting a board to review every relatively low risk change that can be locally approved.

In high-velocity organizations, it is a common practice to decentralize change approval, making peer review a top predictor of high performance. For example, an agile product team would make decisions on which elements of the product backlog will be tackled in a sprint, while the agile product manager would make decisions on which customer requirements would be included into the product backlog. Organizations adopting DevOps practices might establish systemic approval based on the success of automated checks in the continuous integration/continuous deployment (CI/CD) pipeline.

Change Communication

Regardless of who the change authority is, they may need to communicate widely across the organization as well as to key stakeholders. It is important to prepare all persons involved and all persons affected in advance to prevent surprises. Good communication with the Service Desk, for example, may be important to ensure that high call volumes do not come as an unmanageable surprise following a change that went wrong. Marketing teams might wish to avoid planned campaign activity at a time when key systems are expected to be unavailable. Good communication is also particularly important where a large cross-section of persons with specialist knowledge are needed, for example when assessing the risk of a complex change.

The change schedule is used to help plan changes, assist in communication, avoid conflicts, and assign resources. It can also be used after changes have been deployed to provide information needed for incident management, problem management, and improvement planning. It is important to expose the change schedule to all key stakeholders involved in the changes, through communication channels which are likely to get the message to them in a timely manner.

Contribution of Change Control to the Service Value Chain

The change control practice is involved in all the activities of the service value chain as shown below:

Plan Changes to product and service portfolios, policies, and practices all require a certain level of control, and the change control practice is used to provide it.
Engage Customers and users may need to be consulted or informed about changes, depending on the nature of the change.
Design and Transition Many changes are initiated as a result of new or changed services. Change control activity is a major contributor to transition.
Obtain/Build Changes to components are subject to change control, whether they are built in house or obtained from suppliers.
Deliver and Support Changes may have an impact on delivery and support, and information about changes must be communicated to personnel who carry out this value chain activity. These people may also play a part in assessing and authorizing changes.
Improve Many improvements will require changes to be made, and these should be assessed and authorized in the same way as all other changes.

ITIL® is a registered trade mark of AXELOS Limited. IT Infrastructure Library® is a registered trade mark of AXELOS Limited.

ITIL® Best Practice Books

Each free “Best Practice Insights” booklet highlights important elements from the latest version of ITIL® so that you can quickly understand key changes and actionable concepts.
Download Now ›
Last updated: 05/23/2019

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

See an error or have a suggestion? Please let us know by emailing blogs@bmc.com.

About the author

Joseph Mathenge

Joseph Mathenge

Joseph is a global best practice trainer and consultant with over 14 years corporate experience. His passion is partnering with organizations around the world through training, development, adaptation, streamlining and benchmarking their strategic and operational policies and processes in line with best practice frameworks and international standards. His specialties are IT Service Management, Business Process Reengineering, Cyber Resilience and Project Management.

View all posts

About the author

Jon Hall

Jon Hall

Jon is a Lead Product Manager in the BMC Remedy ITSM Product Management team at BMC Software, focused particularly on the evolving toolset marketplace and innovative new solutions for service. He has 18 years of experience in ITSM.

View all posts

You may also like