Change Requests: Handling Scope Creep Without Conflict
By CodexierPublished 5 min read
Every web or software project changes shape as it goes, because the client sees the real thing and understands it better than the brief. That is healthy. What turns it into conflict is when the changes are invisible: the supplier absorbs a few, resents the rest, and the final invoice or the missed deadline lands as a surprise. A change-request routine makes each change visible, priced and decided, and it takes five minutes per change.
Why scope creeps
Scope creeps for three reasons that have nothing to do with anyone behaving badly. The brief was written before the client had seen anything, so it described a guess. Stakeholders who were not in the kickoff arrive at the first review with their own requirements. And small requests feel free to ask for and awkward to charge for, so they accumulate silently until the supplier is out of hours. Understanding this changes the tone: a change request is not an accusation, it is bookkeeping.
Defining scope clearly
You cannot manage changes to something that was never fixed. The scope has to be concrete enough that both sides can point at it and say whether a request is inside or outside.
- List the deliverables: which pages, which features, which integrations, which languages, with a sentence of acceptance criteria for each.
- List what is explicitly excluded, especially things that were discussed and dropped; those are the first to creep back.
- State the number of revision rounds included per deliverable and what a round means.
- State who on the client side may approve changes, so requests from a colleague do not become work by default.
For a fixed-price package such as our company website launch, this list is the package description itself, which is one reason fixed prices reduce conflict: the scope is public before anyone signs.
A change-request log
The log is a shared document, a spreadsheet or a board, that both sides can see at any time. Each request gets one line. The format matters less than the discipline that every request goes in, including the ones the supplier decides to do for free.
| Column | What goes in it | Why |
|---|---|---|
| Number and date | Sequential, with who asked | Makes the request referable in every later conversation |
| Description | One or two sentences of what is wanted and why | The why often reveals a cheaper way to meet the need |
| Estimate | Hours or cost, and the effect on the deadline | The client decides with real numbers |
| Decision | Approved, declined or deferred, by whom, on what date | Nobody later remembers a verbal yes |
| Status | Not started, in progress, done, verified | Shows the client what their approvals have become |
A request the supplier absorbs at no cost still goes in the log with a zero estimate. It documents goodwill and it shows the pattern if small freebies pile up.
Estimating and approving changes
Estimates for changes should be quick and honest rather than precise. A same-day answer in the form of a range, with the schedule effect stated plainly, is what lets the client decide while the request is still fresh. Bundle small requests into a weekly batch so that neither side spends more time on the routine than on the work. Approval must come from the named person, in writing, before work starts; a reply in the log or an email is enough. And be clear about what happens to the deadline: a change approved after the halfway point almost always moves it, and saying so at approval time avoids the argument at delivery time.
For a fixed-price project, the change is a separate small order with its own price; for an hourly project, it is an adjustment to the budget. Either way, the client sees the running total of approved changes at every review. Our own payment terms for changes are described in our guide on deposits and payment terms.
Saying later instead of no
Most change requests are good ideas at the wrong time. Declining them creates friction; absorbing them creates overruns. The third answer is to defer: put the request in a phase-two list with its estimate, deliver the agreed scope on the agreed date, and then review the list with fresh eyes. Half of it will no longer seem necessary once the site or system is live, and the other half becomes a clean, priced second project instead of a stretched first one. This is also the honest answer to a client who asks whether they should add features now: usually not; launch first, then decide from real use. A free call before a project starts is where we set this routine up, and package prices are on the pricing page.
Frequently asked questions
Is a change-request routine not too bureaucratic for a small project?
A shared spreadsheet with five columns is the whole routine, and each entry takes minutes. Small projects suffer most from scope creep because they have the least slack, so the routine matters more there, not less.
What if the supplier claims something obvious is a change?
Go back to the scope list and the acceptance criteria. If the item is implied by a deliverable, such as a form that actually sends email, it is in scope. If the list is silent, it is a genuine gap, and the fair outcome is usually to share the cost. A clear scope at the start prevents most of these.
Can changes be free?
Yes, and good suppliers absorb small ones. Log them anyway with a zero estimate. The log then shows both the goodwill given and the point at which small changes have become a real cost that needs discussing.
Starting a project and want the change routine in place from day one?
Bring your brief or the quote you have received. In fifteen minutes we can check whether the scope is defined well enough to manage changes, and show you the log we use on every project.
Book a free 15-minute call