How to create a Change Request Form from scratch and in practice

The Change Management process is one of the most important processes in IT, especially in the infrastructure area where substantial changes frequently occur. Therefore, it is essential that you know how to create a Change Request Form (CRF).

But making changes is not easy. That is why the Change Request form, or CRF, is a fundamental tool to ensure that a change occurs in a healthy way within your organization.

Without a good form, it becomes impossible to consult past changes, who approved them, who was affected, and who requested them. In addition, we cannot say what was actually done, what went wrong, what went well, and what was reversed. Without a good form, we do not share the responsibility of the change with the team, registering potential impacts and the action plan.

The CRF form is the heart of changes. That’s why today we are going to learn how to build it.

Example of CRF Form

First Step: Identifying the Change

For each change, there must be a form.

Not only that, but according to good management practices, opening a Change Request (CR) is mandatory for any minor change made to any item in the service catalog.

Thus, our first step here will be to identify the change we will make.

To do this, we will build a form as an example so that you can develop your own. The form can be very simple, very complex, or somewhere in between. Here, we will create a form that is in this middle ground.

I suggest that you start with a simple form and then make it more complex according to the needs of your business and organization. Starting with a simple form helps to gain buy-in from employees and not scare them with a long and tiring process.

That being said, let’s move on to the first field of our form:

Change Identifier

The identifier (ID) helps to control changes, store them in an organized manner, and easily locate them if necessary. Try to standardize the ID: a number, date, and/or location can be interesting ways to help with form organization.

Title or Description of the Change

Here, we will describe what change will be made. In addition to this field, for location purposes, you can also include a standardized name for the change, similar to the function of the identifier.

Who is requesting this change?

Every change fulfills one of the following functions: improve something or solve a problem. 

Therefore, it is important here to describe the person responsible for the affected service, the service owner. 

The service owner is the person responsible for a specific service in the organization, according to ITIL. This person can be a manager, a business area employee, or even an IT analyst, but it is important that they are identified in your form. 

In addition to who the requester is, you can also include their department and other contact information, such as phone or email.

Why is this change being made?

What is the justification for this change? Perhaps, at this moment, everyone involved knows the justification, but in the future, for consultation and understanding of what was done, this information may come in handy.

When are we going to make this change?

Include the expected date for the change to be made.

When was the CRF issued?

Include the date your CRF is being issued.

How long do we estimate for this change to be made?

Include the estimated time for the change.

Be careful with the estimated time. Consider preparation time, execution, testing, validation, approval, contingency plan, etc. The actual time may be very different from what we imagine the change activity will be.

If necessary, this item can be expanded into several estimates, which in some cases may be substantial, worth your consideration:

Over time, as problems arise in the production environment, the need for new fields in the CRF like these will naturally arise. As mentioned at the beginning, start with a simple form and gradually make it more complex.

Who will be involved in the change?

Several people can be involved in various ways in the change that will be made. Consider including them in the CRF:

Remember: the CRF has various statuses – approved, canceled, successful, etc. We will not define them here, but it is important that your organization defines what each of these statuses means. Think about the following question: what defines a successful change and an unsuccessful one?

Should it be done in contingency? (Optional)

The form should be a tool that encourages filling it out, not forces it.

Thus, it is interesting to think about ways to enable the person filling it out to find important needs and characteristics of the change that had not been previously thought of.

An example is: should this change be made in the contingency server?

This leads to several other possibilities for filling out the form:

What is the impact?

To define the impact – large, medium, critical, etc. – it is fundamental that we have a deep understanding of our business.

What is the category?

Your change can be categorized in many ways, but remember: the more categories and different impact definitions, the more people can get lost and even make mistakes when filling out the CRF. 

Never use the category “others” because it may end up facilitating many changes being assigned to that category when they would be better allocated to others.

Which services will be impacted by this change?

The change on the same server can simultaneously affect accounting services, payroll, logistics system, etc. It may be interesting to think about which services will be impacted.

Urgency

Based on the category and impact, a specific urgency can be defined for that change.

Warranty and evaluation period

The warranty period and the post-change evaluation period serve to provide a window of time for the change to be evaluated and guaranteed after it has been made and delivered.

Step Two: What will be done in the change?

Now, we will move on to the technical part. We will describe what will actually be done in the change. This phase may include preparation, the change itself, return processes, Plan B, and remediation.

What will be done in the preparation?

This can be used for future reference even in the case, for example, of needing to understand the process that was previously done to replicate it in the future.

If the process goes wrong at some stage and needs to return to the preparation phase, how will this be done? This is an optional possibility, but it is interesting to consider it:

How will the change be made?

Describe step by step.

Do not forget to describe what will be done, this is very important. This description can help with future consultation, understanding what was done by other stakeholders, and even improving the process being performed.

If something goes wrong, what do I do to return to the original state?

In addition, think and DESCRIBE a Plan B, C, D, etc.:

If everything goes wrong, what will we do?

In case all of the above has gone wrong, describe a remediation plan:

In the worst case, maybe the only way out is to send your CV to another company… (Just kidding!)

Step Three: Approval

A good CRF form shares the responsibility between those who will execute and those who will approve this change. Thus, if something goes wrong, it was not only your decision to move forward with that change, making the CRF a much healthier procedure than making a change alone, without a record and without approval.

Approval is mandatory!

Never give up on approval before making a change, even if it is not through an CRF form. At least ask a superior, no matter how urgent the change is.

In emergency changes, everyone should be aware of the impact that the changes will or may have on the environment.

If an CRF is made, describe what you will do and execute what is described!

The idea of CRF is that the change is WELL PLANNED.

Success is not about approaching change in any way, dealing with the unexpected and solving problems, but rather describing a good plan and following it as described.

If a problem occurs, responsibility is shared by those who saw and approved the change.

Who will approve the CRF?

There may be more than one person responsible for approval, especially when several people will be impacted by the change.

Consider including other information such as the department and contact of who will approve.

RACI

Consider introducing RACI when setting up your CRF. RACI is an acronym that stands for Responsible, Accountable, Consulted, and Informed.

Change Evaluation

Describe everything that was done, what went as planned, what DID NOT go as planned, problems, etc. And don’t be afraid to describe failures!

Conclusion

In summary, when setting up your first CRF, start with something simple and gradually add to it as needed by your organization, practices, and processes.

Focus on flexibility, build a form that encourages its completion and execution of more changes, not a form that bureaucratizes and hinders this process. CRF can also be a great way to make employees think about the execution and potential impact of the change to be made.

In addition, the form is essential for sharing responsibility for changes, as approval of requests requires other employees to be aware of what is being done, making the change process much healthier.

And remember, the CRF form is meant to help, think of it as a tool you have to facilitate the recording and how things are done, not an obligation that hinders processes!