Stop scope creep before it becomes a disagreement
A change request is easier to handle when there is already a shared process.
Confirm whether it is a correction or addition. Price and schedule the impact.
Create a baseline
At the start, record the deliverables, assumptions, and completion criteria in a shared document. Include the number of revision rounds if relevant. A baseline does not eliminate change; it gives both sides a concrete way to tell whether a request changes the agreed work.
Separate clarification from added work
A correction to meet the agreed deliverable is different from an added page or feature. Ask what the request changes in labor, materials, dependencies, and timing. Avoid automatically calling every client comment an extra, but do not silently accept substantial new work either.
Offer a clear choice
Describe the requested change, its price impact, and its schedule impact before starting. Offer to replace a lower-priority item when that is practical. Document the client’s decision in the agreed approval channel so the team has one version of the scope.
Learn from repeat requests
If the same extra appears in nearly every project, it may belong in your standard package or discovery questions. Update future proposals. Better scoping is often more useful than winning a debate at the end of a difficult job.
A request for an extra page
Illustrative example—not a reported client result.
| Input or decision | Illustrative application |
|---|---|
| Original scope | Five approved service pages |
| New request | A sixth service page after scope approval |
| Impact | Additional copy, layout, review, and testing |
| Decision | Add a priced change or replace another agreed item |
Separate a correction from a new request
Illustrative working example, not a reported client result.
A client approves a contact page, then asks for a multi-step application with file uploads. Calling this “a small form change” hides the actual work: new fields, storage, validation, security considerations, error states, and testing. Compare the request with the approved function rather than its description. Fixing a broken existing submit button is a correction; adding an application workflow is a scope decision.
A neutral change note avoids turning the conversation into blame. Describe the request, what it adds, the work it displaces, and the revised price or timeline. Offer a smaller alternative when appropriate. Do not begin the extra work until the decision is recorded, unless your agreement already defines a specific allowance that covers it.
| Checkpoint | Working record |
|---|---|
| Original commitment | A basic contact form with a confirmation message. |
| New request | A multi-step application with uploaded documents. |
| Impact | Additional interface, storage, validation, and testing work. |
| Decision | Approve an added scope, trade out another deliverable, or defer it. |
Not every change deserves an additional invoice. The important distinction is whether the request changes the agreed work or asks you to meet an existing commitment.
What if I have already started the extra work?
Pause the unapproved portion, explain what is complete and what remains, and agree on the next step. Do not retroactively present an unagreed charge as though it had already been accepted.
Use the related business calculator to test the numerical assumptions where applicable. Record nonfinancial decisions in your action plan.
Put the idea to work.
- Confirm whether it is a correction or addition.
- Price and schedule the impact.
- Record approval before doing extra work.
One more question
What if the change is very small?
Use judgment, but record recurring small additions. Many individually small requests can become a material amount of work.
AI-assisted educational content. Examples are illustrative, not reported client results. Editorial standards.