Change Request Form: Every Field Explained, With a Completed Example

Quick answer: A change request form is the document someone fills in to formally ask for a change to an approved project. It records what the change is, why it’s wanted, what it will cost in money and time, and who decided. Without it, changes happen quietly and the project quietly breaks.

Every project gets change requests. The question is whether they go through a door or a window.

A good form is the door. It takes ten minutes to fill in, it makes the cost visible before anyone commits, and it leaves a record of who said yes.

This guide explains every field, gives you the template, and — the part most guides skip — shows a completed form with real numbers, so you can see what good entries actually look like.

What Is a Change Request Form?

A change request form is a short document used to ask for a change to something that has already been agreed.

It does four jobs:

1. Captures the ask in words everyone can read later
2. Forces the cost to the surface before anyone starts work
3. Routes it to the right person to say yes or no
4. Creates a record of what was decided and why

That third job is the one people underestimate. Most damage from uncontrolled change isn’t the change itself — it’s that nobody with authority ever saw it.

Change request vs change order

These are two stages of the same thing, and mixing them up causes real confusion.

	Change request	Change order
What it is	A proposal to change something	The instruction to go ahead
When	Before the decision	After approval
Who writes it	Anyone affected	Usually the project manager or contracts team
Binding?	No	Yes — often a contract variation
Can be rejected	Yes	No, it’s already decided

The order is always: request → assess → decide → order.

If someone hands you a “change order” with no request behind it, something has been skipped.

When Do You Actually Need a Change Request?

This is the question people really have, and almost no guide answers it.

The test is simple: has the thing you’re changing already been approved and baselined?

Situation	Needs a form?
Fixing a bug in work you’re still building	No. That’s just doing the work
Changing a requirement the client signed off	Yes
Adding a feature nobody asked for at the start	Yes
Correcting a typo in an approved document	No. Log it as an administrative change
Swapping a supplier named in the contract	Yes
Reordering tasks in your own schedule, same dates	No
Moving a milestone date	Yes
Spending money you already had approved	No
Spending more than was approved	Yes

The one-line rule

If someone outside your team would be surprised to learn about it, it needs a form.

That catches almost everything that matters and excludes the day-to-day work that doesn’t.

What if you’re not sure?

Raise the form. A rejected request costs ten minutes. An unapproved change discovered at handover costs considerably more.

How your organisation sets these boundaries belongs in your configuration management plan, which defines what’s under control and who approves changes to it.

What Are the Four Types of Change Request?

Type	What it is	Approval route
Standard	A pre-approved, routine change you’ve agreed in advance	No decision needed — just log it
Minor	Affects a baselined item, but not scope, cost or the end date	Project manager, plus one reviewer
Major	Affects scope, cost, the deadline, or a contract	Full change control board, plus sponsor
Emergency	Needed immediately to prevent harm or a serious failure	Two named people can approve on the spot, with retrospective review

Standard changes are the useful category people forget. If you pre-agree that certain routine changes don’t need a decision, your board stops drowning in trivia and starts spending its time on the ones that matter.

Emergency changes need a route defined in advance. If you don’t write one down, people will invent one under pressure — and it won’t include a record.

What Fields Should a Change Request Form Include?

Around 15 to 20 fields, in five groups. More than that and people stop filling it in.

Group 1: Identification

Field	What to write
Change request number	A unique reference, e.g. CR-014
Project name	The project, not the department
Raised by	A named person, plus their role
Date raised	The date, not “this week”
Contact details	So the assessor can ask questions

Group 2: The change itself

Field	What to write
Title	One line someone can scan. “Add loyalty points at checkout”
Description	What exactly changes. Be specific enough that two people would build the same thing
Reason	Why it’s wanted. The business reason, not “the client asked”
Type	Standard, minor, major or emergency
Priority	See the scale below — not a guess
Date needed by	And say whether that’s a hard deadline or a preference

Group 3: Impact

Field	What to write
Items affected	Which deliverables, documents or WBS codes change
Effort	Days of work, by role
Cost	The money, with your workings shown
Schedule impact	Days added, and whether it touches the critical path
Quality and testing	What needs retesting, and by whom
New risks	What this change makes more likely to go wrong
Cost of not changing	Often the most important field. See below
Alternatives	What else was considered, and why this option

Group 4: The decision

Field	What to write
Assessed by	Who did the impact assessment, and when
Decision	Approved, rejected, deferred, or more information needed
Conditions	Any strings attached to an approval
Reason for the decision	Especially important for a rejection
Decided by	Named approver, with the date
Signature	Or a recorded digital approval

Group 5: Afterwards

