Documents · Glossary

What is scope creep?

Scope creep is the gradual expansion of work beyond what was agreed, without a matching change to the price or the timeline. It happens through many small additions rather than one large one, which is why it is noticed late, usually when the budget is spent and the job is not finished.

No single request causes it. A dozen reasonable ones do, each too small to argue about, and the total arrives as a surprise to the supplier and as a normal expectation to the client.

Indunil Asanka · Co-founder

6 min read · Published 12 September 2026

What causes it, and the document that answers each cause
Cause	What it looks like	The document that answers it
Vague scope	Deliverables described as verbs rather than things	A statement of work with defined deliverables and an out of scope list
No change process	Additions agreed in meetings and never priced	A change control clause requiring written pricing before work
Unmeasurable acceptance	Endless revision rounds on the same document	Acceptance criteria and a stated number of revisions
Unstated assumptions	A cost that depends on something nobody wrote down	Named assumptions, specific enough to test
No one tracking the total	Fourteen small favours nobody added up	A change log reviewed at every status meeting
Client side approval gaps	A new stakeholder arriving with new requirements	A named approver, with a deputy, and a governance clause

It is a documentation failure before it is a behaviour problem

The instinct is to blame the client, and it is almost always misplaced. Clients ask for things because they are trying to get a good result, and if nothing in the paperwork tells them a request has a cost, they have no way of knowing that it does. A supplier who says yes to eleven small additions has taught the client that additions are free, and the twelfth is not a cheeky request but a reasonable extrapolation. The fix sits in the documents and in the habit of using them, not in becoming harder to deal with. Suppliers who handle change well are usually easier to work with, because everybody knows where they stand and nobody is quietly resenting anybody.

The out of scope list does more work than the scope

Writing what is included feels complete and never is, because a reader fills the gaps with their own expectations. The exclusion list is what closes them. Naming the things a client might reasonably have assumed, content writing, data migration from a second system, training beyond one session, changes after sign off, third party licence costs, is not defensive. It is the only way a fixed price survives the first month. It also surfaces the disagreement at the right time: a client who reads the exclusions and objects has just told you what they actually wanted, in week one, when it can still be priced into the job rather than absorbed in week nine.

Making the change process small enough to use

A change process that requires a formal variation for a two hour task will be bypassed, and once bypassed for small things it is bypassed for medium ones. Build it in two tiers. Below a stated value, a change can be approved by email between the two named leads, recorded in the log, and invoiced with the next payment. Above it, a written variation priced within a few days, signed before work starts. State plainly that work does not proceed on an unsigned variation, because that sentence is the whole mechanism. Then keep the log visible, since a running total of approved changes shown at each status meeting removes the surprise that causes the awkward conversation.

The language that makes it possible to say yes

Nobody wants to refuse a client, and the good news is that the change process never requires it. The answer to a new request is yes, here is what it costs and what it does to the date, which is a completely different conversation from no. Suppliers who find this hard usually have no priced basis for the answer, so quoting anything feels arbitrary. A rate card and a habit of estimating quickly fix that. Where the request is genuinely small and the relationship matters, absorbing it is a commercial choice worth making occasionally and worth recording in the log anyway, marked as no charge, so the cumulative generosity is visible to whoever reviews the job.

Where the client is right and the supplier is wrong

Not every expansion is creep. If a deliverable does not meet the criteria that were agreed, fixing it is rework, not a change, and charging for it is a good way to lose the client and the argument. If the original estimate was wrong because the supplier misunderstood something they could have asked about, that is the supplier's risk under a fixed price. And if an assumption was written so vaguely that it cannot be shown to have failed, it provides no basis for repricing. Distinguishing these honestly, early, is what makes the change process credible, because a client who has seen a supplier absorb their own mistake will accept a priced variation without suspicion.

Catching it in the first fortnight

Creep is cheap to stop early and expensive later, and the early signs are consistent. Requests arriving through a channel other than the agreed one. A new person joining the client's meetings with opinions about requirements. The word just appearing before requests, as in just add a page. A status report whose completion percentage has not moved for two weeks while the team is busy. Any one of those is worth a short, unalarming conversation and an entry in the log. Raising it in week two sounds like good project management. Raising the same thing in week ten sounds like an excuse for being late, whether or not it is one.

Questions people ask

Is scope creep always the client's fault?

No, and treating it that way prevents the fix. Suppliers cause it by writing vague scope, by not pricing changes, by saying yes reflexively and by failing to track the total. Clients cause it by adding requirements late and by introducing new stakeholders. The documents exist so neither side has to rely on the other's restraint.

How do I raise it without damaging the relationship?

Early, in writing, and framed as information rather than complaint. A short note saying three additional items have been agreed since the start, here they are, here is the effect on the date and the fee, reads as competence. The same note in week ten, when the project is late, reads as an excuse regardless of how fair it is.

Should small changes always be charged?

They should always be recorded, which is different. Charging is a commercial decision that depends on the relationship and the size of the job. What causes harm is absorbing changes silently, because the client never learns there was a cost and the supplier's margin quietly disappears with nobody able to explain where it went.

What is the difference between scope creep and a variation?

A variation is a change that was requested, priced, agreed and documented. Scope creep is the same change without any of those steps. The work is often identical; the difference is entirely in whether a process was followed, which is why creep is best understood as a paperwork failure rather than as a type of work.

Can a contract prevent it completely?

No contract prevents behaviour, but a good one makes the consequences visible, which changes behaviour. Defined deliverables, an exclusion list, acceptance criteria, a two tier change process and a log will stop most of it. The remainder depends on somebody actually using the process during a busy week, which is a management habit rather than a drafting problem.

How does it show up on a time and materials job?

As budget overrun rather than as a margin problem, because the supplier is paid for the extra hours. It still matters: the client runs out of funding before the objective is met, and the relationship suffers even though the invoices were all correct. Time and materials engagements need a forecast and a stop point, not just a rate.

Make one with documents

The button opens the generator with this use case already described. Change the wording to match your own.

Create a document with OneCraft

Sources

Written and checked by the OneCraft team. Last checked 12 September 2026.