IT Change Management 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.
lifecycle
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 changes 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 RFCs 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.
stakeholders
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.
visibility
The level of transparency into change processes.
