Writing a scope that survives the project
Most statements of work describe what will be done. The useful half is what will not be.
A scope document exists to answer one question, months later, under mild disagreement: was this included? A document that lists deliverables answers it only for the things somebody thought of at the start.
Write the exclusions
This is the single highest-value section and the one most often missing, because writing it feels negative during a hopeful early conversation. For another example of formal workplace documentation, this page shows how a write-up form is typically structured.
Content writing, image sourcing, hosting setup, training, ongoing maintenance, browser support beyond a stated list, third-party licence costs, data migration from an unknown format — each of these has been assumed included by a client somewhere, entirely reasonably, because nobody said otherwise.
Every excluded item is something the client can now budget for or ask you to quote. Discovering it mid-project is worse for them than reading it in the proposal.
State what the client has to supply, and when
Most delays in client work are client-side: content, approvals, access, decisions, sign-off. A scope that commits you to a delivery date without committing them to inputs is a scope where all the risk is yours. For a broader framework, PMI's overview of project management summarises the standard concepts behind planning and delivery.
List the inputs, the dates they are needed, and — importantly — what happens if they are late. Not as a penalty, but as a stated consequence: the timeline moves by the same number of days, and the slot may not be immediately available.
Count the rounds
Revision is where fixed-price projects are lost. 'Two rounds of consolidated feedback' is a scope; 'until you are happy' is an open commitment.
Consolidated is the important word. Five people sending separate contradictory comments is not one round, and saying so in advance is much easier than saying it in month two. For a broader role perspective, PMI's overview of project-manager responsibilities outlines common project-management responsibilities.
Define done
For each deliverable, what state constitutes complete: delivered in what format, tested against what, approved by whom, within what period after which approval is assumed.
That last clause matters more than it looks. Projects hang for months waiting on sign-off from someone who has moved on to other things, and without a deemed-acceptance clause the work is neither finished nor billable.
Keep it readable
A scope nobody reads protects nobody. Two or three pages in plain language beats fifteen pages of clauses that the client's decision-maker skimmed.
The test is whether the person who will actually be reviewing your work could read it in five minutes and know what they are getting. If it needs a lawyer to interpret, it will not be used as a working document, which is what it is for.