Freddy AI for CX
Effortlessly deliver great customer experiences with Freddy AI.
Leverage a flexible, end-to-end, AI-powered enterprise platform to unify customer experiences
Change request best practices to help your business win
Change requests are a fundamental tool within change management, which itself is one of the most important processes in IT service management (ITSM). This is because everyone makes changes regularly. Change requests provide a standardized approach when asking for change to be made, supporting effective and consistent review and approval, and assisting with the management of risk. Therefore, it is vital that every organization gives detailed consideration to how they intend to use change requests.
In ITSM a change is defined as the addition, modification, or removal of anything that could have an effect on IT services. Change management is the process responsible for managing and controlling the lifecycle of all changes. This includes requesting changes.
The scope of change requests includes changes to IT applications, networks, servers, desktops, laptops, tools, architectures, processes, organizational structures, and operating instructions. The change management process includes requesting a change, and the recording, reviewing and approving of the change request.
A change request is a formal request for a change to be made. The change request includes details of the proposed change. A change request is also known as a request for change or an RFC. Any request for change can be recorded on paper or digitally.
It is important to understand the difference between a change request and the subsequent change record. A change record is created using information from the change request but is then updated as the change progresses through its lifecycle with additional information.
This is in contrast with the change request, which should not be updated once it has been accepted and a corresponding change record has been created. It is also important to differentiate between the change request and the change itself. It is the change that gets implemented, not the change request or RFC.
There is only one type of change request, however, some organizations use different templates depending on the type of change, and the type of asset affected by the change:
Changes can be emergency, standard, or normal. Each is likely to require a different change request template.
Different types of asset are very likely to require different information in the change request to support its review and assessment. For example, a request to change the configuration of networking equipment assets will probably require the IP and MAC address of the equipment, as these uniquely identify it in the network.
In order to ensure standardization of requests to change networking equipment, they can have their own change request template with these addresses as mandatory entries. In the same way, requests to change process assets could have their own change request template that includes the process name as a mandatory entry.
Change requests provide a formal mechanism to ask for a change to be made and evaluated, and assist with the necessary control over this process. Change requests assist in standardizing the information presented when making the request, which assists in the review and evaluation of the requests. Change requests also help to manage the risks inherent in making changes, by forcing the change requestor to consider the detail of the intended change.
Using change requests ensures that the details of what the requestor wants are recorded in a consistent way. If instead of using change requests, requestors ask individuals in IT to do something there is a high risk that the request is forgotten about, or the necessary information required to evaluate the change isn’t available, or is incomplete. This presents a risk to the organization of changes that disrupt the business activities.
Change requests are an important element of the ITIL change management process. ITIL uses the term ‘request for change’ which is usually abbreviated to RFC. RFCs are used in the first stage of the ITIL change management process as a proposal where the requestor provides details of their proposed change.
Once the change request has been created, it is logged by the team in ITSM responsible for change management. The request for change is then reviewed to check that it is complete, and prioritized for business practicality. If incomplete, the change request can be rejected and returned to the requestor, or they can be asked to provide more detail. Once the change request has been accepted, the information in it is used to create a change record, which documents the lifecycle of a single change.
This change record should reference all configuration items that are affected by the change, even if these are not listed in the change request. The change request is then circulated to key stakeholders for evaluation, including an impact assessment. The outcome from the evaluation of the change request is used to determine if the change request is approved. Once approved, the change detailed in the change request can be implemented.
By clicking on "SIGN UP FOR FREE" you agree to our Terms and acknowledge having read our Privacy Notice
The stakeholders for change requests as the same as those for the change management process. The main stakeholders for change requests are:
This is the person who completes the request for change. They are responsible for ensuring that any change request template is completed, including any mandatory fields. They may also be responsible for presenting the change request to the change management process, although this can be done by a related stakeholder known as a ‘change owner’. In many cases the change requestor will also be the change owner.
The change owner is the person who wants the change to happen. The change owner is accountable for the success of the change, even when someone else has created the change request, is managing the change, or is responsible for its implementation. The change owner can also be the change requestor. In some organizations, there is a policy that the team leader has to check and support the change request before it can be submitted for approval. This is a good example of where the change owner and the change requestor are different people. If the change owner is not also the change authority as defined in the change management policy, the change owner is responsible for presenting the change request to the appropriate change authority for approval. This could involve the change owner representing the change request at a Change Advisory Board (CAB) meeting.
The change authority is an important concept for change requests. This is the person or persons with responsibility for approving the change request. In a good implementation of change management this responsibility for approval will vary depending on the type of change, and the detail of the change request, including the risk of the change failing, the impact of any failure, and the system that the change is being applied to. The CAB is just one form of a change authority. The concept of change authorities for approving change requests helps to avoid the idea that only one person, the ‘change manager’, is responsible for approving the requests for change.
A change reviewer is a person with responsibility for reviewing change requests. There can be several different reviewers, each with a different specialism, checking that different items of information in a change request meet the defined requirements.
Change management includes a number of different steps that involve change requests:
The request for change is created by the change requestor using any template that has been defined. The change request provides the information required for reviewing the change, including as a minimum a description, the expected implementation date, and the name of the change owner. The change request can be created on paper or digitally.
The change management team will create a change record in the tools used for change management, using the information provided in the change request. The change request itself is saved as a record.
In some organizations, the change management team or the change manager perform an initial assessment of the change request to verify that all required information has been provided, carry out a quality check, and assign a priority. If any information is missing or of insufficient quality then the change request is rejected and returned to the change requester.
The change request is evaluated using the rules in the change management policy to determine who should be the change authority for this particular change request.
Depending on the outcome of the evaluation, the change request may need to be circulated to the change reviewers identified in the change management policy so that they can conduct their assessment of the change request. Where the change authority is the change manager, they can conduct the assessment of the change request by themselves.
The change authority will either approve or reject the change request after considering the outcomes of any assessments, any clashes with other changes, and the information presented in the change request.
Many change requests are closed as soon as the change has been implemented. If a change fails, then before the change request can be closed a review should be carried out to identify any improvements required.
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:
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.
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.
This is the date that the change request has been submitted into the change management process.
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.
The individual who is making the change request.
The change owner if this is different from the change requestor.
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.
This provides an indication of the urgency of the change request to assist with subsequent scheduling.
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.
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.
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.
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.
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.
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.
Provide a summary of the resources required to implement the requested change, to assist with evaluation and scheduling.
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.
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.
The common mistakes with change requests can be easily avoided if sufficient care and time are given to the design of the change requests and how they interact with the change management process. Some of the more common mistakes with change requests are:
In many organizations change management is seen as bureaucratic, requiring a lot of paperwork to make any change request. Focusing on just the change management process and not its intended purpose will harm the business, ITSM, and rest of IT. The change management process and the change requests must be designed from the perspective of the change requestors so that it is easy and quick for them to request a change. However, at the same time, the change requests must be designed from the perspective of the change reviewers, change owners, and other stakeholders, so that it is easy and quick for them to review and evaluate the change requests. The aim should be to build trust between the change requestors and the change reviewers. This will help to reduce the level of detail required in the change request, making it less time consuming to complete and review them.
Sometimes organizations pick change reviewers who do not have sufficient skills or knowledge to review change requests. In an attempt to seem helpful, these reviewers can frustrate the change management process by asking questions about the change requests that are not relevant to the change, or which have already been considered and addressed in the change request.
Anyone who could create a change request needs to be made aware of the expected contents and required level of detail. It is a good idea to create a document that explains how to complete a change request.
A common mistake is to continue using the same change request templates for many years without any review. The change request templates should be reviewed regularly, and after any failed change, to ensure that the contents are still appropriate and relevant.
If formal change requests are not used then the review and assessment of requests to make any changes will be difficult, as there will be no consistency in the information required to make an informed decision. Without formal change requests, it is more likely that changes will fail, disrupting the organization and damaging the reputation of IT. Informal approaches risk information being lost or omitted, further increasing the likelihood of failed changes. Auditing for compliance with corporate and legislative requirements will be difficult without the existence of formal change requests.
Change & Release Management – It’s Complicated!
Back to Basics – ITIL Change Management Process
How To Effectively Manage Change With Project Management
Change Management for Cloud Services – Why release notes are more important than ever
Start your 21-day free trial. No credit card required. No strings attached.
Sorry, our deep-dive didn’t help. Please try a different search term.