Field	What to write
Change log reference	Where it’s recorded
Documents to update	Scope statement, schedule, budget, specs
Implemented by and when	Closing the loop

The field most often missing from real forms is “reason for the decision.” Without it, the same rejected request reappears in three months and nobody can remember why it was turned down.

What Goes in the Change Request Form Template?

Copy this.

CHANGE REQUEST FORM

CR number:                      Date raised:
Project:
Raised by:                      Role:
Contact:

1. THE CHANGE
Title:
Description:
   [What exactly changes. Specific enough that two people would
   build the same thing.]
Reason / business case:
Type:      ☐ Standard   ☐ Minor   ☐ Major   ☐ Emergency
Priority:  ☐ Critical   ☐ High    ☐ Medium  ☐ Low
Date needed by:                 Hard deadline?  ☐ Yes  ☐ No

2. IMPACT ASSESSMENT                 Assessed by:          Date:
Items affected (deliverables / documents / WBS codes):

Effort:        ____ days   Breakdown by role:
Cost:          £______     Workings:
Schedule:      ____ days added    Touches critical path?  ☐ Yes  ☐ No
               New end date if approved:
Quality:       Retesting required:
Risks created:
Dependencies:  What else must change as a result:

Cost of NOT making this change:
Alternatives considered:
Recommendation:

3. FUNDING
Source:  ☐ Contingency reserve  ☐ New budget  ☐ Absorbed in plan
Reserve before:  £______   Cost:  £______   Reserve after:  £______

4. DECISION
Decision:  ☐ Approved  ☐ Approved with conditions  ☐ Rejected
           ☐ Deferred  ☐ More information needed
Conditions:
Reason for decision:
Decided by:                     Role:              Date:
Signature:

5. AFTER APPROVAL
Logged in change log:  ☐      Reference:
Documents to update:
Implemented by:                 Date completed:

How Do You Set a Priority?

Most forms say “circle high, medium or low” and never define them. So everyone circles high, and priority stops meaning anything.

Define the scale with a response time attached:

Priority	When to use it	Decision needed within
Critical	Work has stopped, or there’s a legal, safety or security requirement	1 working day
High	Affects the go-live date, a contractual commitment, or a dependent project	3 working days
Medium	Improves the outcome, but the project can proceed meanwhile	Next scheduled board meeting
Low	Would be nice. No impact if it waits	Batched for review at the next phase gate

The response time is what makes the scale real. “Critical” means someone has to look at it tomorrow. Once that’s true, people stop marking everything critical.

One more rule: the requester proposes the priority; the assessor confirms it. Otherwise the loudest requester sets the queue.

How Do You Assess the Impact?

Both competing guides have fields for cost and duration, and neither says how to work them out. Here’s a method that takes about twenty minutes.

Six questions, in order

1. What has to change? List every deliverable, document and task affected. If you use a work breakdown structure, list the codes. This list drives everything else.

2. How much effort? Estimate in days, by role. Ask the people who’d do the work, not the person who wants the change.

3. What does it cost? Effort × day rate, plus any new purchases, licences or subcontractor costs. Show your workings on the form so the approver can check them.

4. Does it touch the critical path? This decides whether the project moves. Work affecting a task with float may cost money without costing time. Work on the critical path costs both.

5. What needs retesting? A change to one part can invalidate testing of another. Name the test cases and who re-runs them. This is routinely forgotten and routinely expensive.

6. What new risks does it create? Add them to your risk register with owners. A change that introduces a new high risk may not be worth it even if the direct cost looks small.

Two rules for assessment

The person who wants the change doesn’t assess it. Not because anyone is dishonest, but because optimism is involuntary.

Assess before you decide, always. An approval given before the assessment is a commitment to an unknown number.

What About the Cost of Not Changing?

This field sits on most templates and is almost never explained. It’s the most underrated question on the whole form.

Every change request has two costs: doing it, and not doing it.

Change	Cost of doing it	Cost of not doing it
Add a security fix	5 days, £4,000	A vulnerability shipping to production
Add a requested feature	18 days, £14,400	Same work next year, with rework on top
Change supplier	10 days, £8,000	Continued late deliveries
Improve a screen’s design	6 days, £4,800	Nothing. It works fine

Look at the last row. If the cost of not changing is “nothing,” you’ve found a change you should reject — however much someone wants it.

Three ways to express it

• Deferred cost. “Doing this in phase 2 would cost £19,000 because of rework, against £14,400 now.”
• Opportunity cost. “Marketing expects this to raise repeat purchases. Without it, that benefit doesn’t arrive.”
• Risk cost. “Without this, we carry a compliance risk into go-live.”

