ITIL® Intermediate RCV Tutorial : Change Management

Welcome to lesson 2 of the ITIL Intermediate RCV tutorial, which is a part of ITIL Intermediate RCV Foundation Certification course. This lesson introduces the Change Management process and take a looks at how it contributes to RCV practices.

Let us discuss the objectives of this lesson.


By the end of this ‘Change Management’ lesson, you will be able to:

  • Understand the complete overview of the purpose, objectives, scope, and importance of change management as a process to generate business value.

  • Explain the Change management policies, principles, concepts, activities, methods, and techniques in relation to RCV practices, and especially in relation to types of change requests and how they flow through the process.

  • Review the efficient use of change management metrics, as well as how service operation and continual service improvement interacts with change management.

Let us begin with looking at the purpose and objective of change management in RCV practices.

Purpose and Objectives of Change Management

The purpose of the Change Management process is to ensure that:

  • Standardized methods and procedures are used for efficient and prompt handling of all changes.

  • All changes to service assets and configuration items are recorded in the Configuration Management System

  • The overall business risk is optimized.

The objective of the Change Management process is to ensure that changes are recorded and then evaluated, authorized, prioritized, planned, tested, implemented, documented and reviewed in a controlled manner.

In the next section, we will look at the scope of change management.

You too can join the high earners' club. Enroll in our ITIL Intermediate RCV Course here!

Scope of Change Management Process

The scope of Change Management covers changes to standardized service assets and configuration items across the whole service lifecycle.

Each organization should define the changes that lie outside the scope of their service change process. Typically these might include:

  • Changes with significantly wider impacts than service changes, e.g., departmental organization, policies and business operations – these changes would produce RFCs to generate consequential service changes

  • Changes at an operational level such as repair of printers or other routine service components.

We shall understand this better with the help of a figure in the next section.

Scope of Change Management: Strategic, Tactical, and Operational

The Figure below shows a typical scope of the service Change Management process for an IT department and how it interfaces with the business and suppliers at strategic, tactical and operational levels.
Scope of Change Management
It covers interfaces to internal and external service providers where there are shared assets and configuration items that need to be under Change Management.

Service Change Management must interface with business Change Management (to the left in Figure), and with the supplier’s Change Management (to the right in the figure). This may be an external supplier with a formal Change Management system, or with the project change mechanisms within an internal development project.

The Service Portfolio provides a clear definition of all current, planned and retired services. Understanding the Service Portfolio helps all parties involved in the Service Transition to understand the potential impact of the new or changed service on current services and other new or changed services. Strategic changes are brought in via Service Strategy and the business relationship management processes.

Changes to a service will be brought in via Service Design, Continual Service Improvement, and the service level management process. Corrective change, resolving errors detected in services, will be initiated from Service Operations and may route via support or external suppliers into a formal RFC.

As this explanation provides us a clear understanding of the scope of change management, let us discuss business value of change management.

Business Value of Change Management

In this section, we will discuss on how the change management process adds value to the business in the RCV practices. Reliability and business continuity are essential to the success and survival of any organization. Service and infrastructure changes can have a negative impact on the business through service disruption and delay in identifying business requirements.

Change Management enables the service provider to add value to the business by:

  • Prioritizing and responding to business and customer change proposals

  • Implementing changes that meet the customers’ agreed service requirements while optimizing costs

  • Contributing to meet governance, legal, contractual and regulatory requirements

  • Reducing failed changes and therefore service disruption, defects, and re-work

  • Delivering change promptly to meet business timescales

  • Tracking changes through the service lifecycle and to the assets of its customers

  • Contributing to better estimations of the quality, time and cost of change

  • Assessing the risks associated with the transition of services (introduction or disposal)

  • Aiding productivity of staff through minimizing disruptions due to high levels of unplanned or ‘emergency’ change and hence maximizing service availability

  • Reducing the Mean Time to Restore Service (MTRS), via quicker and more successful implementations of corrective changes

  • Liaising with the business change process to identify opportunities for business improvement.

The reliance on IT Services and underlying information technology is now so complex that considerable time can be spent on:

  • Assessing the impact of business change on IT

  • Analysing the impact of a service or IT change on the business

  • Notifying affected parties (of what is proposed, planned and implemented)

  • Recording and maintaining accurate change, configuration, release and deployment records

  • Managing and resolving incidents caused by change

  • Identifying the problems that continually arise that require more change

  • Introducing the new ideas and technology that cause even more change.

There are therefore considerable cost saving and efficiencies to be gained from well-structured and planned changes and releases.

To understand this better, let us look at an example in the next section.

Business Value of Change Management: Examples from Real Life

Example of IT service-initiated business change

In the retail industry, bar-coding of goods coupled with bar-code readers at the checkout was initially introduced to deliver savings by removing the need to label every item, automating stock control, speeding customer throughput and reducing checkout staff.

Suggestions from IT to the business resulted in making use of this facility to power innovative concepts such as ‘buy one get one free’ and capturing data on each individual’s purchasing habits.

Moving on, let us look at the policies of change management in the next section.

Change Management Policies

Increasing the success rate of changes and releases requires Executive support for implementing a culture that sets stakeholder expectations about changes and releases and reduces unplanned work. Pressure will be applied to reduce timescales and meet deadlines, to cut budgets and running costs, and to compromise testing.

This must not be done without due diligence to governance and risk. The Service Transition management team will be called on from time to time to make a ‘no go’ decision and not implement a required change. There must be policies and standards defined which make it clear to the internal and external providers what must be done and what the consequence of non-adherence to the policy will be.

