ITIL Change Evaluation Tutorial

What is the ITIL Change Evaluation Process? 

Change Evaluation is one of the main processes under Service Transition Module of the ITIL best practice framework. We already learned about the Change Management process. We may think of this process as an extension of Change Management.

This ITIL Change Evaluation Process comes into the picture, whenever the organization decided to make major changes to their existing infrastructure or services. This process is undertaken separately for managing risks associated with major changes to reduce the chances of failures.

This process is tightly bound with some other processes, such as Design Coordination, Transition Planning & Support, and some part of Incident Management.

ITIL Change Evaluation Objective: 

The primary objective of ITIL Change Evaluation Process is to assess major Changes, like the introduction of a new service or a substantial change to an existing service, before those Changes are allowed to proceed to the next phase in their lifecycle Another objective is to reduce or avoid risks that are associated with major changes.

ITIL V3 Change Evaluation Purpose: 

As per ITIL v3, the purpose of this process is to provide a uniform and structured method to determine the performance of a change relating to the likely impact on the business, on any existing or proposed services, and on the current and future IT infrastructure.

It also helps the change management to make the decision on whether a change has to be authorized or not.

The Change Evaluation – ITIL V3 Process must include these activities:

• Identifying risks.
• Evaluating the intended effects of the change.
• Anticipating any unintended effects of the change.
• Verify if the proposed change complies with the organization’s change management policy.
• Presenting a recommendation to change management on whether to proceed to the next stage.

ITIL Change Evaluation Sub-Process: 

As defined by ITIL v3, there are four sub-processes of this process. Below are the objectives and descriptions of those sub-processes, followed by a diagram to explain the ITIL Change Evaluation Process flow:

1) Change Evaluation prior to Planning:

To assess & evaluate a proposed major Change before authorizing the Change planning phase.

2) Change Evaluation prior to Build:

To assess & evaluate a proposed major Change before authorizing the Change build phase.

3) Change Evaluation prior to Deployment:

To assess & evaluate a proposed major Change before authorizing the Change deployment phase.

4) Change Evaluation after Deployment:

To assess & evaluate a major Change after it has been implemented, to verify if the Change has met its objectives and to record any lessons learned from this change.

Important Terminologies & Definitions:

Change Evaluation Report:

• In case of Major Changes, like the introduction of a new service or a significant change to an existing service, require a formal and extensive evaluation of the change before its being authorized.
• The results of that formal assessment are documented in this Change Evaluation Report.

Change Management Policy:

• The Change Management Policy specifies the organizational guidelines about the levels of authorization required to authorize different types of Changes and other rules for assessing Changes.
• This is all about assessing and reducing the risks associated with a change.
• Change Management Policy is used as an input to the Change Evaluation Process to validate the change in terms of business strategy.

ITIL Change Evaluation Roles and Responsibilities:

Change Manager:

• As discussed earlier, Change Manager is the Process Owner of this process.
• This role is responsible for controlling this whole process along with change management.

The Roles of ITIL Change Evaluation Process are the same as the ITIL Change Management Roles.

What is ITIL Change Management?

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

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

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

Benefits of Change Management

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

Some of the benefits that result from Change Management include:

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

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

ITIL Service Transition processes include:

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

Definition of a “Change”

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

Changes can be brought about in two ways

1) Change Request or Request for Change (RFC)

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

2) Change Proposal

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

Types of Changes

1) Emergency Change/Urgent Change

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

2) Standard Change

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

3) Major Change

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

4) Normal Change

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

Additional Change Requests may include:

• Application Changes
• Hardware Changes
• Software Changes
• Network Changes
• Documentation Changes
• Environmental Changes

The Change Management Process Flow

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

A typical Change Management Process includes the following activities:

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

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

2) Review Request for Change (RFC)

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

3) Evaluate the Change

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

4) Approve/Authorize the Change

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

5) Coordinate Implementation

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

6) Review and Close Change Request

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

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

Inter-Related ITIL Processes

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

1) Problem Management

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

2) Configuration and Asset Management

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

3) Release and Deployment Management 

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

4) IT Service Continuity Management 

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

5) Security Management 

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

6) Knowledge Management 

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

7) Request Fulfillment 

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.

8) Portfolio Management 

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

Change Management Roles and Responsibilities 

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

1) Change Requestor/Initiator

The individual or business unit requesting a change.

2) Change Advisory Board (CAB)

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

3) Change Owner/Manager/Authority

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

Change Management Key Performance Indicators (KPIs)

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

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

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

Feature Checklist for Change Management Software

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

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

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

Scope of ITIL Change Evaluation

The following come under the scope of change evaluation:

• Each change should be authorized at several points during its lifecycle. This can be during its building, testing, before it is checked into the DML, and before it is deployed into a live environment.
• Prior to each authorization, an evaluation is necessary to provide the change authority with the required advice and guidance.
• The process of change evaluation describes a formal evaluation which is suited for usage when significant changes are being evaluated.
• Every organization should decide the particular changes which should make use of this formal change evaluation and can be evaluated as a part of the change management process.

Value of ITIL Change Evaluation

Change evaluation contributes a lot to business, which makes it valuable.

• Change evaluation establishes the usage of manmade resources in terms of the benefits delivered.
• This information allows for an increasingly accurate focus on value in service development and change management.
• CSI can take a significant amount of intelligence from change evaluation to inform about future improvements to the process of change. It also makes predictions and performs measurement of service change performance.

Principles of Change Evaluation

The change model evaluation process makes use of the Plan-Do-Check-Act (PDCA) model to make sure that all evaluations are consistent.

Each and every evaluation is first planned and then carried out in multiple stages. The results of the evaluations are checked, and actions are taken to resolve any issues which have been discovered.

Process Activities of ITIL Change Evaluation

• The evaluation planning process starts when the inputs and a trigger are provided. The inputs can be service design, service validation, and testing, etc.
• The performance of the process is evaluated, and an interim evaluation report is generated.
• If the performance is as predicted, then the actual performance evaluation begins. If not, the process is ended.
• If the actual performance has been found to meet the requirements, then the change is said to be complete.
• If the change is incomplete, it is advised to wait for the next change authorization point and begin evaluation of actual performance again.
• Once the change is complete, the evaluation report is generated.

Challenges of ITIL Change Evaluation

The following challenges arise during change management process:

• The main challenge lies in developing standard performance measures and measurement methods across the projects and suppliers.
• It is essential to understand the perspectives of the different stakeholders involved in the process
• It is important to understand the difference between managing risks and taking a risk.
• It is also vital to have clear communication about the organization’s attitude to risk and to encourage a risk management culture.
• Building a detailed understanding of risks which have impacted or which may impact the transition of services is also important.

Risks of ITIL Change Evaluation

The following risks are encountered during change management process:

• Expectations which are unrealistic while considering the time required for change evaluation.
• The absence of clear criteria regarding when change evaluation should be used.
• Presence of personnel with insufficient experience and authority in the organization, which plays a major role in being able to influence change authorities.
• Delays caused by projects or suppliers in scheduling change evaluation.

Change evaluation thus sets correct expectations for the stakeholder and evaluates the intended and unintended effects of a service change. By providing a good quality output, change management can make decisions about expediting decisions and authorizing service changes.

consistent and standardized to determine the performance of a service change. It can happen in the context of possible impacts on business outcomes and on the present and proposed services and IT infrastructure.

The assessment of the actual performance of change is made against its predicted performance. There are certain risks and issues related to change, which are identified and managed.