Be honest when the answer is “no real cost.” A form that always justifies the change isn’t an assessment — it’s advocacy.

What Does a Completed Change Request Example Look Like?

Here’s a filled change request example with numbers that reconcile.

Project: E-commerce replatform · Budget £210,000 · Go-live 4 February

1. The change

Field	Entry
CR number	CR-014
Date raised	12 October 2026
Raised by	Sana R., Marketing Director
Title	Add loyalty points redemption at checkout
Description	Allow customers to apply existing loyalty points as a discount during checkout. Points balance shown at basket and checkout. Partial redemption allowed. Excludes earning rules, which are unchanged.
Reason	Loyalty members can earn points but not spend them online. Support receives regular complaints about this, and it was always intended for a later phase.
Type	Major — affects scope and the go-live date
Priority	High — affects the go-live date
Date needed by	At launch. Hard deadline: no

2. Impact assessment

Assessed by Tomas B., Technical Lead · 14 October 2026

Field	Entry
Items affected	Checkout module, basket module, payment reconciliation, 2 design documents
Effort	18 developer days (14 build, 4 integration)
Cost	£14,400 — 18 days × £800/day. No new licences
Schedule	+11 working days, on the critical path. New go-live: 19 February
Quality	12 new test cases. Full payment regression re-run — 2 days of QA, included above
Risks created	Payment reconciliation becomes more complex. New medium risk, owner: Tomas B.
Dependencies	Loyalty provider API rate limits need confirming before build starts
Cost of not changing	Delivering in phase 2 is estimated at £19,000 because the checkout would be rebuilt. Doing it now saves £4,600
Alternatives	(a) Defer to phase 2 — costs £4,600 more. (b) Show balance only, no redemption — 4 days, £3,200, but doesn’t solve the complaint
Recommendation	Approve. The saving is real and the complaint is recurring

3. Funding

Line	Amount
Project budget	£210,000
Spent to date	£138,000
Contingency reserve before	£18,000
Cost of this change	£14,400
Contingency reserve after	£3,600

4. Decision

Field	Entry
Decision	Approved with conditions
Conditions	(1) Go-live moves to 19 February, communicated to all stakeholders by 20 October. (2) Loyalty provider API limits confirmed in writing before build starts. (3) No further scope changes funded from contingency without board approval, as the reserve is now low
Reason	The £4,600 saving and the recurring customer complaint justify it. The date move is acceptable because no external commitment depends on 4 February
Decided by	Daniel K., Sponsor · 16 October 2026

What to notice about this example

The reserve is nearly gone, and the decision says so. £3,600 left on a project with four months to run is tight. Condition 3 exists because of that. A form that recorded the cost without recording the consequence would have hidden the real problem.

The cost of not changing made the case. £19,000 later versus £14,400 now is the strongest argument on the page, and it’s the field most forms leave blank.

One alternative was cheaper and got rejected anyway. Option (b) cost £3,200 and didn’t solve the problem. Cheaper isn’t the same as better, and writing the alternatives down is what makes that visible.

The date moved. Honestly, in writing, with a communication deadline attached.

Who Approves a Change Request?

Agree this before the project starts, not when the first request lands.

Change size	Who approves	Typical turnaround
Standard (pre-agreed)	Nobody — log it	Immediate
Under £5,000, no date impact	Project manager	2 working days
£5,000–£25,000, or a date change	Project manager plus sponsor	Next board meeting
Over £25,000, or a contract change	Sponsor plus finance, sometimes the client	Within 2 weeks
Emergency	Two named people, acting immediately	Same day, reviewed retrospectively

Adjust the thresholds to your project size. What matters is that they exist and that everyone knows them.

Name a deputy for every approver. Change requests don’t wait for holidays.

The membership and cadence of your change control board belongs in your configuration management plan.

What Happens If a Change Request Is Rejected or Deferred?

No guide covers this, and it’s half of all outcomes.

If it’s rejected

• Write down why. One sentence. This is what stops the request returning in three months.
• Tell the requester personally, not just by updating a status field.
• Keep the form. Rejected requests are evidence that you controlled scope, which matters at closure and in audits.
• Explain the trade-off, not the policy. “This would add 11 days and we have no float” lands better than “it’s out of scope.”

If it’s deferred

• Say what it’s deferred to — phase 2, a named date, or a review point. “Deferred” with no destination means forgotten.
• Record it in the backlog for whatever comes next, or it will vanish.
• Re-estimate when it comes back. A six-month-old estimate is fiction.

If more information is needed

Say exactly what’s missing, who should provide it, and by when. “More info needed” without those three things stalls indefinitely.

A note on saying no

