Summary

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. 

What is a change?

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. 

What is a 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. 
 

What are the different types of change request?

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:

Types of changes

Changes can be emergency, standard, or normal. Each is likely to require a different change request template.

  • An emergency change is one where the change request requires urgent approval that cannot wait for the normal cycle of the change management process. The information required in a change request for an emergency change is often less than what is required in requests for non-emergency changes. Some organizations allow the written change request to be provided after approval has been given for the change to proceed.
  • A standard change is a low risk and repeatable change that has been successfully implemented many times. It is good practice to use a change request when proposing that a particular change should in future be classified as a standard change, as the change request provides the full detail of what is being proposed. Once this change request has been approved, there is no requirement to raise an RFC for subsequent implementation of this change. In effect, it has been pre-approved.
  • A normal change is a change that requires management but is not a standard or an emergency change, hence a change request should always be raised for this type of change.

Type of asset

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. 

Why are change requests important?

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. 

Where do change requests fit into the ITIL methodology?

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.
 

Who are the stakeholders for change requests?

The stakeholders for change requests as the same as those for the change management process. The main stakeholders for change requests are:

Change requestor

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. 

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. 

Change authority

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. 

Change reviewer

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.

What are the steps for processing change requests?

Change management includes a number of different steps that involve change requests:

Create change request

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.

Record the change

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.

Review change request

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.

Evaluate change

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.  

Assess change

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.

Approve change

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.

Review and close 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.

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.

Common mistakes with change requests and how to avoid them.

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:

Excessive Paperwork

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.

Inappropriate change reviewers

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.

Poor communication

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.

Lack of continual improvement

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.

What are the consequences of not using formal change requests?

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.

Other Related Resources

BLOG

Change & Release Management – It’s Complicated!
BLOG

Back to Basics – ITIL Change Management Process
BLOG

How To Effectively Manage Change With Project Management
BLOG

Change Management for Cloud Services – Why release notes are more important than ever