2 August 2026 · 7 min read
How to stop scope creep eating your margin
On fixed-price work, every unbilled change is pure margin loss. The fix is not tougher negotiation — it is four process gates that make scope visible.
For a software services business, scope creep is not an inconvenience. It is the difference between a profitable account and one you are subsidising. On fixed-price work, every unbilled change comes directly out of margin. On time-and-materials, it comes out of the client relationship instead, which costs more in the long run.
The usual response is to negotiate harder. That rarely works, because by the time you are negotiating, the work has often already been done. The fix is structural: make scope changes visible at the moment they occur, rather than at invoice time.
Why scope creep is mostly invisible
Very little scope creep arrives as a formal request for something large. It arrives as a series of small, reasonable-sounding adjustments, each too minor to be worth a difficult conversation.
- "Could we also handle the case where the user has two accounts?"
- "This should probably send a confirmation email too."
- "Can we make the export configurable while we are in there?"
Individually each is an hour. Collectively they are a fortnight, and nobody made a decision to spend it. Worse, the person who agreed to each one — usually a developer being helpful on a call — had no visibility into the cumulative total or the commercial impact.
The four gates
1. A signed-off scope baseline
You cannot detect a change without a baseline. That means a written specification, explicitly signed off, that both sides can point at. If your baseline is a proposal document written before discovery, you do not really have one.
This is the gate most firms skip, and it makes the other three impossible.
2. A single channel for change
Scope changes should not be agreeable in a hallway, a Slack thread, or a call with a developer. One route, one owner. This is not bureaucracy — it is what makes the cumulative total visible to someone accountable for the commercials.
The practical version: developers are empowered to say "that sounds reasonable, let me route it through the change process" rather than being put on the spot to agree or refuse.
3. Everything gets estimated, including the small things
The instinct is to wave through anything under a day. That instinct is exactly what makes scope creep invisible, because scope creep is made of things under a day.
Estimate everything, and keep a running total the client can see. The conversation changes completely when it moves from "can you just add this?" to "this is the ninth addition and takes us eleven days past baseline."
4. Explicit accept-or-defer decisions
Every change gets a decision: accept and adjust price or date, or defer to a later phase. What it must not get is silent absorption.
Deferring is the underused option. Most changes are genuinely reasonable and genuinely not urgent. A visible "phase two" list lets you say yes to the idea while saying not now to the cost.
The commercial conversation this enables
| Without gates | With gates |
|---|---|
| Change discovered at invoicing | Change priced when requested |
| Client feels surprised and overcharged | Client chose the cost knowingly |
| Firm absorbs the overrun or has a difficult call | Overrun is billable or was explicitly deferred |
| Delivery date slips with no explanation | Date moves visibly, with a stated cause |
The second column is not just better for margin. It is better for the relationship, because the client is making informed decisions rather than receiving surprises.
Where the leak usually starts
Almost always at requirements. When the original specification is ambiguous, every ambiguity becomes a change request — and an argument about whether it was in scope. Firms with a rework problem generally do not have a discipline problem downstream. They have a specification problem upstream.
Which is worth knowing before you invest in change-control process: if the baseline is vague, tighter gates will produce more disputes, not less. Fix the specification first.