Policies that support Change Management include:

  • Creating a culture of Change Management across the organization where there is zero tolerance for unauthorized change

  • Aligning the service Change Management process with business, project and stakeholder Change Management processes

  • Prioritization of change, e.g., innovation vs. preventive vs. detective vs. corrective change

  • Establishing accountability and responsibilities for changes through the service lifecycle

  • Segregation of duty controls

  • Establishing a single focal point for changes in order to minimize the probability of conflicting changes and potential disruption to the production environment

  • Preventing people who are not authorized to make a change from having access to the production environment

  • Integration with other Service Management processes to establish traceability of change, detect unauthorized change and identify change-related incidents

  • Change windows – enforcement and authorization for exceptions

  • Performance and risk evaluation of all changes that impact service capability

  • Performance measures for the process, e.g., efficiency and effectiveness.

In the next section, we will look at the design and planning considerations in change management.

Change Management: Design and Planning Considerations

The Change Management process should be planned in conjunction with Release and Configuration Management. This helps the service provider to evaluate the impact of the change on the current and planned services and releases.

The requirements and design for the Change Management processes include:

  • Requirements, e.g., to comply with relevant legislation, industry codes of practice, standards, and organizational practices

  • Approach to eliminating the unauthorized change

  • Identification and classification

  • Organization, roles, and responsibilities

  • Stakeholders

  • Grouping and relating changes

  • Procedures

  • Interfaces to other Service Management processes, e.g.,service level management and capacity management for impact assessment and review

  • Approach to interfacing Change, Release and Configuration Management with the problem and incident management processes to measure and reduce change-related incidents.

  • Configuration Management interfaces

In the next section, we will discuss about change requests.

What is Change Request?

A change request is a formal communication seeking an alteration to one or more configuration items.

  • This could take several forms, e.g.,‘Request for Change’ document, service desk call, Project Initiation Document.

  • Different types of change may require different types of change request.

  • An organization needs to ensure that appropriate procedures and forms are available to cover the anticipated requests.

  • Avoiding a rigid approach to documenting a minor change removes some of the cultural barriers to adopting the Change Management process.

Let us now proceed to learn about the types of change requests.

Types of Change Request

There are 3 types of change requests. And they are:

  • Standard Change Requests: Standard Change is a pre-authorized change that is low risk, relatively common and follows a procedure or work instruction

  • Normal Change Requests: Normal Change Requests are Service Change that goes through normal Change Management procedures

  • Emergency Change Requests: Emergency Change request is A change that must be implemented as soon as possible, for example, to resolve a major incident or implement a security patch.

In the next section, let us look at the key terms used in change request.

Types of Changes, RFC's & Changes Records : Let's Set The Record Straight!

Here in this section, we will go through the three keywords predominantly used in change management. Let’s understand what the exact meaning of these is:


-  Change would be any addition, modification or removal of anything that could have an effect on IT services.

- The scope should include changes to all architectures, processes, tools, metrics, and documentation, as well as changes to IT services and other configuration items.

RFC or Request for Change:

- A request for change – a formal proposal for a change to be made.

- It includes details of the proposed change, and may be recorded on paper or electronically.

- The term RFC is often misused to mean a change record, or the change itself.

Change Record:

- A record containing the details of a change.

- Each change record documents the lifecycle of a single change and is created for every request for change that is received, even those that are subsequently rejected.

- Change records should reference the configuration items that are affected by the change and may be stored in the CMS or elsewhere in the SKMS

In the next section, we will look at the different kinds of change requests.

Types of request by Service Lifecycle stage

The following table gives you the sample list of different kinds of change requests.

These change requests originate from different phases of a service lifecycle. For example, if you look at the first change request type “request for change to service portfolio” the documented work procedure is “Service change management” but if you observe the phase this request emerges is during Service Strategy. Thus these requests can originate during any time or phase of service lifecycles.

You can take a look at the other examples listed in the table for better understanding.

Let us discuss about change model in the next section.

Change Models

A change model is a way of predefining the steps that should be taken to handle a particular type of change in an agreed way.

Changes that require specialized handling could be treated in this way, such as:

  • Emergency changes that may have different authorization and may be documented based on past change requests.

  • Changes to mainframe software that may require specific sequences of testing and implementation

  • Implementation of security patches for desktop operating systems that require specific testing and guaranteed deployment to large numbers of targets, some of which may not be online

  • Service requests that may be authorized and implemented with no further involvement from change management.

Now let us proceed to understand the change proposals.

Change Proposals

Change management reviews the change proposal and the current change schedule, identifies any potential conflicts or issues, and responds to the change proposal by either authorizing it or documenting the issues that need to be resolved.

When the change proposal is authorized, the change schedule is updated to include outline implementation dates for the proposed change. After the new or changed service is chartered, RFCs will be used in the normal way to request authorization for specific changes. These RFCs will be associated with the change proposal so that change management has a view of the overall strategic intent and can prioritize and review these RFCs appropriately.

Next, let’s understand the standard change in detail.

Standard Changes

A standard change is a change to a service, or other configuration item for which the approach is pre-authorized by change management and this approach follows an accepted and established procedure to provide a specific change requirement.

  • Every standard change should have a change model which defines steps to follow, including how the change should be logged, managed and implemented.

Once the approach to manage standard changes has been agreed, standard changes processes and associated change workflows should be developed and communicated. A change model would normally be associated with each standard change to ensure consistency of approach.

Standard changes should be identified early on when building the change management process to promote efficiency. Some standard changes to configuration items may be tracked on the asset or configuration item lifecycle.

Some examples of standard changes are, upgrade of a pc with specific software, provision of equipment and service to the new employee. These changes can be considered as low impact, routine application change to handle seasonal variation.

  • Authorization of each occurrence of a standard change will be granted by the delegated authority for that standard change.

Examples are budget holding customer for installation of software from an approved list on a PC registered to their organizational unit or by the third party Engineer for replacement of a faulty desktop printer

