ITIL Change Management: Implementation Basics

ITIL is a framework of best practices for IT service management. The aim of ITIL is to provide workflows that break down IT management responsibilities into sub-tasks, thus reducing the complexity of day-to-day operations and project management.

The definition of ITIL was first released in 2001. Since that time, the system has been through a number of revisions. The latest version is called ITIL 4 Edition and it was published on February 18, 2019.

ITIL is organized as a set of books. Each book covers a particular stage in the ITIL Lifecycle:

• Service Strategy
• Service Design
• Service Transition
• Service Operation
• Continual Service Improvement

Change Management is a “process” in the Service Transition stage.

The Change Management process

In ITIL, “stages” are broken up into “processes.” The purpose of Change Management is to organize the workflow of introducing new IT services, which might be alterations to, or the replacement of, existing services. The development and introduction of the new system should be performed in a non-disruptive manner. The sign off for the process comes after the new system is operational and has proven to meet requirements.

The key aims of the process are to:

• Reduce risk and impact of the new service
• Avoid disruption of existing operations
• Facilitate communications and approvals
• Plan effectively, using available resources where possible
• Confirm that the change has reduced the number incidents that it was designed to address

The trigger that starts the change management process arises from the Service Strategy stage or as a consequence of unsatisfactory results from the Continual Process Improvement stage. An external trigger for a change is a “change request”; a trigger that results from internal IT department assessments is a “change proposal.”

Change management is not concerned with the development of new software and services. If a new application is going to be developed in-house, this is guided by a project management standard. This gap in the change process is due to the fact that change management applies equally to the installation of bought software. Therefore, if software is to be developed in-house, this is treated as a black box process and the developed application is treated as if it had been bought. That is, development is external to the ITIL Change Management process.

Configuration items

In ITIL, a Configuration Item (CI) is an element of the IT infrastructure. This use of the word “configuration” can be confusing to system administrators. The term usually refers to the settings of a device, such as a switch or a router. Its use in ITIL is completely different. Therefore, seasoned IT technicians need to put that regular usage of the word out of their head when approaching any ITIL-related meeting.

Confusing matters even further, the ITIL parlance refers regularly to “configuration management.” In network administration, this term refers to the setting up of new devices and locking those settings so that they cannot be tampered with. There is a category of system management software that is called “configuration management tools.” Once again, the IT services operator has to forget the regular use of this term when working on an ITIL-guided project.

One of the important information stores in ITIL is called the “Configuration Management Database” (CMDB). This does not necessarily need to be an actual database. It can be maintained on paper. However, this is what an IT operation staff member would know as a device inventory and a software inventory. The ITIL CMDB is a list of all hardware and software assets.

The Change Management process is concerned with the replacement of or the creation of an asset in the CMDB. Therefore, when beginning a Change Management process, it is important to identify which CIs will be affected or created by the project.

Types of change

As well as categorizing changes by their source, there are a few more ways to identify different types of change. Identify a change as one of these definitions.

• Urgent change A quick resolution of a serious problem that has caused an interruption to normal IT services. Although Change Management is meant to avoid disruption to normal service, an urgent change may cause upheaval because the importance of resolving an identified problem quickly overrides all other considerations.
• Standard change The most frequently encountered type of change and the easiest type to manage. Most of the change management projects you will implement will be in this category. These changes can be implemented with internal processes, involving the Service Desk team.
• Normal change A larger task than a standard change; this category of change includes supervision and involvement by external actors, such as the requestors for the change who are working in another department of the company.
• Major change This is a very large undertaking that requires a major effort and will introduce a significantly different IT service. Major changes require a large financial investment and incur a risk to the company because failure would cause a large financial loss.

The number of people that need to be involved in an ITIL Change Management exercise varies depending on the type of change. Urgent changes and standard changes are the responsibility of the Service Desk team and the cost of implementing these changes is usually built into the Service Desk’s regular budget.

A normal change is a matter for negotiation between the requesting department and the Service Desk team. This can be seen as a commission that is governed by a contract. That agreement will specify the goals of the project and the requesting department will be in charge of judging whether those goals have been met before it “signs off” on the project.

A major change is a substantial change that is driven by corporate needs. Examples of such new requirements are the need to comply with existing or new industry standards or laws, a merger with another company requiring the two IT systems to unite, and a decision by the Board of Directors to launch a new product line or expand operations to new locations.

