Statement of Work (SOW)

Overview

A statement of work (SOW) is a project-specific document that defines the scope, deliverables, timeline and pricing for a particular piece of work, executed under the umbrella of a broader master services agreement (MSA) already in place between the parties. The term 'statement of work' is itself native to, and extremely common in, US commercial and government contracting practice — arguably more so than in many other countries — for IT, consulting, marketing, construction and similar engagements, precisely because it lets the parties fix a stable legal framework once (the MSA) and then issue lightweight, project-specific SOWs for each new piece of work without renegotiating liability, IP, confidentiality and termination terms every time. Relationship to the master services agreement: an SOW should always state expressly that it is issued under, and governed by, the terms of the parties' existing MSA (identified by date and parties), and that in the event of any conflict between the SOW and the MSA, the MSA terms prevail unless the SOW expressly states otherwise for that specific project. An SOW used without an underlying MSA is really a stand-alone services contract and should be drafted with full contract terms (liability, IP, termination, dispute resolution etc.), not just project mechanics — this template assumes an MSA is in place. Scope and deliverables: the single most important part of an SOW is a precise, unambiguous description of what will be delivered — specifications, quantities, format, and quality/acceptance criteria. Vague scope ('marketing support,' 'ongoing consulting') is the leading cause of scope-creep disputes and payment disputes under SOW-based engagements. Milestones and acceptance: the SOW should set out a milestone schedule (dates and associated deliverables) and an ACCEPTANCE PROCESS — how the client will review and either accept or reject each deliverable, and what happens if a deliverable is rejected (a right to remedy within a defined period is standard). Payment is commonly tied to milestone acceptance rather than simply to time elapsed, which protects the client against paying for undelivered or defective work. Change control: because scope inevitably evolves, the SOW should include a change control mechanism — a defined process (usually a written change order signed by both parties) for varying scope, timeline or price, rather than allowing scope to drift informally through email exchanges, which is very difficult to enforce or dispute later. Resourcing and dependencies: for services-heavy SOWs, it is good practice to name the key personnel assigned (particularly if the client is relying on specific expertise) and to record any dependencies on the client (information, access, sign-off) that could affect the timeline if not met. When to use: for any discrete project or phase of work commissioned under an existing master services agreement, where the parties want to fix scope, deliverables, milestones and price for that specific piece of work without renegotiating the underlying legal terms. Common pitfalls: issuing an SOW with no reference to a governing MSA (leaving basic legal protections undefined); vague deliverable descriptions; no defined acceptance process; and no change control mechanism, leading to unmanaged scope creep. This template must be reviewed against {{governing_state}} contract law and alongside the parties' MSA.