Following are the crucial elements that make success for standard changes:

  • There should be a defined trigger to initiate the change. For example service request or an exception generated by event management.

  • Tasks are well known, documented and proven.

  • Authority should be effectively given to the people in advance.

  • Budgetary approval will typically be preordained or within the control of the change requester.

  • The risk should be normally low and always well understood.

If these elements are understood, agreed, documented with definitions and shared between all the stakeholders, the Standard change can be implemented easily.

In the next section, let us understand the term remediation and its planning.

Remediation Planning

Remediation: It refers to actions taken to recover after failed change or release. Remediation may include back out, request for service continuity plan, or other actions designed to enable the business process to continue.

Following points are included in remediation planning:

  • No change should be approved without having clearly addressed the question of what to do if it is not successful. Ideally, there will be a back-out plan, which will restore the organization to its initial situation, often through the reloading of a standardized set of CIs, especially software and data.

  • However, not all changes are reversible, in which case an alternative approach to remediation is required. This remediation may require a revisiting of the change itself in the event of failure or may be so severe that it requires reinstating the organization’s business continuity plan.

  • Only by considering what remediation options are available before instigating a change, and by establishing that the remediation is viable (e.g.,it is successful when tested), the risk of the proposed change be determined and the appropriate decisions are taken.

So far, we have looked at the purpose, objective, scope, change request terms, types, change model and proposals of change management. In the next section, let us get introduced to the process activities in change management.

Change Management Process Activities

This section provides approaches to managing service changes effectively by addressing the tasks carried out to achieve and deliver controlled change.

Overall Change Management activities include:

  • Planning and controlling changes

  • Change and release scheduling

  • Communications

  • Change decision making and change authorization

  • Ensuring there are remediation plans

  • Measurement and control

  • Management reporting

  • Understanding the impact of change

  • Continual improvement

In the next few sections, we will discuss these activities in detail. In the next section, let us look at the activities involved in the individual change request.

Typical activities in Managing individual changes

Typical activities in managing individual changes are:

  • Create and record the RFC

  • Reviewing RFC and change proposal

  • Assessing and evaluating the change

  • Authorizing the change

  • Planning updates

  • Coordinating change implementation

  • Reviewing and closing change

To understand the activities and differentiate the change requests let us look at the examples given in the next two sections.

Example Process flow for a Normal Change Request

This section gives you an example of Normal Change request process flow. The figure below shows an example of a change to the service provider’s services, applications or infrastructure.
Normal Change Request Process Flow

Examples of the status of the change are shown in italics. Change and configuration information is updated all the way through the activities. This example shows authorization for change build and test and for change deployment. In practice, there may be additional authorization steps, for example to authorize change design or change development.

Let’s look at another example in the next section.

Example Process flow for a Standard Operational Change Request

The image shown below gives you an example of standard change request process flow.
Standard Operational Change Request
A standard change is a change to a service or infrastructure for which the approach is pre-authorized by Change Management that has an accepted and established procedure to provide a specific change requirement.

Examples might include an upgrade of a PC in order to make use of specific standard and pre-budgeted software, new starters within an organization, or a desktop move for a single user. Other examples include low impact, routine application change to handle seasonal variation.

Approval of each occurrence of a standard change will be granted by the delegated authority for that standard change, e.g.,by the budget holding customer for installation of software from an approved list on a PC registered to their organizational unit or by the third party engineer for replacement of a faulty desktop printer.

The next section talks about the Major change management activities.

Major Change Management Activities

Now, in the subsequent sections, we will get into the details of different activities, methods, and techniques of change management. The list of activities for discussion is given below:

  • Create and record the RFC

  • Reviewing RFC and change proposal

  • Assessing and evaluating the change

  • Authorizing the change

  • Planning updates

  • Coordinating change implementation

  • Reviewing and closing change

In the next section, we will discuss the first two activities of change management.

Change Management Activities Methods and Techniques ( 1 of 6)

The first activity of change management is to Create and record Requests for change.

The details of this activity are:

  • The change is raised by a request from the initiator – the individual or organizational group that requires the change. For example, this may be a business unit that requires additional facilities, or problem management staff instigating an error resolution from many other sources.

  • For a major change with significant organizational and/or financial implications, a change proposal may be required, which will contain a full description of the change together with a business and financial justification for the proposed change. The change proposal will include signoff by appropriate levels of business management.

Let’s continue this discussion in the next section.

Change Management Activities Methods and Techniques (2 of 6)

The second activity is to Review the Request for Change.

Change Management should briefly consider each request and filter out any of the requests that seem to be:

  • Totally impractical

  • Repeats of earlier RFCs, accepted, rejected, or still under consideration

  • Incomplete submissions

Change Management Activities Methods and Techniques (3 of 6)

The third activity is to Assess and evaluate the change.

The potential impact on the services of failed changes and their impact on service assets and configurations need to be considered. Generic questions (e.g.,the ‘seven Rs’) provide a good starting point. Many organizations develop specific impact assessment forms to prompt the impact assessors about specific types of change. This can help with the learning process, particularly for new services or when implementing a formal impact assessment steps for the first time.

Responsibility for evaluating major change should be defined. It is not a best-practice issue because organizations are so diverse in size, structure,and complexity that there is not a universal solution appropriate to all organizations. It is, however, recommended that major change is discussed at the outset with all stakeholders in order to arrive at sensible boundaries of responsibility and to improve communications.

Although Change Management is responsible for ensuring that changes are assessed and, if authorized, subsequently developed, tested, implemented and reviewed, clearly final responsibility for the IT service – including changes to it – will rest with the service manager and the service owner. They control the funding available and will have been involved in the change process through direct or delegated membership of the Change Advisory Board (CAB).