Rejecting changes is part of the job, and doing it well protects relationships rather than damaging them. The pattern that works: acknowledge the value, state the cost plainly, offer the alternative.

“This would genuinely help, and I can see why you want it. It’s 11 days and £14,400, and we’d have to move go-live. If we do it in phase 2 instead, we keep the date — shall I put it at the top of that list?”

How Do You Number Change Requests?

Both competing templates have a “change request number” field. Neither suggests a scheme. Here’s one:

CR-001, CR-002, CR-003 ...

Sequential, per project, three digits. Four rules:

1. Number on receipt, not on approval. Rejected requests keep their numbers. The gaps in your approved list are part of the record.
2. Never reuse a number. If a request is withdrawn, the number retires with it.
3. Use the number everywhere. In the schedule, the budget, the change log, the status report, the meeting minutes.
4. Prefix by project on multi-project programmes. ECOM-CR-014 beats two CR-014s in the same inbox.

That third rule is where the value is. When a status report says “go-live moved because of CR-014,” anyone can find the reasoning.

What Is a Change Log, and What Goes in It?

The change log is the running list of every request raised, whatever happened to it. One row per request.

Column	Example
CR number	CR-014
Title	Add loyalty points redemption
Raised by	Sana R.
Date raised	12 Oct 2026
Type	Major
Priority	High
Cost	£14,400
Days added	11
Status	Approved with conditions
Decided by	Daniel K.
Date decided	16 Oct 2026
Documents updated	Scope, schedule, budget, 2 design docs

Why the log matters more than the forms

The individual forms tell you about one change. The log tells you about the project.

Fourteen requests in four months, nine approved, £41,000 drawn from a £60,000 reserve — that pattern tells a sponsor something no single form can. It’s also the first thing anyone will ask for at project closure.

Three rules: one log per project, update it the same day a decision is made, and show the running total of approved cost and days.

What Are the 8 Most Common Change Request Mistakes?

1. No threshold for when a form is needed. So either everything needs one, or nothing does.
2. Approving before assessing. A yes given before the numbers is a blank cheque.
3. The requester assessing their own change. Optimism isn’t dishonesty, but it’s still wrong.
4. An undefined priority scale. Everything becomes high.
5. Leaving “cost of not changing” blank. It’s the field that decides borderline cases.
6. No reason recorded for rejections. The same request comes back forever.
7. Forgetting to update the documents. An approved change that never reaches the scope statement will be a dispute later.
8. Funding changes from contingency without saying how much is left. The example above shows how close this gets to the edge.

What Software Handles Change Request Forms Best?

Three jobs, three kinds of tool.

Job	What to look for	Type of tool
Collecting requests	A form anyone can submit without a licence, with required fields	Form tools, or the request feature in a project platform
Routing and approving	Workflow states, named approvers, notifications, an audit trail	Project management platforms, or a service desk tool
The change log	Sortable table, running totals, export	Spreadsheets, or a database view in your project tool

Four features that matter more than the brand:

• An audit trail nobody can edit. If approvals can be quietly changed, the record proves nothing.
• Required fields. A form that lets people skip the impact section will be skipped.
• A link to the affected items. The request should connect to the tasks and documents it changes.
• Export. Someone will want the change log in a spreadsheet at closure.

One caution: a form tool doesn’t give you a change request process. Decide your thresholds, approvers and priority scale first. Automating an undefined process just makes the confusion faster.

How Does Writegenic AI Fit In?

Change requests generate a steady stream of short, structured writing — and usually under time pressure, because someone is waiting for an answer.

Writegenic AI can help you:

• Turn a rough request — an email, a message, a note from a meeting — into a properly worded change request
• Write the description so two people would build the same thing
• Draft the impact assessment narrative from your numbers
• Write the rejection in language that keeps the relationship intact
• Summarise the change log into a paragraph for your status report or closure report
• Draft the stakeholder note when an approved change moves a date

It sits alongside the rest of the documents: the project scope, the scope management plan, the configuration management plan that defines the process, and the closure report where the change log ends up.

Explore AI for project management or use the prompt generator for sharper instructions.

Draft with the tool, keep the judgement. AI can make a change request read clearly in a minute. It cannot estimate 18 days of work, know whether your reserve can absorb £14,400, or decide whether moving go-live is acceptable. Those numbers come from the people doing the work, and the decision belongs to whoever is accountable for the budget.

Try Writegenic AI free

Frequently Asked Questions

Related reading:

• What Is Configuration Management Plan: Template + Example
• Creating a Scope Management Plan: A Step-by-Step Guide
• Contingency Plan in Project Management: Template + Example
• How to Write a Project Scope Using AI
• Project Closure: Checklist + Closure Report Template