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.
The state of an RFC where all planning, documentation and approval requirements have been fulfilled.
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.
Standardised processes that are often repetitively used.
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 minimising service disruptions.
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 practises in IT change management.
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.
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.
The business rules requirements directing what information is required to be provided, who authorises 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.
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-practises list: Major, Significant, Minor, Low
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-practises list: Bug Fix, Business Need, External Requirement, Hardware Fix, Hardware Upgrade, Network Upgrade, Procedural, Software Upgrade, Telecom Upgrade
RFC closed code
A general categorisation of the results of the implementation. Sample best-practises 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-practises 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.
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 organisation, the effect upon the infrastructure and customer service, as well as the effect of not implementing the change. Sample best-practises list: Most severe, Somewhat severe, Future, Request
RFC implementation plan
The details of how the change will be specifically implemented.
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-practises 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-practises list: Awaiting Approval, Backout Plan, Implementation Plan, Test Plan
The urgency priority of the request for change. Sample best-practises list: Urgent, Major, Significant, Minor
RFC rejection reason
A general reason why an RFC was rejected. Sample best-practises 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.
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-practises 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.
Usually a geographical location affected by the RFC. Sample best-practises list: Geographical, Global, Local, Subsidiary
RFC service group
The IT department that is assigned to implement the request for change.
The status of the request for change as it moves through its life cycle. Sample best-practises 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.
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.
ITIL terminology for the planning of new services or the updating of current ones.
The specific effects and length of time an IT service might be unavailable.
ITIL terminology for a service having been implemented and in a production environment.
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.
ITIL change type defined as low-risk, often repetitive changes, where the factors affecting the change are already known.
How long a specific computing system will be unavailable during the implementation of the change.
The level of transparency into change processes.