Before a project begins, a client and service provider need one document that answers three questions: what gets delivered, by when, and for how much. Without it, you’re relying on email threads, verbal agreements, and assumptions.
That document is the statement of work.
What is a statement of work?
A statement of work (SOW) is a document that fully outlines a work agreement between two or more parties. It’s used at the start of any service-based engagement, including consulting, software development, marketing, construction, and government contracting, to align both sides before work begins.
An SOW establishes the work requirements, acceptance criteria, payment terms, and milestones that define a successful project.
Think of it as the single source of truth for a project: what gets done, by whom, by when, and for how much. It’s one of the first documents created before kickoff, and everything that follows traces back to it. When there’s a dispute about scope or payment, the SOW is the document both parties return to.
What does a statement of work include?
While no two SOWs are exactly the same, most cover the same core components.
Here’s what a standard SOW should contain.
Additionally, the statement of work outlines the goals, timelines, and criteria for the acceptance and closure of the project.
Here’s a closer look at what any basic standard of work should contain.
- Project overview and goals: A high-level summary of what the project will achieve and why the work is being commissioned. This section sets the context for all parties.
- Scope of work: Defines exactly what’s included in the engagement and, just as importantly, what is not. This is the most critical section for preventing scope creep down the line.
- Deliverables: The specific outputs the service provider will produce, with clear acceptance criteria for each. Vague deliverables are one of the most common sources of project disputes.
- Timeline and milestones: The project schedule broken into phases, with key dates and dependencies called out. This gives both parties a shared view of progress and accountability.
- Tasks and responsibilities: Specific actions assigned to teams or individuals, often with due dates and sequencing. This section makes clear who owns what and when.
- Timeline and milestones: The project schedule broken into phases, with key dates and dependencies called out. For complex projects, milestones may need to be completed in a specific order, and it’s worth building in scheduled check-ins that connect individual deliverables back to the broader organizational goal.
- Costs and payment schedule: A clear breakdown of approved labor, expenses, and how funds will be released, whether on a milestone basis or another schedule. Because most projects run over budget due to labor, materials, or unforeseen circumstances, this section should also define the conditions under which budget overages are acceptable and how they will be handled.
- Standards and requirements: Any regulatory, technical, or communication standards that apply to the engagement, including reporting formats, compliance requirements, or tools both parties agree to use.
- Signatures: The SOW becomes a binding document once both parties sign.
A well-structured SOW will also include a definitions section to clarify acronyms and technical terms, a clause covering ownership and usage rights for any work produced, and a process for handling decisions that cannot be resolved before the project starts. For more inspiration on structure and format, see our SOW templates and examples.