IT Change Management Glossary of Terms

Help Desk Glossary of Terms

List of IT Change Management Industry Terms

Download this glossary of IT change management industry terms to better understand industry jargon.

approvals business rules

The rules that define the list of approvers required for a change process to progress, along with the order of their approval.

approved RFC

The state of an RFC where all planning,  documentation and approval requirements have been fulfilled.

change manager

The person who coordinates all change management activities and ensures approved changes represent an acceptable level of possible and probable risk and impact.

change advisory board (CAB)

A separate group or a committee that is responsible for assessing the readiness of nonstandard changes to the production environment.

change models

Standardized processes that are often repetitively used.

emergency change

ITIL change type defined as an emergency, often unexpected, where the change must be implemented as quickly as possible.

emergency committee (EC)/emergency change advisory board (ECAB)

A special group of people who advise when a change is an emergency or has high impact.

forward schedule of changes

This list of changes that are currently scheduled.

IT change management

The process responsible for controlling changes to the production environment while minimizing service disruptions.

IT infrastructure

The hardware and network the IT department provides and supports.

IT Infrastructure Library® (ITIL) change management

A structured framework to help define and implement best practices in IT change management.

IT services

The software, networking, and personal computing the IT department provides and supports.

IT to business alignment

How IT's costs affect overall business objectives.


The time, processes, and procedures the relate to an RFC from the opening of the request to its closing.

normal change

ITIL change type defined as non-emergency, where the factors affecting the change are not already known.

post implementation review (PIR)

A survey and cataloging of the change’s implementation process and rollout into production, including successes and failures, or any follow-up work that is required as a result.

process flow

The business rules requirements directing what information is required to be provided, who authorizes which steps, who needs to approve, when and to whom notifications are sent, during the change process.

request for change (RCF)

The official request for a change in the IT environment that contains all the information regarding the change.

RFC approvers

A list of the people who approved the change.  The number required is based on change management approval rules requirements.

RFC backed out reason

The details as to why a change needed to be reverted.

RFC backout plan

The details of how the revert the change should problems occur.

RFC benefit value

How much the change will benefit the business.  Sample best-practices list:  Major, Significant, Minor, Low

RFC builder

The person assigned to deploy the change.

RFC business line manager

The manager the RFC’s customer affected.

RFC change category

A general description of the type of change.  Sample best-practices list:  Bug Fix, Business Need, External Requirement, Hardware Fix, Hardware Upgrade, Network Upgrade, Procedural, Software Upgrade, Telecom Upgrade

RFC closed code

A general categorization of the results of the implementation.  Sample best-practices list:  Backed Out, Cancelled, Successful, Successful with Problems, Unsuccessful

RFC closed date

The date the RFC is marked as completed in total.

RFC cost level

A general description of the cost impact of the change.  Sample best-practices list:  High, Medium, Low

RFC customer(s) affected

A single person or list of personnel entities (departments, buildings, locations, etc.) that will be affected by the change.

RFC department

Any non-IT department that is assigned to help implement the request for change.

RFC impact level

The measure of what the impact of the change will have on the business organization, the effect upon the infrastructure and customer service, as well as the effect of not implementing the change.  Sample best-practices list:  Most severe, Somewhat severe, Future, Request

RFC implementation plan

The details of how the change will be specifically implemented.

RFC implementer

The person from the RFC service group assigned to implement that change.

RFC induced problem category

A general classification of a specific problem that occurred because of the change.  This is usually assigned to a detail note of the specific issue.  Sample best-practices list:  Conflict with existing software, Customers not set up in the database, Customers not trained, Customers surprised, Errors with certain operating systems, Interfered with business priorities, Service desk not trained for support

RFC pending actions

The actions that still need to be completed in preparing the RFC before actual implementation.  Sample best-practices list:  Awaiting Approval, Backout Plan, Implementation Plan, Test Plan

RFC priority

The urgency priority of the request for change.  Sample best-practices list:  Urgent, Major, Significant, Minor

RFC rejection reason

A general reason why an RFC was rejected.  Sample best-practices list:  Budget Constraints, Business Reasons, Duplicate Request, Insufficient Cause, Schedule Conflicts

RFC rejection reason details

A detailed description as to why an RFC was rejected.

RFC requested date

The date requested for the change to be implemented.

RFC requester

The person requesting the change.  This may or may not be the person who actually filed the request (eg. an IT technician may file the request for the IT manager).

RFC risk level

A measure of the probability of failure.  Sample best-practices list:  Major, Significant, Minor, Routine

RFC schedule window

The hours set aside for the actual implementation of the change.  Typically, the change cannot be completed during this window, it is rolled back and rescheduled to implemented at another time.

RFC scope

Usually a geographical location affected by the RFC.  Sample best-practices list:  Geographical, Global, Local, Subsidiary

RFC service group

The IT department that is assigned to implement the request for change.

RFC status

The status of the request for change as it moves through its life cycle.  Sample best-practices list:  New, Planning, Pending, Scheduled, WIP (work in progress), Closed, Rejected

RFC test plan

The details of how the change will be tested before and after the change.

RFC tester

The person responsible for making sure the change is tested before final implementation.

RFC total change back cost

All costs that can be accounted to departments other than IT.

RFC total materials cost

All physical materials costs related to the change.

RFC total resources cost

All personnel costs related to the change.

service design

ITIL terminology for the planning of new services or the updating of current ones.

service disruption

The specific effects and length of time an IT service might be unavailable.

service operation

ITIL terminology for a service having been implemented and in a production environment.

service transition

ITIL terminology for moving from the design phase to the operation phase.


All people involved in the entire planning and implementation processes of the change.

standard change

ITIL change type defined as low-risk, often repetitive changes, where the factors affecting the change are already known.

system downtime

How long a specific computing system will be unavailable during the implementation of the change.


The level of transparency into change processes.

Additional Whitepapers