As major changes are likely to involve many business departments, there is no single customer within the business and the change may require input from experts drawn from outside the business, such as external auditors, legal advisors, marketing consultants, or pressure groups.

Because there are so many opinions that need to be involved in the definition of the goals of a major change and then the declaration that the change has been completed successfully, these types of changes require a Change Advisory Board (CAB).

​The Change Advisory Board

A senior member of the Service Desk team will be allocated to be a single point of contact for any change request raised outside of the IT department. In the case of normal changes, that staff member will liaison with the requestor of the change in order to negotiate the terms of the new project.

In the case of major changes, the requestor role is fulfilled by a panel, called a Change Advisory Board (CAB). The major project will be mandated by the Board of Directors and will be a vital chance for the success of the business. It will also require a large budget, which will need to be approved by the Board.

The importance and large cost of a major project mean that a member of the Board of Directors will be nominated to lead the CAB. A senior financial expert from the company will also be a CAB member. Other seats on the CAB will be filled by business specialists. Those seats do not always need to be filled by the same people because, as the project progresses, different experts will be needed to oversee the change.

The acceptance criteria for a major change are harder to define than any other type of change. The goals of the change might not be immediately quantifiable. They might be stated as “reduce costs by 20 percent over a five-year period.” In such an example, the full team would not be expected to be active until the long-term goal could be measured.

External resources are also commonly used as contributors to a CAB. So, an external auditor would be expected to be allocated to the team according to the goals of the change. For example, a cybersecurity expert and a data protection standards consultant would be expected to be added to the CAB for the implementation of a standard such as HIPAA or PCI-DSS.

In the case of a legally required change, external specialist consultant will be working on the implementation of the change. It is to be expected that the CAB experts would be drawn from a different consultancy to those hired to provide experts to the project itself. This avoids an external consultancy providing its own verification for a sign-off that would trigger the payment of fees.

​Change viability management

Major changes involve many more intermediate goals and progression to subsequent phases of a change might be contingent on the successful and proven achievement of those goals. In some cases, failure of an early stage of development could cause the change request to be canceled. Major changes involve a great deal of risk to the profitability and continuity of a business and the full scope of the hoped-for change can sometimes only become fully visible once a research phase of the change has been completed.

In many cases, it is better to scrap a change project rather than risk the financial viability of the business. If it becomes apparent that the desired change is not going to be financially feasible, its failure might lead the company to withdraw from the area of business where new legal requirements formed the trigger for the requested major change.

Despite the ability of ITIL to create a framework that sets out guidelines for change management, it doesn’t guarantee success. Part of the reason for applying ITIL is to minimize disruption and risk to the business’s regular operations. So, it follows that the priority of minimizing risk leads to ITIL sometimes compel the CAB to recommend dropping a change.

​Change Management responsibility

ITIL is a framework for IT Service Management (ITSM). The ITSM structure places all of the IT department staff that interface with other departments in the company in a section, known as the Service Desk. The Service Desk team includes Help Desk operators. The idea is that the Service Desk office provides a single point of contact for all IT needs within the business.

“A single point of contact” doesn’t mean one person or one platform. The difference between the Help Desk and Service Desk concepts is that Service Desk includes client-facing analysts that accept requests for change, help define the requirements, and liaison with the requestor until the change has been completed. These people are like ambassadors for the IT department and they are collectively known as the Change Authority.

No matter which type of change is needed, the Service Desk team is in charge of getting the project done.

The stages of Change Management

With any large task, it is easier to progress in a measurable manner if the big task is broken up into smaller stages. By this method, you create achievable short-term goals and the task becomes less daunting.

Change Management is broken down into a process flow, which is made up of four steps. These are:

1. Request for Change
2. Change Evaluation and Planning
3. Change Approvals
4. Change Implementation and Review

The Change Management tasks arise from each of these stages.

​Request for Change

A request for change is either a change request that arrives from other departments or a change proposal, which is a system improvement identified by the Service Desk team. A change request can come from anywhere in the business at any time. A change proposal arises when Help Desk technicians identify a problem that occurs again and again. Usually, a change request is for a new service and a change proposal is an improvement to an existing service.

However, the change request arises, there are a few preliminary tasks that need to be completed.

• Log the request for change
• Assign RFCs to analysts
• The analyst defines the requested change
• The analyst and requestor prepare an outline

