Also called: SOW, scope of work
Statement of Work (SOW): what to check
A statement of work (SOW) is the document that defines the actual deliverables, timeline, and price for a project, often sitting under a broader master service agreement. It is the single most important document for avoiding scope creep, because everything not written in it is, by default, either an argument or free work.
A good SOW is specific and boring. A dangerous one is short and vague, leaving 'what counts as done' to interpretation.
What to check
Deliverables defined precisely
Exactly what you will hand over, in what format, and what 'complete' means. Vague deliverables are the root of most project disputes.
Revision rounds capped
How many rounds of changes are included, and that anything beyond them, or outside the defined scope, is a billed change request.
See unlimited revisions benchmarks →Milestones and payment schedule
Payment tied to defined milestones, with a deposit up front, rather than one lump sum at the end after all the work is done.
See deposit benchmarks →Change-request process
A written path for handling new requests: how they are scoped, priced, and approved, so 'one more small thing' does not become unpaid work.
Red flags
- Deliverables described in a sentence or two, with no definition of 'done'.
- No revision cap, or 'revisions until satisfied'.
- Payment only on final completion, with no deposit or milestones.
- No change-request process, so every addition is an argument.
Got one of these in your inbox? Paste it into the free scanner and see which of these red flags is actually in yours.
Check a contract freeNo signup. Not a substitute for a lawyer.