Why most SOWs leak scope (and the five clauses that stop it)

A few years ago I lost about $18k on a project I should've made $40k on. The client wasn't trying to screw me — they were lovely, actually — but the SOW I'd written was a soft target. Every time they asked for 'just one quick thing,' I said yes because I liked them and because the doc didn't give me a polite way to say no.

Three weeks in, I was redesigning their onboarding flow. That wasn't in the contract. Neither were the four extra stakeholder interviews. Or the second round of brand exploration. By week six I was working evenings and resenting people I liked.

I've written probably 200 SOWs since then. The ones that finish on budget all have the same five things in them. The ones that don't, don't. It's that consistent.

1. Deliverables as nouns, not verbs

'We will support the migration' — that's a verb. Support how? For how long? Support what?

Compare: 'Migration runbook (PDF, max 30 pages, one revision round included).' That's a noun. You can hand it over. You can point to it and say done.

Clients can't sign off on verbs. They can sign off on nouns. Make every deliverable a noun.

2. An explicit out-of-scope list

Most SOWs list what's included. Almost none list what isn't. Three to five bullets is plenty.

It's uncomfortable to write — you feel like you're being negative, or like you're poking the bear. Write it anyway. It forces the conversation now, when it costs you a five-minute email, instead of in week six, when it costs you a weekend.

My standard ones now look like: 'Does not include user research beyond the listed sessions. Does not include copywriting. Does not include support for stakeholders not named above.' Boring. Effective.

3. A change-request mechanism that's actually used

Write one paragraph. Call it the CR process. Reference it whenever the scope wobbles.

I've got a sentence I use constantly: 'Happy to do that — let's run it through the CR process so we keep your invoice predictable.' It sounds friendly because it is friendly. The word 'predictable' does the work. Nobody wants an unpredictable invoice.

4. Acceptance criteria per deliverable

Without these, 'done' is whatever the client feels on the day. With them, done is a checklist. Two or three measurable criteria per deliverable is enough.

Don't get cute. 'Renders in Chrome, Safari, Firefox on current and prior major versions' is fine. 'Delights the user' is not.

5. A payment schedule tied to milestones, not dates

Date-based invoicing punishes you for client delays. The client takes three weeks to give you assets, and somehow that's still your cash-flow problem. No.

Milestone-based invoicing aligns incentives. The client wants to unblock you because their next milestone unblocks their next deliverable. Suddenly the asset review takes three days instead of three weeks.

"A scope-tight SOW is a love letter to your future self at 4 PM on a Friday in week seven."

None of this is hard. It's just unglamorous. The reason most SOWs leak scope is that writing a tight one feels like overkill on the day you draft it — and like the only thing standing between you and a refund six weeks later.

PenSow's SOW template bakes all five of these in by default. I helped write it. The point isn't to skip the thinking — it's to skip the formatting so you can do the thinking.