Change Management is powerful and far-reaching, in that it supports every stage of the ITIL life cycle. 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.
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, processes, 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!
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 organizational structure have on people. OCM and Change Management work together because organizational structure influences the behavior of people and processes.
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.
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:
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:
Related: Ivanti Service Management Solutions
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:
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.
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.
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.
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.
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.
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:
Related: More IT Jargon Explained
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:
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.
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.
See a Demo: Ivanti Neurons for ITSM - Change Management
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.
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.
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 the implementation and coordination of training needs.
Upon completion of the change, a Post Implementation Review (PIR), which is a review of the detailed 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.
Related: The Essential Guide to ITIL
Change Management interfaces with other ITIL service management processes across the service lifecycle, including Problem and Configuration 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.
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.
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.
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.
Each change that occurs will be evaluated for its impact on security.
Helps ensure decision support for changes. This includes coordination and collaboration with other process areas for evolving data, information and knowledge for service-oriented decisions.
Users sometimes 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.
Portfolio Management will submit to Change Management Change Proposals for further processing.
Related: What is knowledge management?
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:
The individual or business unit requesting a change.
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.
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 a 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's effectiveness and its improvement the Manager is accountable for the execution of the process. If only one role exists, that role 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:
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 dedicated project management to coordinate implementation along with an IT Service Management solution in place to support your ITIL processes.
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.
Define the types and criteria for each type of change you will handle.
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.
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.
Identify the measurements that are important to your business stakeholders. Use these to demonstrate improvements and share these successes.
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.
This can be based on organizational governance and/or maturity of the change management process in the successful handling of the various change types.
Free Trial: Ivanti Neurons for ITSM
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:
*This content originally appeared on Cherwell.com, prior to the acquisition by Ivanti.
Maintain control over your IT infrastructure