--- name: statement-of-work description: Use when asked to write or structure a Statement of Work (SOW) — abstract/scope/payment sections, objectives via OKRs, performance via KPIs, or a RACI-style responsibility matrix — grounded in joelparkerhenderson/statement-of-work, as distinct from a full contract's legal terms. --- # 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](https://github.com/joelparkerhenderson/statement-of-work) — the source for this skill, including a full worked example. - [Wikipedia: Statement of work](https://en.wikipedia.org/wiki/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.