Change Management Activities Methods and Techniques (4 of 6)

The fourth activity is Authorizing the change.

Formal authorization is obtained for each change from a change authority that may be a role, person or a group of people. The levels of authorization for a particular type of change should be judged by the type, size or risk of the change, e.g.,changes in a large enterprise that affect several distributed sites may need to be authorized by a higher-level change authority such as a global CAB or the Board of Directors.

The culture of the organization dictates, to a large extent, the manner in which changes are authorized. Hierarchical structures may well impose many levels of change authorization, while flatter structures may allow a more streamlined approach.

A degree of delegated authority may well exist within an authorization level, e.g.,delegating authority to a change manager according to pre-set parameters relating to:

  • Anticipated business risk

  • Financial implications

  • Scope of the change (e.g.,internal effects only, within the finance service, specific outsourced services).

Now let us look at the 7 R’s of change management.

7 R’s of Change Management

In the industry, there is a technique used for assessing the change, and it is s called 7R’s of change request.

For proper impact assessment and understanding of benefits/risks, these seven questions should be answered:

  1. Who RAISED the change?

  2. What is the REASON for the change?

  3. What is the RETURN required for the change?

  4. What are the RISKS involved in the change?

  5. What RESOURCES are required to deliver the change

  6. Who is RESPONSIBLE for build, test, and implementation of the change?

  7. What is the RELATIONSHIP between this change and other changes?

In the next section,let us look at an example of authorizing the change.

Example of Change Authorization Model

This section shows an example of Authorization model. An example of a change authorization hierarchy is shown here.

Each organization should formally document its own change authorization hierarchy, which may be very different to the example shown here. All change authorities should be documented in the CMS. If change assessment at level 2, 3 or 4 detects higher levels of risk, the authorization request is escalated to the appropriate higher level for the assessed level of risk.

The use of delegated authority from higher levels to local levels must be accompanied by trust in the judgment, access to the appropriate information and supported by management. The level at which change is authorized should rest where accountability for accepting risk and remediation exist.

Should disputes arise over change authorization or rejection, there should be a right of appeal to the higher level. Changes that have been rejected should be formally reviewed and closed.

Let us continue with the fifth activity of change management in the next section.

Change Management Activities Methods and Techniques (5 of 6)

The fifth activity of change management is Coordinating change implementation. Its details are:

  • Authorized RFCs should be passed to the relevant technical groups for building of the changes. It is best practice to do this in a formal way that can be tracked, e.g.,using work orders.

  • Change Management has the responsibility for ensuring that changes are implemented as scheduled. This is largely a coordination role as the actual implementation will be the responsibility of others (e.g.,hardware technical specialists will implement hardware changes). Remediation procedures should be prepared and documented in advance, for each authorized change so that if errors occur during or after implementation, these procedures can be quickly activated with minimum impact on service quality. Authority and responsibility for invoking remediation is specifically mentioned in change documentation.

  • Change Management has an oversight role to ensure that all changes that can be are thoroughly tested. In all cases involving changes that have not been fully tested, special care needs to be taken during implementation.

Testing may continue in parallel with the early live usage of a service – looking at unusual, unexpected or future situations so that further corrective action can be taken before any detected errors become evident in live operation.

The implementation of such changes should be scheduled when the least impact on live services is likely. Support staff should be on hand to deal quickly with any incidents that might arise.

In the next section, let us discuss the last activity of change management. 

Change Management Activities Methods and Techniques (6 of 6)

The last activity of change management is to Review and close change record.

Its details are:

  • On completion of the change, the results should be reported for evaluation to those responsible for managing changes, and then presented as a completed change for stakeholder agreement (including the closing of related incidents, problems or known errors). Clearly, for major changes, there are more customer and stakeholder input throughout the entire process.

  • A review should also include any incidents arising as a result of the change (if they are known at this stage). If the change is part of a service managed by an external provider, details of any contractual service targets will be required (e.g.,no priority 1 incidents during the first week after implementation). A change review (e.g.,post-implementation review, PIR) should be carried out to confirm that the change has met its objectives, that the initiator and stakeholders are happy with the results; and that there have been no unexpected side-effects. Lessons learned should be fed back into future changes. Small organizations may opt to use spot checking of changes rather than large-scale PIR; in larger organizations, sampling will have a value when there are many similar changes taking place.

  • There is a significantly different approach and profile between:

- The review of a service change – immediately visible to the customer and scheduled for discussion at the next service level management review meeting

- An infrastructure change – concerned with how IT delivers rather than what IT delivers, which will be (almost) invisible to the customer. Change Management must review new or changed services after a predefined period has elapsed. This process will involve CAB members since change reviews are a standard CAB agenda item.

  • The purpose of such reviews is to establish that:

- The change has had the desired effect and met its objectives

- Users, customers, and other stakeholders are content with the results, or to identify any shortcomings

- There are no unexpected or undesirable side-effects to functionality, service levels, warranties, e.g.,availability, capacity, security, performance, and costs

- The resources used to implement the change were as planned

- The release and deployment plan worked correctly (so include comments from the implementers)

- The change was implemented on time and to cost

- The remediation plan functioned correctly if needed.

  • Any problems and discrepancies should be fed back to CAB members (where they have been consulted or where a committee was convened), impact assessors, product authorities and release authorities, so as to improve the processes for the future.

  • Where a change has not achieved its objectives, Change Management (or the CAB) should decide what follow-up action is required, which could involve raising a revised RFC. If the review is satisfactory or the original change is abandoned (e.g.,the circumstances that required the change are no longer current and the requirement disappears) the RFC should be formally closed in the logging system.

In all discussion so far we have come across the term CAB, so what is CAB? Let’s look into this in the next section.

What is Change Advisory Board?

