What should be included in a change request?
Change requests should contain the minimum information required to support the review and approval of the change. The amount of information required in a change request will depend on the maturity of the change management process, and the role and skills of the change reviewers. If the change reviewers are considering the technical feasibility of the change, then the change request must contain sufficient information to enable them to do this. If, however, the change management process is more mature and the reviewers are just checking that the change has the approval of the change owner, then the level of information in the change request will be significantly less.
As a minimum the information in the change request should include:
Unique identifier
It be possible to uniquely identify every change request. A unique identifier is sometimes assigned when the change request is accepted by change management, but this may cause issues as it will be difficult to differentiate between different change requests that are being reviewed or have been rejected. A better approach is to provide each group of change requestors with their own sequence of unique identifiers, usually sequential numbers preceded by a code which identifies the group. A requestor then uses the next available identifier when creating a change request. Many tools provide this feature.
Change request title
This provides a brief description of the change request which is meaningful to all stakeholders. The terminology should be understood by these stakeholders, to assist them with their review and evaluation of the change request.
Date submitted
This is the date that the change request has been submitted into the change management process.
Date and time of the change
This is the date and time when the requestor wants the change to be implemented. This may be subsequently amended in the change record, but the original date requested should remain unaltered in the change record.
Change requestor
The individual who is making the change request.
Change owner
The change owner if this is different from the change requestor.
Service(s) affected
It is important to reference in the change request the services that will be impacted, both positively and negatively, both during and after implementation of the change. Focusing on the services helps to avoid undue attention being given to the specific technology components that are being changed.
Proposed change priority
This provides an indication of the urgency of the change request to assist with subsequent scheduling.
Full description of the requested change
This should include information on which assets are being changed, and a summary of what the changes are. If possible, the change request should include the configuration management identifiers for all assets that are impacted.
Justification for the change
Why the change request has been submitted. This should include the benefits to the organization, any implications of not approving the change request, and any problems that will be resolved by implementing the change.
Outage during implementation
It is good practice to highlight any expected loss of availability to the services during implementation of the change, as this will assist approval and communications about the change.
Implementation time schedule
An outline schedule should be included in the change request, with timings for all activities associated with the change. This should include any preparation time prior to starting implementation, the implementation activities, and post-implementation verification.
Risk analysis
The risk to the business from this change should be analyzed. This should include specific risks to service availability during and after implementation, the probability of experiencing issues, and the impact if the risks become issues.
Stakeholders for the change
Identify the stakeholders that will benefit from the change proposed in the change request, those who have been consulted about the change, and those who should evaluate the change request.
Resource requirements
Provide a summary of the resources required to implement the requested change, to assist with evaluation and scheduling.
Reviews and sign-offs
It is good practice to reference any reviews that have already been carried out of the change request, and any sign-offs for the request that have been given before submitting the request for a change to the change management process. In mature change management most of the evaluation of the proposed change should be done before the change request is submitted for formal approval.
Back-out considerations
The expected time to back-out the change should issues be experienced should be provided in the change request, as this helps to give change reviewers the confidence that the change has been carefully planned. This should include the expected timings to complete any back-out and information on the conditions under which a back-out will be invoked.