Sample Change Request Form: Real example for project managers

Changes are an important part of any project. At the same time, the Change Request Form is a must-have tool for any project manager. In this article, we share sample real-world fields and data for compiling your change request form. You can use the sample form literally or make your modifications at the bottom.

Change Request Form Example

The form is a unified scheme for providing the necessary information for change management, grouped by important elements, named so that they can briefly refer to the content. Reference:


The name is very important because usually the projects that each company implements are more than one.

Date of submission

the date of drawing up the Request

Date of acceptance

the date of acceptance of the Request

The date is everything when it comes to completing a task on time. However, the date may be the date of preparation of the “Request for Change” as well as the date of “Acceptance of the Request for Change”. The two dates may differ, especially if the company wants such documents to be received on paper. And more likely if a meeting is convened between the two dates to discuss details. But the deadlines for the contractor run from the date of adoption.

Requesting party

Name of the applicant company because more than one company is working on a project and requests for change may be bilateral, both from contracting authority to contractor and from contractor to contracting authority.

Request number

The number will be placed in the company “Applicant”. It is important in itself because the greater the number of change requests, the more it can be agreed to increase the cost of the project or the payment of each request to be valued separately. The contract for the assignment of the project may provide for every 10 requests for change to increase the implementation period.

Description of the change

Both when assigning a project and when requesting a change, the details are important, if the description is accurate and clear, implementation will be able to start immediately, without requiring additional workshops to clarify needs.

Description of the reason

A very important part of the Request for Change, because if an additional payment is agreed, establishing the reason for the change would be a criterion at whose expense the task is performed. Reference:


The alternative is the possibility to fulfill a request in an easier or faster way or why not in both criteria. The description is not an easy task, but it is important because, as a written document, “The change request” can be the subject of a dispute, and disputes are resolved based on provable facts. Of course, this is the final option for the relationship between client and contractor in a project, but adverse situations must always be anticipated.
So, when describing the alternatives, both the contracting authority and the contractor have the opportunity to look at the solution to the problem that caused the change from another angle, because among the alternatives there may be an easier or faster way to achieve the desired result.

Description of the technical changes and technologies required to implement the change:

When it comes to making a machine, technology is a key component. If the project is for shooting an ad, this field can be left blank.

Description of the possible risk

In principle, changes are required for improvement, but when not all risks are taken into account or, as in the field above, alternatives are not envisaged, the desired result may not be achieved.

In the first place is the risk of delay. It can be agreed that with n number of requests for changes the deadline for completion of the project is extended, and this is good for the contractor, the competition in the market is the one that with the faster product grabs a larger share of the market.

In the second place is the risk of the lack of a specialist who will be able to satisfy the change request. To be able to attract subcontractors in a project, but if it is in an area where the company has no contacts, it may not be able to find a contractor.

The third is the risk of complicating the functionality of the product, that the innovations with which it is further developed will become unusable.

Specify a priority or criticality level

The Change Management Plan will specify and unify scales and classifications to ensure that both parties use the same language, understand each other, and adjust their expectations. A scale is required to fill in this field. It may include the following levels:
1. Highest priority – this category includes requests for changes to the main characteristics of the assigned product. Impose changes in already existing sub-projects. They require extra time, people, and skills on their own and external resources.
2. High priority – this category includes changes that are important and require changes in existing projects, but can only be implemented with their resources of time, people, and skills.
3. Important priority – this category includes amendments for which an additional sub-project with the commitment of an external resource must be described.
4. Less important priority – this category includes amendments for which an additional sub-project must be developed but can be implemented with their own resources
5. Simple priority – this category includes changes that will be implemented in the course of the project, with the commitment of additional resources
6. Insignificant – this category includes changes of the type clarifications, which will be implemented in the course of the project, without requiring additional resources of time, people, and skills

Estimated costs and resources needed to implement the change:

As can be seen from the “priority” scale, it is more likely that additional resources will have to be engaged, and they will cost money. The contracting authority gives its forecast, and then the contractor in the section “Reasons for the opinion” agrees with this forecast or offers a price for the resource that satisfies him.

