Change Request Process: Steps, Template and Impact Analysis
Short answer
A change request process turns any proposed change to agreed scope into a written request, has the delivery team assess effort, cost, schedule and risk, and lets a named person approve, reject or defer it. Work starts only after approval. That keeps every budget or deadline shift traceable to a decision someone made deliberately.
“Could we just add a field for the VAT number?” Every project hears sentences like that, often in a corridor or as a meeting wraps up. On its own, harmless. One field, an hour, no problem. Twenty such requests later the budget is 15 percent over and nobody can say when it happened.
A change request process isn’t red tape. It’s the only way to explain afterwards why a project cost more than planned.
Why the contract has to cover changes
Many clients assume they can simply order changes. Construction contracts often do give the client a right to instruct variations, with a mechanism for valuing them. Software development agreements frequently don’t. Without such a clause, changing agreed scope usually needs both parties to agree. The vendor can decline, or quote a price you won’t accept.
So the procedure belongs in the contract before the first change shows up. Fixed-price and time-and-materials deals handle this differently, as covered in fixed price vs time and materials.
Sample contract clause
The clause doesn’t need to be complicated. This wording covers the essentials and can be adapted:
Either party may propose changes to the agreed scope in writing using the change request form. Within five working days the supplier will provide an assessment of effort, fees, schedule impact and risks. Assessments requiring up to half a day of effort are free of charge. No change will be implemented until approved in writing by the client’s named representative. Until a decision is made, the supplier continues work on the agreed scope.
The final sentence matters more than it looks. Without it, one open request can stall the whole project while everyone wonders whether to build the old version or the new one. Whether assessments are billable also causes surprising friction, so settle it up front.
The process in six steps
- CaptureThe requester describes the change and the reason on the form.
- ClassifyThe project lead checks: clarification within scope, or a genuine change?
- AssessThe delivery team estimates effort, cost, schedule impact and risk, usually within five working days.
- DecideThe named approver or board approves, rejects or defers.
- RecordThe decision goes into the change log; plan and budget are updated.
- DeliverOnly now does work begin, with its own acceptance criteria.
Step two often gets skipped, yet it sets the tone for the whole project. Not every question is a change. If the requirements document says “export as CSV” and the delimiter is undefined, settling it is part of the job. If someone suddenly wants a formatted Excel export as well, that’s a change request.
Template: the change request form
The form can be short. These fields cover most projects:
| Field | Content |
|---|---|
| Number and date | CR-014, 12 March |
| Requested by | Name, role |
| Description | What should change, in two to four sentences |
| Reason | Why, and what happens if we don’t |
| Affected requirements | IDs from the spec or backlog |
| Priority | Must, should, could |
| Effort (from supplier) | Range in person-days |
| Cost | Range in currency |
| Schedule impact | Moves milestone X by Y days, or none |
| Risks and dependencies | Testing, data migration, training |
| Alternative | A cheaper option, if one exists |
| Decision | Approved, rejected or deferred, with date and signature |
“Alternative” is the most valuable field. Many requests can be met for a fraction of the effort once somebody asks.
Impact analysis, worked through
Say sales wants Apple Pay added to the customer portal alongside card payments. The supplier assesses it:
- Payment provider configuration and domain verification
- 2 to 4 days
- Checkout and receipt changes
- 2 to 3 days
- Testing on devices, failure cases
- 2 to 3 days
- Total effort
- 6 to 10 days
- Cost
- $4,800 to $8,000
Day rate of $800 assumed. Ranges come from the supplier's three-point estimate.
Then the schedule: without extra people, the pilot slips by about a week and a half. With that information the business can decide. Maybe Apple Pay matters enough. Maybe release two is soon enough. Maybe a feature classified as a could under MoSCoW prioritization drops out to make room.
Without an assessment the decision would have been made in the corridor: “Sure, we’ll do it.”
Small changes without bureaucracy
If every trivial tweak needs a formal request, people route around the process. A small-change allowance works well. For instance, the product owner may approve changes under one person-day directly, as long as the running total stays within an agreed pool, say 5 percent of budget. Anything larger goes through the full procedure.
Track the pool visibly. Once it’s used up, even the smallest change needs a regular request.
The change log as an early-warning system
Log every request, including rejected ones: number, title, effort, decision, date. That list is more than paperwork. It reveals patterns.
Lots of requests from one department mean its needs were under-represented in the spec. Requests spiking after every demo mean users see the software too late. And when approved changes reach 20 percent of the original budget, you’re effectively running a different project and should replan. Quietly growing scope is one of the classic reasons why software projects fail.
Agile and change requests aren’t opposites
Agile teams welcome change. That doesn’t alter the arithmetic. With a fixed budget, each new story pushes another one out. The formal request turns into a backlog trade-off: what comes in, what goes out, who decided?
Teams that document those trade-offs reach acceptance with a clear picture of what was supposed to ship. Teams that don’t end up arguing about a scope nobody can reconstruct.
If you’re setting up a project with an external partner, raise the change procedure in the first conversation. Studios such as OnlineBuilders treat the question of how new requirements are handled as part of project preparation.
Next step: start a sheet today with columns for number, title, effort, decision and date, and back-fill every change from the last four weeks. The total will probably surprise you.
Questions people ask
Is every change a change request?
No. Clarifying details within agreed scope is normal project work. It becomes a change request when scope, quality, schedule or budget would move compared with the contract.
Can a client force a vendor to implement changes?
Generally not without agreement, unless the contract gives the client a right to order variations. Construction contracts often include such rights; software contracts frequently don't, which is why the procedure belongs in the agreement.
What is a change control board?
A small group with authority to approve changes, typically the sponsor, the product owner and the delivery lead. Smaller projects can give that authority to a single named person with budget responsibility.
How do agile teams handle change requests?
Change is expected and goes into the backlog. With a fixed budget the same logic applies, though: every new item displaces another. The formal request becomes a documented trade-off by the product owner.
