Scoping client work so it does not drift

Deliverables, not activities

The most common scoping mistake is describing effort instead of output. Design phase, discovery, development sprint and stakeholder alignment are all activities. None of them can be completed in a way that is externally verifiable, which means none of them can be approved and none of them can be argued about productively.

A deliverable is a thing that exists at the end. Not design phase, but: responsive page designs for the five templates listed below, delivered as a shared design file, covering desktop and mobile breakpoints, with one round of revisions included.

The second version is longer, and that length is the entire value. Every clause in it is a boundary that would otherwise have been an assumption, and assumptions are where the fortnight goes.

Write acceptance criteria that could settle a disagreement

Acceptance criteria are a description of the state of the world when a milestone is done, specific enough that two people who disagree could read them and reach the same conclusion.

The useful test is adversarial: imagine the relationship has gone badly and both sides are reading the criteria closely, looking for support. Criteria that say the design should look modern and professional collapse instantly. Criteria that name the templates, the breakpoints, the file format and the number of revision rounds hold up.

You are not writing them because you expect a dispute. You are writing them because criteria that would survive a dispute are also criteria that prevent one, and because the act of writing them forces you to discover the ambiguity now, while it is still free to resolve.

• What artefact exists at the end, in what format, delivered where.
• What is explicitly excluded, especially adjacent things a reasonable person might assume.
• How many revision rounds are included, and what a round means.
• What the client must provide, by when, for the date to hold.
• Who has authority to approve it. Naming one person is the highest-value clause in most statements of work.

Exclusions are the cheapest insurance you can buy

Nobody enjoys writing exclusions. They read as defensive and they make a document feel adversarial at exactly the moment you are trying to build goodwill. Write them anyway, because the alternative is a conversation about the same subject later, when there is money attached and less warmth available.

You do not need a legalistic list of everything in the universe you are not doing. You need the small number of things a reasonable client might genuinely assume were included: content writing, data migration, third-party licence costs, ongoing maintenance, training, accessibility remediation, browser support beyond a named set.

Framing matters more than length. Not included in this phase, available as a separate scope reads very differently from a bare refusal, and it converts more of those requests into paid work rather than into friction.

Name a single approver

The most damaging structural gap in client work is not vague scope. It is a project where three people each behave as though they have final say, so a deliverable approved by one is reopened by another, and each cycle burns days you did not price.

Fix it in the statement of work by naming the individual whose approval concludes a milestone. Other stakeholders can review and comment; one person decides. If the client cannot name that individual, you have learned something important about the engagement before you have committed to it.

When approval genuinely requires a committee, price that. A milestone reviewed by a steering group takes longer and returns more contradictory feedback than one reviewed by a single accountable person, and that difference is a real cost that belongs in the estimate rather than in your evenings.

Define what a revision round is

Two rounds of revisions included is one of the most common clauses in professional services and one of the least defined. Without a definition, a round can mean one consolidated set of feedback or eleven separate emails over three weeks, and the difference in cost is enormous.

Define it concretely: a round is one consolidated set of feedback delivered within a stated window, addressed together. Feedback arriving after that window, or contradicting feedback already actioned, starts a new round.

This is not pedantry. Drip-fed feedback is more expensive than the same volume delivered at once, because every context switch has a cost and every partial revision risks being undone by the next note. Defining the round pushes the client towards consolidating, which is better for both sides.

Make change requests boring and routine

If handling an out-of-scope request requires a difficult conversation, people will avoid the conversation and absorb the work. So the mechanism has to be so routine that using it carries no social cost.

That means a change request is a normal artefact, not an escalation: a short description, an estimate, a price and a date impact, sent for approval the same way anything else is. No negotiation about whether it counts, because the acceptance criteria already answered that.

Teams that adopt this consistently report the same surprise. Clients approve most change requests. What they object to is being surprised by an invoice, or being told no with no route forward. A priced option is neither of those things.

Close the loop with your own history

Scoping accuracy compounds if you measure it. Log estimated against actual effort at task level, then look at the ratio by project type rather than by individual project. Individual projects are noisy; categories are informative.

After a handful of engagements you will find stable patterns — that a certain kind of integration work reliably runs at one and a half times your estimate, or that a particular client's review cycles take three times as long as anyone else's. Both facts are worth money the moment you know them, because you can price them.

This is the difference between estimating from optimism and estimating from evidence, and it is available to any team willing to record two numbers per task.