Statement of Work

A Statement of Work (SOW) is a narrative description of required work: it stipulates the deliverables or services needed to fulfill a contract, and defines the task in clear, concise, meaningful terms — related but distinct documents: a Statement of Objectives (SOO) describes desired outcomes without prescribing the method, a Performance Work Statement (PWS) focuses on performance-based outcomes, and a Contract Data Requirements List (CDRL) enumerates the specific data deliverables a contract requires.

Core sections

• Title, Abstract — the project's official name and a one-paragraph summary covering the most relevant objectives and issues.
• Value — the estimated cost/value of the work, including products, services, and materials.
• Scope — the range and parameters of the work: people, processes, tools involved.
• Type — the legal character of the engagement (e.g. work-for-hire under a specific jurisdiction's law) — this section states type narratively; it is not a substitute for a lawyer drafting the actual binding legal terms.
• Payment — the budget, payment schedule, and transfer method.

Purpose section

• Objectives — what's to be achieved by completion. Use Objectives and Key Results framing: state the objective, then the measurable key results that would prove it was met.
• Performance — how the work is measured. Use Key Performance Indicators for both business metrics (e.g. customer satisfaction, revenue impact) and technical metrics (e.g. uptime, response time, data accuracy) — state a specific target number for each, not just the metric's name.
• Factors — critical success factors: personnel availability, budget allocation, tool availability, stakeholder engagement, scope management, risk management, time management, quality assurance, end-user adoption.

Who does what

• People — everyone involved (employees, contractors, vendors, customers, auditors, investors) with contact information — commonly kept as a separate, continuously-updated "people" document rather than embedded and going stale inside the SOW itself.
• Roles — what each role does, its capabilities and limits.
• Responsibilities — a RACIO matrix (a responsibility assignment matrix variant): rows are areas of responsibility, columns are roles, and each cell is one of Responsible, Accountable, Consultable, Informable, or Omittable for that role/area pairing.

Context: past, present, future

Describe what led to the work (past), how it fits the organization's current objectives and industry (present), and how it relates to future roadmaps (future) — enough for a contractor to formulate a good bid and for both sides to reach shared understanding, not boilerplate filler.

Planning section

Requirements, specifications, a work breakdown structure, applicable standards, the technical/operational/organizational environment, method and source of acceptance, reporting requirements, project-management control procedures, change-management procedures, and ownership of intellectual property — each should be specific enough that both parties agree, in advance, on what "done" and "acceptable" mean, since a vague acceptance criterion is where SOW disputes come from later.

Other terms and conditions

Authorities (who holds Work Authority vs. Contracting Authority), each party's obligations, location/language of work, special/security/ insurance/expense requirements — these sections exist to prevent predictable disputes (who approves what, who provides what access, who bears what cost) by settling them explicitly before work starts rather than assuming shared understanding.

Schedule and sign-off

Start/completion dates, the schedule (built on the SOW's own work breakdown structure), required resource types/roles, applicable reference documents, and a wordbook (glossary of the initialisms/abbreviations used — e.g. SOW, OKR, WBS — so all parties share the same definitions). End with an explicit sign-off block and a note encouraging the signer to raise questions before signing, not after.

Common pitfalls

• A scope section vague enough that "done" is contestable — the whole point of a SOW is to make completion and acceptance objectively checkable; ambiguity here is where disputes originate.
• Objectives without measurable key results, or performance metrics without target numbers — see Objectives and Key Results and Key Performance Indicators; an unmeasurable objective can't settle a later disagreement about whether the work succeeded.
• No RACIO matrix, or one with ambiguous overlapping "Responsible" assignments — more than one "Responsible" party per area of work is a common, avoidable source of things falling through the cracks.
• Treating the SOW as the whole contract — a SOW is the narrative description of the work; broader legal terms (liability, indemnity, dispute resolution, termination) typically live in the surrounding master agreement or contract, not the SOW alone — don't treat SOW language as a substitute for actual legal drafting.
• No change-management procedure stated up front — without one, scope changes get negotiated ad hoc under pressure instead of via an agreed written-amendment process.

Learn more

• joelparkerhenderson/statement-of-work — the source for this skill, including a full worked example.
• Wikipedia: Statement of work
• Objectives and Key Results, Key Performance Indicators for the Objectives/Performance sections specifically.
• This skill describes SOW content structure; it is not legal advice — have actual contract language reviewed by a qualified lawyer.