Statement of Work (SOW): Definition and Template Guide
A detailed document that defines project-specific deliverables, timelines, milestones, and success criteria for a specific engagement, often attached to a master contractor agreement.
A Statement of Work (SOW) is a project-specific document that defines exactly what work will be done, when it will be delivered, and how success will be measured for a particular engagement. Unlike a contractor agreement (which is a master contract covering general terms like payment, IP ownership, and termination), an SOW focuses on one specific project or phase of work. Key components include: detailed deliverables, timeline and milestones, acceptance criteria, payment schedule tied to deliverables, and project scope boundaries to prevent scope creep.
statement-of-work
A Statement of Work (SOW) is a formal document that outlines the specific deliverables, timeline, and success criteria for a defined project or engagement. It typically functions as an attachment or addendum to a master contractor agreement, providing project-specific details while the main agreement covers overarching terms like intellectual property rights, confidentiality, and termination clauses. The SOW creates accountability by documenting exactly what will be delivered, when it’s due, how it will be evaluated, and what happens if requirements change. This protects both the contractor (ensuring clear scope and payment terms) and the client (ensuring they get what they pay for on schedule).
- Scope boundaries: A strong SOW explicitly states what’s included AND what’s excluded to prevent scope creep and disputes over additional work
- Milestone-based payment: Linking payments to specific deliverable completion rather than hours worked creates accountability and aligns incentives
- Change order process: Include a clear procedure for handling scope changes, including how additional work will be priced and approved
- Acceptance criteria: Define objective standards for deliverable acceptance to avoid subjective disagreements about whether work meets requirements
- Separate from master agreement: The SOW handles project specifics while the contractor agreement covers ongoing legal terms, allowing you to execute multiple SOWs under one master contract
SOW vs Contractor Agreement
Understanding the distinction between these two documents is critical for contractors and clients working together on multiple projects.
Contractor Agreement (Master Services Agreement)
The contractor agreement, sometimes called a Master Services Agreement (MSA), is the foundational legal contract that governs the overall relationship between a contractor and client. It typically includes:
- Payment terms: How and when invoices will be paid (net-30, net-60, payment method)
- Intellectual property ownership: Who owns the work product created during the engagement
- Confidentiality: Non-disclosure terms protecting sensitive business information
- Liability and indemnification: Who’s responsible if something goes wrong
- Termination: How either party can end the relationship and what happens to in-progress work
- General legal terms: Dispute resolution, governing law, independent contractor status
This agreement stays in effect for the duration of the business relationship and typically doesn’t change between projects.
Statement of Work
The SOW is a project-specific addendum that references the master contractor agreement and adds:
- Specific deliverables: Exactly what will be produced (features, designs, reports, etc.)
- Timeline and milestones: When deliverables are due and what the project phases are
- Budget and payment schedule: Total project cost and how payments tie to milestone completion
- Acceptance criteria: How the client will evaluate whether each deliverable meets requirements
- Project scope: Boundaries on what’s included and excluded from this particular engagement
Each new project gets its own SOW, while the contractor agreement remains constant.
Why Use Both
This two-document approach offers several advantages:
- Efficiency: Negotiate legal terms once, then quickly execute new SOWs for subsequent projects
- Flexibility: Adapt project scope and pricing for each engagement without renegotiating the entire legal relationship
- Clarity: Project managers can focus on the SOW deliverables without wading through legal boilerplate
- Protection: The master agreement ensures consistent legal protections across all projects
What to Include in Your SOW
A comprehensive SOW should address these key elements:
1. Project Overview and Objectives
Start with a brief summary that answers: What is this project? Why is it being done? What business goal does it support? This context helps everyone understand the bigger picture and make better decisions when questions arise.
Example: “This project will redesign the mobile checkout flow to reduce cart abandonment and increase conversion rates on iOS and Android platforms. The goal is to achieve a 15% reduction in checkout abandonment within 60 days of launch.”
2. Detailed Deliverables
List every tangible output the contractor will provide. Be specific about formats, quantities, and specifications. Vague deliverables like “design work” lead to disputes; specific ones like “10 high-fidelity Figma mockups with mobile and desktop variants” create clarity.
Each deliverable should include:
- Description: What exactly is being delivered
- Format/specifications: File types, technical requirements, quality standards
- Quantity: How many of each item
- Dependencies: What must be provided by the client or completed first
3. Timeline and Milestones
Break the project into phases with clear deadlines. Include:
- Start date: When work begins
- Milestone dates: When each major deliverable or phase is due
- Final delivery date: When the entire project must be complete
- Review periods: How long the client has to review and request revisions for each deliverable
Be realistic about timelines and build in buffer for revisions and unexpected delays.
4. Acceptance Criteria
Define how each deliverable will be evaluated. Good acceptance criteria are objective and measurable, such as “all pages load in under 2 seconds” or “design passes WCAG 2.1 AA accessibility standards” rather than subjective standards like “looks good.”
Include:
- Functional requirements: What the deliverable must do
- Quality standards: Performance benchmarks, error rates, accessibility compliance
- Review and approval process: Who reviews, how long they have, how many revision rounds are included
- Definition of “done”: What constitutes final acceptance of each deliverable
5. Payment Terms
Link payment to milestone completion to align incentives. Specify:
- Total project value: The full contract amount
- Payment schedule: Amounts and milestones that trigger payment (e.g., “30% upon completion of wireframes, 50% upon completion of high-fidelity designs, 20% upon final delivery”)
- Invoice timing: When invoices will be submitted relative to milestone completion
- Payment terms: How quickly payment is due (should reference the master agreement)
- Expenses: Whether any expenses (software, stock photos, etc.) are reimbursable or included in the project price
6. Scope Exclusions
Explicitly state what’s NOT included. This prevents scope creep and sets expectations. Examples:
- “This SOW does not include backend development or API integration”
- “Animation and micro-interactions are excluded from this phase”
- “SEO optimization and copywriting are not included”
7. Change Order Process
Define how scope changes will be handled:
- Request procedure: How the client requests additional work
- Impact assessment: Contractor evaluates time and cost impact
- Approval: Both parties must approve changes in writing before work begins
- Pricing: How additional work will be priced (hourly rate, percentage markup, etc.)
- Timeline adjustment: How deadlines shift when scope increases
8. Client Responsibilities
List what the client must provide for the project to succeed:
- Information and assets: Brand guidelines, existing code, credentials, content
- Subject matter experts: Access to people who can answer questions
- Timely feedback: Response times for reviews and questions
- Approvals: Decision-maker availability for milestone approvals
Clear client responsibilities prevent delays caused by missing information or slow feedback.
9. Assumptions and Constraints
Document any assumptions the project plan relies on, such as:
- “Assumes client will provide final copy for all pages by [date]”
- “Assumes existing codebase is compatible with proposed framework”
- “Design work assumes unlimited revisions within reason; major direction changes may trigger change order process”
Also note any constraints:
- Budget limits that may restrict certain approaches
- Technical limitations of existing systems
- Regulatory requirements that must be met
Frequently Asked Questions
Do I need both a contractor agreement and an SOW?
If you're working on a single one-time project, you can combine everything into one contract. However, if you expect to work together on multiple projects over time, separating the master contractor agreement from project-specific SOWs is more efficient. The master agreement covers legal terms that stay constant (IP ownership, payment terms, confidentiality), while each SOW defines a specific project's deliverables and timeline. This lets you quickly execute new SOWs without renegotiating the entire legal relationship each time.
What happens if the project scope changes midstream?
This is why your SOW needs a change order process. When the client requests additional work beyond the original scope, the contractor should: 1) Assess the time and cost impact, 2) Submit a change order proposal detailing the additional deliverables, timeline extension, and added cost, 3) Get written approval from the client before proceeding. Without this process, contractors risk doing unpaid work, and clients risk surprise bills. Document all scope changes in writing—verbal agreements lead to disputes.
How detailed should deliverables be in an SOW?
Detailed enough that both parties have the same understanding of what's being delivered. Instead of 'website design,' specify '15 high-fidelity desktop mockups and 15 mobile mockups in Figma, including homepage, 5 product pages, checkout flow (4 steps), user account dashboard, and about page. All designs will follow the existing brand style guide and include hover/active states for interactive elements.' The test: if you handed the SOW to a third party, could they tell whether the deliverable meets the requirement?
Should hourly contractors use SOWs?
It depends on the engagement structure. If you're working hourly on an ongoing, open-ended basis (like staff augmentation), you may not need project-specific SOWs—just a contractor agreement with an hourly rate. However, if you're doing a defined project on an hourly basis with a not-to-exceed cap, an SOW still makes sense to document scope, deliverables, and timeline. Fixed-price projects always need SOWs to link payment to deliverable completion rather than hours logged.