CAB refers to the Change Advisory Board. It is a body that exists to support the authorization of changes and to assist Change Management in the assessment and prioritization of changes.

As and when a CAB is convened, members should be chosen who are capable of ensuring that all changes within the scope of the CAB are adequately assessed from both a business and from a technical viewpoint.

The CAB may be asked to consider and recommend the adoption or rejection of changes appropriate for higher level authorization and then recommendations will be submitted to the appropriate change authority.

To achieve this, the CAB needs to include people with a clear understanding of the whole range of stakeholder needs.

The change manager will normally chair the CAB, and the potential members include:

  • Customer(s)

  • User manager(s)

  • User group representative(s)

  • Applications developers/maintainers

  • Specialists/technical consultants

  • Services and operations staff, e.g.,service desk, test management, ITSCM, security, capacity

  • Facilities/office services staff (where changes may affect moves/accommodation and vice versa)

  • Contractor’s or third party representatives, e.g.,in outsourcing situations

  • Other parties as applicable to specific circumstances (e.g.,police if traffic disruptions are likely, marketing if public products are affected).

It is important to emphasize that the CAB:

  • Will be composed according to the changes being considered

  • May vary considerably in make-up even across the range of a single meeting

  • Should involve suppliers when that would be useful

  • Should reflect both users’ and customers’ views

  • Is likely to include the problem manager and service level manager and customer relations staff for at least part of the time.

When the need for emergency change arises, i.e. there may not be time to convene the full CAB, it is necessary to identify a smaller organization with authority to make emergency decisions. This body is the Emergency Change Advisory Board (ECAB).

Change procedures should specify how the composition of the CAB and ECAB will be determined in each instance, based on the criteria listed above and any other criteria that may be appropriate to the business. This is intended to ensure that the composition of the CAB will be flexible, in order to represent business interests properly when major changes are proposed.

It will also ensure that the composition of the ECAB will provide the ability, both from a business perspective and from a technical standpoint, to make appropriate decisions in any possible events/outcomes.

In continuation to ECAB, let us understand emergency changes in the next section.

Emergency Change - ECAB

Emergency changes: These are sometimes required and should be designed carefully and tested before use or the impact of the emergency change may be greater than the original incident. Emergency changes may document some details based on past requests. The number of emergency changes proposed should be kept to an absolute minimum because they are generally more disruptive and prone to failure.

All changes likely to be required should, in general, be foreseen and planned, bearing in mind the availability of resources to build and test the changes. Nevertheless, occasions will occur when emergency changes are essential and so procedures should be devised to deal with them quickly, without sacrificing normal management controls.

Emergency change is reserved for changes intended to repair an error in an IT service that is negatively impacting the business to a high degree. Changes intended to introduce immediately and that require business improvements are handled as normal changes but assessed as having the highest urgency.

Emergency change authorization. Defined authorization levels will exist for an emergency change, and the levels of delegated authority must be clearly documented and understood. In an emergency situation, it may not be possible to convene a full CAB meeting. Where CAB approval is required, this will be provided by the Emergency CAB (ECAB).

Not all emergency changes will require the ECAB involvement; many may be predictable both in occurrence and resolution and well understood changes are identified with authority delegated, e.g.,to Operations teams who will action, document and report on the emergency change.

Let us now look at Emergency change building, testing, and implementation.

Authorized changes are allocated to the relevant technical group for building. Where timescales demand it, Change Management, in collaboration with the appropriate technical manager, ensures that sufficient staff and resources (machine time etc.) are available to do this work.

Procedures and agreements – approved and supported by management – must be in place to allow for this. Remediation must also be addressed and as much as testing of the emergency change is possible should be carried out.

Completely untested changes should not be implemented if at all it is better to avoid. Clearly, if a change goes wrong, the cost is usually greater than that of adequate testing. Consideration should be given to how much it would cost to test all changes fully against the cost of the change failing factored by the anticipated likelihood of its failure.

As we are now aware of the CAB and ECAB let us move on to understand the triggers on request for changes in the next section.

Change Management Process Triggers

Requests for change can be triggered throughout the service lifecycle and at the interfaces with other organizations, e.g.,customers and suppliers. There will also be other stakeholders such as partners that may be involved in the Change Management processes. Typical examples of types of change that trigger the Change Management process are described below:

Strategic changes

Service strategies require changes to be implemented to achieve specific objectives while minimizing costs and risks. There are no cost-free and risk-free strategic plans or initiatives. There are always costs and risks associated with decisions such as introducing new services, entering new market spaces, and serving new customers.

The following are examples of programmes and initiatives that implement strategic changes:

  • Legal/regulatory change

  • Organizational change

  • Policy and standards change

  • Change after analyzing business, customer and user activity patterns

  • Addition of new service to the market space

  • Updates to the Service Portfolio, customer portfolio or contract portfolio

  • Change of sourcing model

  • Technology innovation

Change to one or more services

Changes to the planned services (in the service portfolio) and changes to the services in the service catalog will trigger the change management process. These include changes to one or more services.

Here are few examples: Service catalog, Service package, Release package, Service assets etc. Operational Change

It is important to know the distinction between different types of requests that will be initiated by users. These types of request will depend on the nature of the organization and services and may include requests such as password reset, an access request or request to move an IT asset.

These types of change will often be managed as standard changes by the request fulfillment process. Service operation functions will also implement corrective and preventative changes via the normal change procedure and the standard change procedure. These should be managed through change management, for example restarting an application, which may impact a shared service.

Changes to deliver continual improvement

When CSI determines that an improvement to a service is warranted, an RFC should be submitted to change management. Changes such as changes to processes can have an effect on service provision and may also affect other CSI initiatives. Some strategy and service changes will be initiated by CSI.

