Appendix B Example of a basic request for change form
| Data element | Description | Comments |
| Tracking number | Unique ID number assigned by change manager/CAB | |
| Status | Current status of request. Field managed by change manager/CAB Submitted – RFC has been accepted by change manager/CAB for consideration Approved – RFC has been reviewed and approved by change manager/CAB Rejected – RFC has been reviewed and rejected by change manager/CAB – explanation provided in Comments field Pending – RFC has been reviewed and is awaiting further information, explanation or other |
|
| Change type | Normal – Normal change Standard – Standard, pre-approved change Emergency – Changes that must happen faster than a normal CAB schedule allows. Typically associated with either rapidly emerging business needs or incident management |
|
| Priority | Urgent – High – Medium – Low – |
|
| Initiator of RFC | Name and department/role of the person initiating the RFC | |
| Submission date | Date the RFC is submitted | |
| Short description of change | Description of the change being requested | |
| Reason for change | Description of why the change is being requested, explaining the expected results and benefits from the business perspective | For significant changes, this can be a pointer to a more complete plan |
| Configuration items (CIs) | List of all CIs impacted by the change | CIs are components of the IT infrastructure (both hardware and software) that are managed by the IT organization |
| Customers and users impacted | Which customers and users are impacted by the proposed change. Includes those who may be potentially impacted | |
| Proposed change date | Desired implementation date of the proposed change | |
| Proposed change time | Desired time to implement the change | |
| Change duration | Estimated time to fully implement the change, including time to fully roll back if needed | |
| Approved change date | Agreed implementation date for the approved change (decided by change manager/CAB) | If organization has established release windows, substitute to match |
| Approved change time | Agreed implementation time for the approved change (decided by change manager/CAB) | |
| Implementation plan | Detailed plan to implement the proposed change Description of the major steps to be performed Who will be performing the steps |
For large or high-impact changes, this may be a pointer to release or project plans. The level of detail depends on the culture as well as the nature of the requested change. Encourage requesters to err on the side of more detail |
| Communication plan | What information will be communicated to customers, who will receive it, and how it will be done | |
| Post-implementation test plan | How the change will be tested once complete to ensure the desired outcomes will be realized by the business | If organization has customer acceptance plans, include here |
| Back-out plan | Detailed plan to undo (roll back) the change to the pre-change state in the event of trouble or unintended results | For large or high-impact changes, this may be a pointer to release or project plans |
| Comments | Additional information as needed | Use to document ‘pending’ or ‘rejected’ requests |
| Result | Status indicating the result of the change: • Success – change worked as planned • Failed – change failed, customer impacted • Rolled back – change failed, rolled back without customer impact |
|
| Post-implementation review | Comments on the CAB’s review of the change, including any lessons learned or opportunities for improvement |