Writing a scope of work that prevents scope creep
Most scope creep is not the client's fault — it's a vague SOW that left both sides assuming different things. Here's how to write one that holds up.
A scope of work (SOW) is the document that turns a friendly project conversation into a definition both sides can point at when something feels off. Skip it, and three weeks in someone is doing unpaid work while someone else is wondering why the "obvious" feature isn't done. A good SOW takes an hour to write and saves weeks of awkward email.
The five sections every SOW needs
- Project summary — one paragraph, in plain language.
- Deliverables — the specific artifacts you will hand over.
- Assumptions — what has to be true for the timeline to hold.
- Exclusions — what is explicitly not in scope.
- Change-order process — what happens when scope shifts.
Deliverables: specific enough to point at
"Website redesign" is not a deliverable. "A Figma file containing desktop and mobile designs for the home page, the product page, and the checkout flow, including two rounds of revisions" is a deliverable. The test: could a stranger reading the SOW tell whether the work is done? If not, tighten it. Numbered lists make sign-off conversations dramatically shorter.
Assumptions: where the timeline really lives
Most missed deadlines come from broken assumptions, not slow work. Spell them out: "Client provides final copy by day 5", "Brand assets are available in vector format", "Stakeholder feedback consolidated into a single document per round". When an assumption fails, the timeline shifts — and because it was written down, that shift is a fact, not a fight.
Exclusions: the polite but firm boundary
Listing what you are not doing feels weirdly aggressive the first few times. Do it anyway. "This SOW does not include copywriting, photography, or post-launch maintenance" prevents the slow-motion conversation where a client assumes those were included because you never said otherwise. You can always add them via a change order at your standard rate.
The change-order clause
New requests are not scope creep — they're a normal part of any project. What turns them into scope creep is doing them for free. A simple clause solves this: "Requests outside the deliverables above will be quoted as a change order with separate pricing and timeline. Work begins after written approval." Send the change order, get the email back, then start. No drama, no resentment.
Payment terms belong here too
Bury payment terms in the SOW alongside the work definition. A common, fair structure for project work is 50% on signature, 50% on delivery — or for longer engagements, milestone payments tied to specific deliverables. Reference your standard invoice terms (net 14, late fee, accepted payment methods) so the contract and the invoice agree.
Signatures: make them easy
An SOW that requires printing, signing, scanning, and emailing back will sit in a Downloads folder for a week. A PDF with an inline e-signature field gets returned the same day. AetherSign's signature blocks drop straight into an SOW PDF — no account required on the client side, which is usually the actual friction point.
Keep the SOW boring
A great SOW is short, dull, and specific. Save the polish and the personality for the proposal cover letter. The SOW is the document you both want to be able to read in 18 months and immediately understand what was agreed.