The result of the Request for Change task is an ongoing list of potential change demands. Not every request on the list will be implemented.

​Change Evaluation and Planning

The Change Evaluation and Planning phase looks into each request and expands its outline. Not every Request for Change makes it to this phase. The first part of the Change Evaluation step involves judging each stored request for viability. Some requests will need further clarification and so get sent back to requestors for revision – a task that can be supported by an assigned analyst.

Whether impractical requests get removed from the change candidate list, sent for clarification, or just get left to gather dust is up to the expectation management policy of the Change Authority.

Urgent changes get fast-tracked through the evaluation process. By their definition, these changes have been proposed by the Service Desk team and so, implicitly, they have already been evaluated for desirability during the proposal formation, which may be very quick. A standard change is also quicker to implement than normal or major changes because they are formulated from within the Service Desk team or the IT Department and don’t require consultation with other departments.

The result of the Evaluation phase is the Change Evaluation Report. This goes into greater detail about the requested change and assesses its impact on the business, the IT system, the quality of service that the business delivers to its customers, and the improvements that it will create in staff productivity.

The risks involved in implementing the proposed change will also be explained in the Change Evaluation Report. If the development and installation of the new CI would cause disruption to existing systems, services, or working practices, these should be noted. A ballpark figure on the costs of the change and the number of resources that would be needed for the project should also be outlined.

The Change Evaluation Report should explain the viability of the proposal. It should also state the type of change and a likely set of goals to measure completion. The Change Evaluation Report presents a more clearly defined scope of the proposed change. Essentially, this is a quote to be proposed by the Change Authority to the requestor, or, in the case of major changes, to the head of the CAB.

​Change Approvals

The Change Approvals phase can take some time. This formulates the contract between the requestors and the Change Authority. Once the proposals presented in the Change Evaluation Report are accepted, the requestor will be on the hook for funding the change. Therefore, the speed of this phase depends on the type of change.

Urgent changes and standard changes are usually funded out of the standing IT budget. These change proposals are usually monitored by the management of the Service Desk and the IT Department during their formation and are usually relatively small changes, so cost approval can occur very quickly.

Major changes are also often quickly approved. This is because the driver of these changes is often unavoidable, such as a new legal requirement. Another reason why major changes move relatively quickly is that these requests are handed down from the Board of Directors, and so originate from the highest approval authority. Major changes are usually staged, with the initial phase being a feasibility study. So, initial approval doesn’t have major financial consequences because important decisions on whether to proceed can be deferred to the Implementation phase.

​Change Implementation and Review

The Implementation step requires the appointment of a Change Manager from within the Service Desk’s Change Authority.

The Change Manager is a coordinator who then commissions others to plan out all of the resources needed to complete the change. The change could be implemented with a new software package, or it might require dedicated hours from an IT Department specialist technician. The actual development of the solution is out of scope for Change Management.

The Change Manager needs to put in place a remediation plan to rollback any innovations in case the change plan fails. The Change Manager also needs to firm up goals and acceptance conditions before the implementation project begins. These project boundaries, along with completion time frames should be handed over to the implementation project manager. At this point, the Change Manager becomes the representative of the requestor when dealing with the implementation team. The total package of project requirements laid out by the Change Manager is called the Forward Schedule of Changes.

The Change Manager supervises the installation and testing of the change, which should already have been tested by the implementation team. Once the Change Manager has confirmed that the solution conforms with the goals laid out in the approved request, the CAB or the requestor is called in to perform acceptance testing and sign off on the change. The final phase of acceptance testing could create feedback into redevelopment until the scope of the project is fully completed.

The Change Manager has to guide the expectation of the requestor in order to avoid the acceptance of the solution from dragging on into a continuous improvement scenario – this is out of scope for Change Management in ITIL.

​Succeeding with ITIL Change Management

The key to success when implementing ITIL Change Management is to recognize that it is a set of guidelines, it is not a law. Remember that this framework is there to help you and you will see flexibility in the strategy once you look into the system.

Be particularly aware of the different types of change and the varying procedures that need to be followed for each. You don’t need to call in a Director to set up a Change Advisory Board if you just need to set up a maintenance contract for printers. You don’t need to go through a rigid approvals process just to get the DBA to expand the database’s disc space allocation.

ITIL Change Management gives you a formula for breaking down large tasks and allocating responsibilities and documentation expectations for each type of change.

ITIL Change Management FAQs