Impact on the project

The consequences are the changes that will be formed in the Annex to the contract because they affect the initially agreed.


In the opinion, the project contractor must express his opinion on each of the specified fields in the form “Request for change”.
And end with the choice of one of the given answers “approved”, “rejected” or “postponed”
Approved request
Request denied

Reasons for the answer

The reasons for taking the opinion are the “trump cards” in negotiating “how to get things done”, and the client and the contractor aim to get a product so that they can generate revenue.

Approving Party / Name

The approval must include all project managers in the program whose activities will be affected by the change.

Date and Signature

Read more

Cost management plan in project management practices,

Procurement Management Plan in Project Management Practices,

Applying control in project management,

Two factors ensure the generation of requests for change

Two factors ensure the generation of requests for change: the changes that occur in the market to which the project is directed, and a vague understanding of the project’s goals and objectives. Successful projects are flexible enough to respond to these incentives.

It is easier to avoid requests for changes that result from a lack of understanding by stakeholders about the goals and objectives of the project. Clear communication about the overall goals and objectives of the project will put the project on a solid footing.

How to complete the project on time

Here are some tips on how to do this and complete the project on time.

Making the project public

Change requests are like small business cases and must contain the elements that the business project contains. Reference:

The element we are interested in here is the expected benefit of the change. Request a change resulting from making the change, such as making the online purchase process easier, making the product more attractive to the target demographic, or changing the workflow change feature. Requesting a change can add more value to a project. This type of change request must proceed to the next step in the change management process.

Requests for changes may not explicitly describe the benefits they bring. The implied benefit to the organization or project may be hidden in the technical description of the requested change. The change management process must provide contact information to the applicant in the change request and all applicants must be ready to answer questions about their requests. Visit, call or email the applicant and ask them to explain the business case in more detail. Ask them leading questions such as “What new market demand will this change cause?”, “How will this change save project time?”, Or “How much money will this project change save?” Avoid asking questions like “Will this change improve the system?” ”, Or“ How will this change improve? ”. These questions will provide an opportunity to discuss why their solution is better than originally defined.


If you need to avoid wasting time preparing requests for changes that are not beneficial to the organization or project, you can do so as follows. Clearly state the goals and objectives of the project, in the business case and the working opinion. Clarity on the purpose of the project is your first step towards avoiding unnecessary requests for change. Make sure that the goals and objectives of the project are clearly and simply stated.

Make sure you use the best practices that the project management offers to collect and verify the requirements of your project. You start with a clear, concise set of project goals and objectives and thus fulfill the first criterion for collecting requirements. The next step is to involve the appropriate stakeholders to implement the set requirements. The right stakeholders are those who will use the system, those who are customers or customers of the system, those who own the system, those who are responsible for the customer market, or those who own systems that need to interact with the new/changed system.

The requirements must also be clear, concise, and unambiguous so that they can be interpreted in the specifications governing what is built. The requirements should be checked – what will the product look like when the requirement is met? How will the system react? The next step in getting the requirements is to sign the right people to the requirements. Simply put, the right people are the ones who own or are responsible for the business units to which the stakeholders belong. They can delegate the decision to a subordinate, but they must delegate only one subordinate, not the entire team.

The last step in capturing the project requirements is to communicate the approved, signed requirements to the project stakeholders. The requirements will be covered in some form of a business requirements document or commercial specification. Make sure it’s in readable form, inform stakeholders about its location, communicate your expectations for reading it and make sure it’s available to all stakeholders.

You need to act as a screening so that valuable project resources are not wasted by analyzing and evaluating applications that have no hope of acceptance.

Your change management plan should provide the ability to reject change requests that are not supported by a business case before the evaluation step. The person responsible for managing the project change must be the project manager or one of the project team who has assigned this role.

Feel free to reject a change that you have deemed not a business case to support.

It is important when dealing with a change request, regarding a business case not specified in the application, to be prepared and flexible in this case, after all, your goal is not to eliminate the requests for changes, but simply to eliminate those who have no business case.

By Samantha Rhine

Samantha Rhine, Editor-in-Chief of