How to Handle Scope Changes After a Proposal Is Signed

Price the change the same day, against the milestone structure the client already approved. A scope change handled within a day is a normal commercial conversation. The same change raised three weeks later, after the work is partly done, is a dispute about who absorbed it.

General information, not legal advice. This article covers practical handling of changes to agreed work. How a variation affects a specific contract depends on that contract and on your jurisdiction.

What counts as a scope change?

A scope change is anything that alters what is delivered, how much of it, or when. In practice that is:

• New deliverables that were not in the signed scope.
• More of an existing deliverable, such as ten page designs where the proposal said six.
• Extra revision rounds beyond the number the proposal specified.
• A compressed deadline, which changes the cost of the same work.
• A new stakeholder whose sign-off adds a review cycle nobody priced.

Work that was listed in the scope and simply turned out harder than expected is not a scope change. That is an estimating miss, and it is yours. Keeping that line honest is what makes clients trust the change requests you do raise.

Can you change scope after a proposal is signed?

You can, as long as both sides agree. A signed proposal records what was agreed when it was signed. It does not freeze the relationship, and no reasonable client expects it to.

What matters is that the change is recorded as clearly as the original scope was. The failure mode is not the change itself, it is ending up with a signed document that describes one engagement and a scattered trail of messages describing another. If the scope in force is spread across a proposal, two emails, and a call, then nobody can say precisely what was agreed, which is the same condition that makes an original proposal unenforceable. See is a signed proposal a contract.

How should you price a scope change?

Price it against the milestone structure the client already approved.

This is where most freelancers and agencies lose money, and the usual advice makes it worse. The standard guidance is to quote every change as its own small project. But a standalone quote asks the client to evaluate the number from scratch, with no context, which is exactly the situation in which a number looks large. A change expressed as an adjustment to a phase they already approved is read against a decision they have already made.

So if the original pricing was tied to milestones, say "this adds two days to the build phase, taking that phase from X to Y." If it was a fixed total, say what the new total is and which part moved. The consulting proposal template and software development proposal template both structure pricing this way, which is what makes changes against them straightforward to express.

What should a change request include?

Five things, and the fifth is the one usually missing:

1. What changed, in one sentence.
2. What it affects in the original scope.
3. What it costs, expressed against the existing structure.
4. What it does to the timeline, including any dependency it pushes.
5. What happens if it is declined, meaning what the original plan still delivers.

Without the fifth, a client cannot actually weigh the decision. They are being asked to approve a cost with no stated alternative, and the reasonable response to that is delay. Naming the decline path is also what keeps the request from reading as pressure.

How do you raise one without friction?

Raise it early, in writing, and keep it short. Scope creep is rarely one large request. It accumulates through small additions that were never priced, because raising each one felt disproportionate at the moment it appeared. Six unpriced small additions are a margin problem that arrives at the end of the project, when it is least recoverable and most awkward to discuss.

A same-day note of three sentences does not feel like a confrontation. A four-week-old accumulation raised at invoicing does. The friction people are trying to avoid by staying quiet is created by staying quiet.

If the engagement is ongoing rather than project-based, the same logic belongs in the agreement itself: a monthly retainer agreement that states what a month includes gives you a natural, unembarrassing place to note when a request falls outside it. For project work, a statement of work does the same job.

Start From A Template

Changes are easier to handle when the original document made scope explicit in the first place. Every free proposal template separates deliverables, exclusions, and client dependencies, so there is a written line to point at when something falls outside it. Start with the business proposal template for a general engagement, then keep the agreed position in one document as it changes, rather than across a thread.