UDEHA
Operations

Scope document

The written record of what a project includes, excludes and depends on — the reference that makes a later disagreement checkable.

A scope document states what a piece of work covers: the deliverables, the number of revisions, the dates, what the client has to provide, and — the section most people omit — what is explicitly not included.

The exclusions carry the value. Everything a client assumes is included is included, in their mind, until something written says otherwise, and the assumptions are always reasonable ones you simply did not share. Naming five exclusions in one paragraph prevents most of a year's friction, and it does it before anyone is annoyed, which is the only time the conversation is cheap.

The second underused section is dependencies. Most overruns are not caused by the work being harder; they are caused by an input arriving three weeks late. Writing "if content is not supplied by the 14th, delivery moves week for week" makes a client delay a client cost rather than an argument about your reliability.

Worked: a project quoted at 40 hours ships in 62. Reconstructed afterwards, 14 of the extra hours were three rounds of revision beyond the two discussed and 8 were waiting on a logo file. Both were preventable by two sentences written before the start, and neither is arguable after it.

Also known as

  • statement of work
  • SOW
  • brief

Relevant for

Creators
Write the number of revisions and the date content is due; "a few tweaks" is unlimited until something says otherwise, and it always arrives on a busy week.
Business owners
The exclusions and the dependencies are the document — write them before anyone is annoyed, because that is the only point at which the conversation is cheap.

Read more in the Library