Willing to take up a Course in ITIL Intermediate RCVCheck out the Course Preview!

Change Management Process Inputs and Outputs

Every process has its own set of inputs as well as outputs. Let us go through the different inputs and the outputs of the process one by one.

First let us look at the Inputs Changes that may be submitted as RFC, often with an associated change proposal that provides the detail of how the change will happen, e.g.,approach to implementing a legislative change. The change proposal will be based on a change model and will provide more detail about the specific change proposed.

The inputs include:

  • Policy and strategies for change and release

  • Request for Change

  • Change proposal

  • Plans – change, transition, release, deployment, test, evaluation, and remediation

  • Current change schedule and PSO

  • Current assets or configuration items, e.g.,baseline, service package, release package

  • As-planned configuration baseline

  • Test results, test report and evaluation report.

Next, let’s look at the Outputs.

Outputs from the process will be:

  • Rejected RFCs

  • Approved RFCs

  • Change to the services, service or infrastructure resulting from approved RFCs

  • New, changed or disposed of assets or configuration items, e.g.,baseline, service package, release package Change schedule

  • Revised PSO

  • Authorized change plans

  • Change decisions and actions

  • Change documents and records

  • Change Management reports.

Let us now discuss about the process interfaces in change management.

Change Management Process Interfaces

In order to be able to define clear boundaries, dependencies and rules, change and release management should be integrated with processes used for organizational programmes or projects, supplier management and also integrated with suppliers’ processes and procedures.

There will be occasions when a proposed change will potentially have a wider impact on other parts of the organization (e.g.,facilities or business operations), or vice versa, and the service change process must interface appropriately with other processes involved. Let’s discuss these processes in detail.

Integration with business change processes

Where appropriate, the Change Management should be involved with business programme and business project management teams to ensure that change issues, aims, impacts, and developments are exchanged and cascaded throughout the organization where applicable.

This means that changes to any business or project deliverables that do not impact services or service components may be subject to business or project Change Management procedures rather than the IT service Change Management procedures. However, care must be taken to ensure that changes to service configuration baselines and releases do follow the Change Management process.

The Change Management team will, however, be expected to liaise closely with projects to ensure smooth implementation and consistency within the changing management environments.

Programme and project management

Programme and project management must work in partnership to align all the processes and people involved in service change initiatives. The closer they are aligned, the higher the probability that the change effort will be moved forward for as long as it takes to complete. Change Management representatives may attend relevant Project Board meetings.

Sourcing and partnering arrangements should clearly define the level of autonomy a partner may have in effecting change within their service domain without reference to the overall service provider. A key component is how deeply change processes and tools are embedded into the supplier organization or vice versa and where the release veto(refusal) takes place. If the supplier has responsibility for the availability of the operational service, conflicts can arise.

Sourcing and partnering

Sourcing and partnering include internal and external vendors and suppliers who are providing a new or existing service to the organization. Effective Change Management practices and principles must be put in place to manage these relationships effectively to ensure smooth delivery of service.

The effort also should be put into finding out how well the partners themselves manage change and choose partner and sourcing relationships accordingly. It is important to ensure that service providers (outsourced or in-house) provide the Change Management function and processes that match the needs of the business and customers. Some organizations in outsourcing situations refer RFCs to their suppliers for estimates prior to approval of changes.

Organizational and Stakeholder change management

In some organizations there is a separate function that manages organizational changes; in others, this aspect of change management may be carried out within the IT organization. It is, however, always essential that organizational aspects of change management are properly considered and that the change management process has appropriate interfaces with the people carrying out this work.

Let us now look at the interfaces within service management.

Change Management Interfaces within Service Management

The figure below shows different interfaces within Service management.

The Service Management processes may require change and improvements. Many will also be involved in the impact assessment and implementation of service changes, as discussed below:

Service Asset and Configuration Management

The Configuration Management System provides reliable, quick and easy access to accurate configuration information to enable stakeholders and staff to assess the impact of proposed changes and to track changes workflow. This information enables the correct asset and service component versions to be released to the appropriate party or into the correct environment.

As changes are implemented, the Configuration Management information is updated. The CMS may also identify related CI or assets that will be affected by the change, but not included in the original request, or in fact similar CI or assets that would benefit from similar change.

Problem Management

Problem Management is another key process as changes are often required to implement workarounds and to fix known errors. Problem Management is one of the major sources of RFCs and also often a major contributor to CAB discussion.

IT Service Continuity Management

IT Service Continuity has many procedures and plans; these should be updated via Change Management to ensure that they are accurate, up to date and that stakeholders are aware of changes.

Information Security Management

Security Management interfaces with Change Management since changes required by security will go via the Change Management process and security will be a key contributor to CAB discussion on many services. Every significant change will be assessed for its potential impact on the security plan.

Capacity and Demand Management

Capacity and Demand Management is a critical aspect of Change Management. Poorly managed demand is a source of costs and risk for service providers because there is always a level of uncertainty associated with the demand for services.

Capacity Management has an important role in assessing proposed changes – not only the individual changes but the total impact of changes in service capacity. Changes arising from Capacity Management, including those set out in the capacity plan, will be initiated as RFCs through the change process.

Change Management Interfaces with SACM

This section gives the pictorial depiction of the interface of change management with SACM which has already been explained in the last section

Change Information Management

All change requests must be associated with services and other CIs. This means that either they must be included within the CMS or a mechanism must be provided to enable cross-referencing and searching changes related to CIs. It is very common for a single tool to be used for managing incidents, problems and, changes, as well as the CMS, and this kind of tool can help to improve the efficiency of the processes.

It is very important to be able to correlate changes with incidents and to review the history of changes to any CI as part of incident or problem management. This requires access to historical change information, which should be made available for searches.

