Change request vs pull request
A change request asks to change what was agreed — the scope, the requirements, sometimes the price and the dates. A pull request asks to change the code. They solve the same problem at different levels, and the change request can learn a lot from the pull request: a visible difference, a review in place, named approvers, and nothing merged until they approve.
Three things called a “change request”
| Where you hear it | What it means |
|---|---|
| Client projects and agencies | A request to change agreed scope or requirements, usually with its cost and dates |
| IT operations (ITIL, ServiceNow) | A request to change a production system, reviewed before it is made |
| Code review | A proposed code change. GitHub and Bitbucket call it a pull request, GitLab a merge request, Gerrit a change; “request changes” is a reviewer’s verdict on one |
This page is about the first meaning — and about what it can borrow from the third.
Change request vs pull request, side by side
| Aspect | Change request (scope) | Pull request (code) |
|---|---|---|
| What it changes | What was agreed: scope, requirements, cost, dates | The files in a repository |
| Who usually proposes it | The client or a stakeholder | A developer, or a coding agent |
| Who decides | The client and the delivery lead | Reviewers in the team |
| What the reviewer sees | A description in an email or a form | A diff: exactly what changes, line by line |
| What approval means | The new scope, cost and dates are agreed | The change may be merged |
| What happens next | Someone updates the spec, the plan and the tickets — by hand | The merge is the update; history keeps both versions |
The last two rows are where client projects go wrong. A pull request cannot merge without its approval, and merging it is the update. A change request is approved in one place and applied — or forgotten — somewhere else.
Scope creep vs change request
Scope creep is change without a decision. A change request is change with one. The work may be identical; what differs is whether anyone saw its cost before saying yes.
client kept adding just one more thing and the team kept saying yes without checking with me first.
— an agency project manager, r/projectmanagement, July 2026
a lot of stakeholders ask for changes casually until they actually see the downstream impact on the team and delivery dates.
— r/projectmanagement, May 2026
The cost is real: “Your company is losing big money without change requests” (r/projectmanagement). Examples, causes and fixes are in scope creep in software projects.
Change request vs change order
A change request is the ask. A change order — the word agencies and contractors use — is the signed amendment that follows: the new scope with its price and dates, added to the contract or statement of work. Many software agencies use the two words for the same thing. What matters is not the name but the order of events: the price is agreed before the work starts, not discovered on the invoice.
The change request process in software development
- Write it down, in the requester’s words. Who asked, what they asked for, and why. A request made on a call is still a request — write it up the same day and send it back.
- Find what it touches. The requirements it changes, the work already built on them, the tests that check them, and the integrations behind them. Small-looking changes are where this matters most: in one r/webdev thread about “quick change” requests, reordering a checkout form would have broken a CRM integration that “mapped fields by position, not name”.
- Size the impact. Scope added or removed, cost, dates, risk, and what has to be redone.
- Decide with the client. Approve, decline or defer — and record who decided and when. Offer a choice where you can: as asked, a smaller version, or a swap for something of equal size.
- Update the agreement. The requirements get a new version; the version signed off before — the baseline — stays readable, unchanged. Plans and tickets follow the new version.
- Build and accept against the new version — not against the email that started it.
Everything else a change has to reach after the decision is in requirements change management.
Skipping the process once teaches the client it is optional:
the moment you establish that you can change what was signed off, then all “quick” changes are fair game
— r/webdev, June 2026
What a change request can borrow from a pull request
- A diff, not a paragraph. Show the requirement as it is and as it would be, side by side.
- Review in place. Let the client comment on the exact line, not on an email about it.
- Named approvers. Say in advance whose approval the change needs.
- Checks before merge. No approval until the list of what it touches is complete.
- Nothing merges until approved. Work on a change does not start from a “sounds good” on a call.
- History. Every approved change leaves the previous version readable, with who approved it.
That is the idea behind Specroot’s own short description of itself: a pull request, for documentation.
How to handle change requests in agile
Agile expects requirements to change, so a change request is not a failure — it is the backlog doing its job. Two things still apply. On a fixed price or a fixed date, every addition is paid for with money, time or something else taken out; make the trade explicit — swap, don’t add. And whatever the contract, the change should land in the requirements the team builds from, not only in the backlog — otherwise the spec and the work drift apart. That gap has a name: spec drift.
Change request template
The template has its own page now, with a filled-in example, a change request log and the email that asks the client for a decision: change request template for software projects.
Where Specroot fits
This is the problem Specroot works on: a change to the requirements kept apart from the signed-off version, showing what it affects, and merged only once the client signs off. Specroot for agencies and consultancies.
Read next
- Scope creep in software projects — Scope creep is work added to a project without a decision about what it costs. Examples from software projects, what causes it, and how to stop it.
- Statement of work template for software development — A free statement of work template for software projects, what a SOW should include, SOW vs scope of work vs MSA, and clauses for acceptance and changes.
- Requirements baseline: what it is, with an example — A requirements baseline is the agreed version of the requirements every later change is measured against. Definition, example, scope baseline, re-baselining.