Scope creep, and the variation process that prevents it

Scope creep is rarely a single dramatic demand. It is a sequence of small, reasonable requests, each of which would be petty to refuse, which together turn an eight-week project into a five-month one nobody is happy with.

The pattern is recognisable once you have seen it. The quote covers eight pages. During design, a ninth page seems obviously necessary. The contact form should probably email two people rather than one, and store submissions somewhere, and send an automatic acknowledgement. The client’s photographer runs late so the designer sources placeholder images, and then sources better placeholders, and then edits the real photographs when they arrive. Someone mentions that the site should really have a blog. Every one of those is defensible. None was quoted.

Why scope creep damages both sides

For the supplier, unquoted work is margin removed from a fixed fee, and the compensation is usually taken from somewhere the client cannot see: less testing, less attention to the pages nobody discussed, a rushed launch. Projects that overrun also collide with the next client’s start date, which spreads the damage sideways.

For the client, the costs are slower delivery, work performed under time pressure, and a supplier who begins keeping score. The relationship changes character. Requests that were once answered in an afternoon start being met with hesitation, and neither party can quite say when the goodwill ran out. Disputes about final invoices almost always have an uncontrolled scope somewhere in their history.

The thing to notice is that both parties usually behave well throughout. Scope creep is not a symptom of a bad client or a bad supplier. It is what happens when a project has no mechanism for saying yes to a change on the record.

What a project scope change-control process looks like

A variation process is not bureaucracy. It is the mechanism that lets you change your mind without either side absorbing the change silently — the same function a change control process serves in any project management discipline, scaled down to the size of a website build.

The request is written down. An email is sufficient. What is being asked for, and why.

The supplier responds with impact, not just price. The fee for the additional work, stated exclusive or inclusive of GST consistently with the original quote, plus the effect on the delivery date and on anything already scheduled. Time impact is the part most often omitted and the part that causes the most friction.

You approve in writing before work starts. Not after. A variation performed on a verbal nod and invoiced later is the second most common source of end-of-project disagreement.

The project schedule is formally revised. If the launch date moves, it moves in the document, not in conversation.

A running log is kept. One list of every variation, its fee and its date impact, visible to both parties throughout. This single artefact prevents most disputes, because nobody arrives at the final invoice surprised. On a project with more than one decision-maker on the client side, naming which stakeholders can actually approve a variation avoids a second, quieter form of scope creep — different stakeholders each adding their own small request without seeing what the others have already approved.

Small items can be handled with a threshold: changes under an agreed size are absorbed, anything above triggers the process. That keeps the mechanism from being invoked for a swapped photograph. Either way, the deliverables list agreed at the start of the project — the page list, the project objectives it was meant to satisfy, and what was explicitly excluded — is the document every variation gets checked against.

Legitimate scope change, or under-scoping

Not every variation notice is fair. Some are a supplier recovering a quote that was too thin to win the work honestly. There is a test that separates the two, and it is not about the size of the request.

Ask whether the item is something a competent supplier would have known was required to deliver what was quoted. A contact form that actually sends email is not an extra on a quote that included a contact form. A site that works on a phone is not an extra in a market where most visitors arrive on one. The ability to edit your own content is not an extra where the proposal said you could update it yourself. Basic search-engine essentials — page titles, a sitemap, indexable pages — are not an extra on a website build. Items like these are completion of the original scope, and being charged for them is being charged twice.

Genuine variations look different. They are things you asked for that were not there before, or things that changed because your business changed, or things nobody could have known at quoting time because the information did not exist yet.

Two warning signs are worth naming. A quote materially below every other quote you received, attached to a scope description too vague to argue with, frequently reprices itself through variations later. And a supplier who declines to put the scope in writing at all has removed the only instrument by which under-scoping could ever be demonstrated.

The defence against both is the same and it happens before the project starts: a written scope specific enough that a variation is obvious to both parties the moment one is proposed. A page list with names. What each page contains. What functionality exists and what it does. What content you supply and by when. What is explicitly excluded. Writing that down is unpleasant work for an afternoon and it is the reason some projects finish on time. What belongs in the surrounding agreement — variations, delays, payment stages and termination — is set out on web design contracts in Australia.