Change management must have access to the CMS and to information and documents within the SKMS in order to plan and manage changes, to identify stakeholders in any change, and to predict the potential impact of changes.

Let us look at the Critical Success Factors and KPIs of change management.

Change Management CSF's And KPI's ( 1 of 3)

The following list includes some sample CSFs for Change Management Process.

Each organization should identify appropriate CSFs based on its objectives for the process. Each sample CSF is followed by a small number if typical KPIs that support the CSF. These KPIs should not be adopted without careful consideration.

Each organization should develop KPIs that are appropriate for its level of maturity, its CSFs and its particular circumstances. Achievement against KPIs should be monitored and used to identify opportunities for improvement, which should be logged in the continual service improvement(CSI) register for evaluation and possible implementation.

Let us take one CSF which states that:

  • Responding to business and IT requests for change that will align the services with the business needs while maximizing value.

So the supporting KPIs would be:

  • Increase in the percentage of changes that meet the customer’s agreed requirements, e.g.,quality/cost/time

  • The benefits of change (expressed as ‘value of improvements made’ plus ‘negative impacts prevented or terminated’) exceed the costs of change

  • Reduction in the backlog of change requests

  • Average time to implement meets SLA targets, based on urgency/priority/change type

  • Increase in scores in the survey of stakeholder satisfaction for the change management process

  • Increase in the accuracy of predictions for time, quality, cost, risk, resource and commercial impact

Change Management CSF's And KPI's ( 2 of 3)

Next CSF states:

  • Optimizing overall business risks

Supporting KPIs could be:

  • Reduction in the number of disruptions to services, defects and re-work caused by inaccurate specification, poor or incomplete impact assessment

  • Reduction in the percentage of changes that are categorized as emergency changes

  • Increase in change success rate (percentage of changes deemed successful at review/number of changes authorized)

  • Reduction in the number of changes where remediation is invoked

  • Reduction in the number of failed changes

  • Reduction in the number of unauthorized changes identified

  • Reduction in the number of incidents attributed to changes

Change Management CSF's And KPI's ( 3 of 3)

The last CSF states:

  • Ensuring that all changes to configuration items are well managed and recorded in the configuration management system.

Supporting KPIs could be:

  • Reduction in the number and percentage of changes with incomplete change specifications

  • Reduction in the number and percentage of changes with incomplete impact assessments

  • Reduction in number of audit compliance issues for the change management process

  • Reduction in number and percentage of discrepancies found by service asset and configuration management verification and audit

In the next section, let us discuss about the challenges faced when implementing change management.

Change Management Challenges

This section talks mainly about the challenges of change management process implementation. They are:

  • The major challenge for change management is ensuring that every change is recorded and managed. Regular communication of the scope and value of change management will help to ensure that IT staff understands the scope and value of change management and do not try to bypass the process.

  • Make sure that it is seen to add value by helping changes happen faster and with higher success rates.

  • Migrate to a true change management process that becomes involved early enough in the service lifecycle, includes assessment of benefits and costs, and helps to plan and manage changes.

  • Agree and document the many levels of change authority that are needed to manage change effectively and to communicate effectively with these change authorities.

We have looked at the challenges, now let’s move to discuss about the risks involved.

Change Management Risks

The Next two sections talk about the risks of implementing change management process.

The Risks involved in this process could be:

  • Lack of commitment to the change management process by the business, IT management or IT staff and lack of business or IT Management sponsorship

  • Implementation of changes without the use of change management

  • Change assessment being reduced to box-ticking, without real consideration of the risks, costs, and benefits

  • Introduction of delays to change the implementation without adding sufficient value

  • Insufficient time being allowed for proper assessment of changes, and pressure from projects or the business to expedite decisions

  • Insufficient time allowed for the implementation of changes, and attempts to fit too many changes into a change window

  • Insufficient resources for assessment, planning, and implementation of the number of changes required by the business

  • Lack of clarity on how change management should interact with other service management processes, such as release and deployment management or service asset and configuration management

  • Lack of clarity on how change management should interact with project management or service design activities

  • Excessively bureaucratic change management processes that introduce an excessive delay to required changes.

Moving on, let us discuss on Operational activities of change management in the next section.

Change Management Operational Activities

There are certain operational activities of change management. And they include:

  • Raising and Submitting RFCs

  • Participating in CAB/ECAB meetings

  • Implementing changes as directed by change management

  • Backing out changes as directed by change management

  • Helping, define and maintain change models

  • Receiving change schedules

  • Using change management process for standard/operational type changes

In the next section, let us discuss the change triggers in service operation

Change Triggers in Service Operations

