How to write a statement of work

To write a statement of work, describe the work as results rather than hours: list what is in scope and what is not, name each deliverable with its format, owner, due date and acceptance test, lay out the schedule, set out the fees and what triggers each one, and write down the assumptions and dependencies the price relies on. Sign it under a master agreement that carries the legal terms, or add those terms if there is none.

Scope in and scope out

The scope section lists the activities in the order they happen. The statement of work example, for a fictional analytics firm migrating an insurer’s claims database, numbers five: discovery of the source data, a data mapping specification, migration tooling, a parallel run in a non production environment, and a cutover to production with post migration verification. Each activity is a sentence or two, specific enough that nobody could mistake a proof of concept for a production migration.

Scope out is the half most people skip, and it is where disputes start. Write down what a reasonable client would otherwise assume is included: other systems, training, ongoing support after go live, data cleansing beyond mapping. The example handles this through its assumptions and change control, stating that any work outside the scope in section 2 goes through change control. That works, but a short out of scope list is clearer still. The project charter example shows the stronger form: six things in and four things out as two lists side by side, including the third depot and returns processing.

Describe results, not effort. The US federal acquisition rules on performance work statements put it well: describe the work in terms of the required results rather than how it is to be done or the number of hours to be provided, and make performance measurable. business.gov.au’s contract guide makes the same point with an example of a clear description that states dates, place, numbers and materials instead of a vague promise to train staff.

Deliverables that can be accepted

A deliverable is a thing someone can look at and accept or reject. For each one give:

• Name, such as Data Mapping Specification
• Format, such as a spreadsheet or a code repository
• Owner, the party who produces it
• Due, a week number or date

The example’s deliverables table has five rows: a discovery report as a PDF by the end of week 2, the data mapping specification as a spreadsheet by week 5, the migration toolset in a code repository by week 14, and the parallel run results and final cutover plan as PDFs by week 17. A separate indicative schedule sets out five phases across the 18 weeks, with go live in week 18.

Dates by week number are useful when the start date may move, because the schedule survives a delayed signature. Convert them to calendar dates once the effective date is fixed.

Acceptance

Acceptance is the clause that turns delivered into finished, and it prevents more invoice disputes than any fee clause. It needs a review period, what the reviewer checks against, and what happens on silence.

The example gives the client ten business days from receipt to review each deliverable. If no feedback arrives within that period, the deliverable is deemed accepted. The final migration is accepted on successful cutover and data verification as defined in the cutover plan. The software development agreement example uses the same ten business day window, with criteria written before each sprint starts.

Deemed acceptance protects the supplier from a client who never replies, and the review period protects the client from a rushed sign off. Both sides should be able to live with the number.

Fees and how they are earned

State the pricing model, the rates or prices, the total and the GST position. The example is time and materials: four roles with day rates and estimated days, from a lead consultant at $2,200 a day for 40 days to a project manager at $1,600 a day for 20 days, totalling an estimated $412,000 excluding GST. The rows reconcile: $88,000, $180,000, $112,000 and $32,000.

For a fixed price, replace the rate table with a price and a payment schedule tied to deliverables, so that each payment falls due on acceptance of something. The milestone payment clause shows how that link is usually worded. For time and materials, consider a cap or a point at which the supplier must warn the client that the estimate will be exceeded.

Assumptions and change control

Assumptions are the only part of a statement of work that protects a supplier when a project slips for reasons on the client side. The example lists five: timely access to systems and experts, a stable source schema, the target platform ready by the start of phase 2, the client responsible for user acceptance testing, and anything outside section 2 going through change control.

Each one converts a future delay into a variation rather than an argument. Make them specific. “Client will cooperate” protects nobody; “the target platform is available and configured by the start of phase 2” can be checked on a date.

Change control then says how scope, schedule or budget change. The example requires changes to be agreed in writing through a formal change request, as specified in the master agreement. The note on scope creep describes what happens when this step is skipped.

The sections table

The table at the end of this article lists eleven sections of a statement of work, what each contains, the trap it prevents and how the claims migration example handles it. The guide on when to use an MSA with a SOW explains which terms belong in the master agreement instead, so this guide does not repeat that split.

Common mistakes

Hours instead of results. A statement of work that sells 300 hours gives the client nothing to accept.

No acceptance clock. Without a review period and a rule for silence, a deliverable can sit unaccepted for months.

Vague assumptions. An assumption that cannot be checked on a date will not support a variation.

Legal terms repeated from the master agreement. Two versions of a liability clause create an argument about which one applies; refer to the master agreement instead.

No SOW number. Once there are several statements of work under one master agreement, an unnumbered one is hard to invoice against.

Deliverables that depend on the client, with no date for the client. If the data mapping specification cannot start until the client grants system access, give that access its own date in the assumptions or the schedule. Otherwise the supplier’s week 5 deadline stays fixed while the client’s input slips, and the delay lands on the wrong side of the table.

Signing before the contacts are named. The document control block in the example names a contact on each side. Without them, acceptance notices and change requests go to whoever happens to be copied on an email.

Build it

A statement of work is mostly tables: the document control block, deliverables, schedule and fees. A document here has 45 component types, including tables, timelines and callouts, and it is classified before writing by texture, scale and structure, where structure can be flat, numbered or tabular, which suits a scope built from deliverables and rates. Documents do not print citations, so if a clause relies on the master agreement, name the agreement and its date in the text, as the example does.

The AI chat edits text only, so it can rewrite a deliverable description or an assumption, while rows and columns are added in the builder. The page on data tables in a document shows the table block, and the tutorial on creating a document with AI covers writing the first draft from a prompt.