There are many things that may trigger a change in the Service Operation environment. These include:

  • New or upgraded hardware or network components

  • New or upgraded applications software

  • New or upgraded system software (operating systems, utilities, middleware etc. including patches and bug fixes

  • Legislative, conformance or governance changes

  • Obsolescence – some components may become obsolete and require replacement or cease to be supported by the supplier/maintainer

  • Business imperative – you have to be flexible to work in ITSM, particularly during Service Operation, and there will be many occasions when the business needs IT changes to meet dynamic business requirements

  • Enhancements to processes, procedures and/or underpinning tools to improve IT delivery or reduce financial costs

  • Changes of management or personnel (ranging from loss or transfer of individuals right through to major takeovers or acquisitions)

  • Change of service levels or in service provision – outsourcing, in-sourcing, partnerships, etc.

Let us now proceed to discuss about Managing change in Service operation in the next section.

Managing Change In Service Operations

Service Operation should strive to achieve stability – but not stagnation! There are many valid and advantageous reasons why ‘change is a good thing’ – but Service Operation staff must ensure that any changes are absorbed without adverse impact upon the stability of the IT services being offered.

Change assessment

Service Operation staff must be involved in the assessment of all changes to ensure that operational issues are fully taken into account. This involvement should commence as soon as possible not just at the later stages of change – i.e. CAB and ECAB membership – by which time many fundamental decisions will have been made and influence is likely to be very limited.

The Change Manager should inform all affected parties of the change being assessed so input can be prepared and available prior to CAB meetings. However, it is important that Service Operation staff is involved at these latter stages as they may be involved in the actual implementation and they will wish to ensure that careful scheduling takes place to avoid potential contentions or particularly sensitive periods.

Measurement of successful change

The ultimate measure of success in respect of changes made to Service Operation is that customers and users do not experience any variation or outage of service. So far as possible, the effects of changes should be invisible, apart from any enhanced functionality, quality or financial savings resulting from the change.

Managing organization and stakeholder change

Service Transition’s basic role is, on the basis of agreed design, to implement a new or changed service, effectively making the organization different than it was before. For a change of any significance, this is delivering an organizational change, ranging from moving a few staff to work from new premises through to major alterations in the nature of business working, e.g.,from face-to-face retail to web-based trading.

Change is an inevitable and important part of organizational development and growth.

Change can occur in incremental phases or suddenly, affecting some or all of an organization, its people, and its culture. Without change, progress does not happen. Organizational change efforts fail or fall short of their goals because changes and transitions are not led, managed and monitored efficiently across the organization and throughout the change process.

These gaps in key organizational activities often result in resistance, dissatisfaction, and increased costs. Change is never easy; it usually takes longer than planned and creates barriers and resistance along the way. Effective leaders and managers understand the change process and plan and lead accordingly. Major negative impact can come from losing staff – disillusioned people leaving – which brings risks to the organization, e.g.,loss of knowledge and lack of handover.

Factors that drive successful change initiatives at the organizational level include:

  • Leadership for the change

  • Organizational adoption

  • Governance

  • Organizational Capabilities

  • Business and service performance measures

  • A strong communication process with regular opportunity for staff feedback.

    What are you waiting for? Interested in taking up the ITIL Intermediate RCV Course? Check out our Course Preview here!

Understanding the Organization Culture

For successful Service Transition, an organization needs to determine the underlying values and drivers that enable effective management of change. Each organization and combination of organizations is different so the Service Transition approach to change is determined, in part, by the culture and so may vary across the organization.

Organizational culture is the whole of the ideas, corporate values, beliefs, practices, and expectations about behavior and daily customs that are shared by the employees in an organization. Culture can support an implementation, or it can be the source of resistance.

When performing Service Transition activities it is important to gain an understanding of the type of culture currently existing in the organization and how this is likely to be affected by any proposed changes. Conversely, it is equally important to understand the effect current culture may have a ‘barrier’ to realizing change.

Examples of key questions to be posed to help identify culture are shown below.These questions are useful when reviewing the Service Strategy and Service Design deliverables.


Cultural Aspect



  • Is there a common language or shared language(s)?

  • Does the language inhibit and reinforce boundaries or facilitate effective change and knowledge transfer?

  • Is the organizational language style mostly formal or informal?


  • Does the organization appear to resist change or is it constantly evolving?


  • What are the preferred modes of communication?

  • What is the content and style of internal communications?

  • Where does official and unofficial communication happen?

  • Are communication channels open and democratic or closed and hierarchical?

  • How are knowledge and experience shared?

  • Are rumors/gossip relevant?

Knowledge flow

  • How do people describe the way knowledge and information are transferred in the organization?

  • How easy is it to find what you need to know when you need it?

  • How easy is it to find the right person with the right experience?


  • Are there identifiable ‘communities’ within the organization?

  • Is there a community leader, e.g.,problem management community leader?

  • What is the structure and function of these communities?


  • Are an individual’s networks well developed, on the whole?

  • What kind of information is exchanged by these people?

Working Environment

  • Does the working environment create the right conditions for knowledge transfer and integrated working, e.g.,close proximity physically and/or electronic tools?

  • How are desks configured?

  • How are communal areas used?

  • History How does the organization see its own history?

  • Is it valued and used or quickly forgotten?

  • How does the organization value past experiences, e.g.,do people still refer back to their old company after a merger?


  • Are meetings seen as productive?

  • How are they managed?

  • Are they effective?

  • Does everyone feel safe to speak?

  • How is opinion or criticism handled?

  • How is output captured or taken forward?

Rewards and motivations

  • How are individuals/teams rewarded or recognized for sharing knowledge/information and experience?

  • What motivates people in the organization?

  • What else might be blocking engagement of an individual/team, e.g.,other major change, major incident handling?


  • What are individuals’, teams’ and the organizational attitudes to time, e.g.,busy or relaxed; punctual, rigid and unchanging or flexible?

With this we have come to the end on the learning unit, let us quickly summarize in the next section.


Let us now quickly recap on learning unit 2. In this module we looked at:

  • The overall activities of Change Management include: planning and controlling changes; change and release scheduling; communications; change decision making and change authorization; ensuring there are remediation plans; measurement and control; management reporting; understanding the impact of change; and continual improvement.

  • Techniques for each major Change Management are: create and record requests for change; review the requests for change; assess and evaluate the change; authorize the change; coordinate change implementation; and review and close change record.

  • Change Management process triggers include strategic changes; change to one or more services; operational change; and changes to deliver continual improvement.

  • Change Management interfaces include integration with business change management; program and project management; and sourcing and partnering.

  • Measures taken should be linked to business goals wherever practical—and to cost, service availability, and reliability. Any predictions should be compared with actual measurements.

  • Improving service management is to embark upon an organizational change program

Let us now move to Module 3 on Service Asset and Configuration Management.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Work Email*
Phone Number*
Job Title*