A Statement of Work (SOW) is the project-level document that sits underneath a Master Service Agreement, or stands alone for a single-engagement service contract. It is where the actual work gets defined — what will be delivered, by when, for how much, and what counts as done. While the MSA handles legal terms once, every project produces a new SOW. Get the SOW right and the project runs on rails; get it wrong and you spend the project arguing about whether something was in scope.

This guide explains the role of the SOW alongside the MSA, the essential sections every SOW must contain, how to write deliverables and acceptance criteria that hold up under scrutiny, how to handle change orders, and the common drafting mistakes that lead to scope creep, payment disputes, and project failures.

When You Need an SOW

  • Project-based services under an existing MSA (consulting, software development, marketing campaigns, design)
  • Standalone service engagements where an MSA is overkill
  • Internal projects where one team is delivering to another (rare but useful for accountability)
  • Government or large-corporate procurement where the SOW is part of a tender response

For staff augmentation (time-and-materials engagement of consultants), a simpler engagement letter may suffice. SOWs shine when there are specific deliverables tied to specific payments.

Essential Sections of an SOW

1. SOW Header and References

SOW number, effective date, reference to the governing MSA (if any), parties (client and service provider), and brief description.

2. Project Background and Objectives

One or two paragraphs explaining the business context — why the project exists, what business outcomes the client expects. This frames everything that follows and helps resolve ambiguity later: "the intent was X, so the right answer is..."

3. Scope of Work

The core. Describe in detail what the service provider will do. Best structured as:

  • In scope — Specific work to be performed
  • Out of scope — Explicit exclusions (this is where most disputes are prevented)
  • Assumptions — Conditions assumed to be true (e.g., "client will provide access to existing documentation by week 2")
  • Dependencies — What the provider needs from the client (data, approvals, personnel)

4. Deliverables

Tangible outputs the client will receive. Each deliverable should have:

  • Name and reference number
  • Description (what it is and what it contains)
  • Format (Word document, PDF, source code repository, presentation, working software)
  • Delivery date or milestone
  • Acceptance criteria

5. Acceptance Criteria

How the client determines whether the deliverable is acceptable. This is critical and often skipped. Examples:

  • For a written report: "Contains analysis of the five business areas listed in Appendix A, with recommendations and supporting data; conforms to the agreed report template; reviewed and accepted by the Client Project Sponsor"
  • For software: "Passes the User Acceptance Test cases listed in Appendix B with zero critical defects and fewer than five medium defects"
  • For a marketing campaign: "Campaign assets delivered as per the agreed brief; campaign launched on the agreed date; reporting dashboard accessible to client"

Avoid vague language like "to client's satisfaction" — this gives the client unlimited rejection rights.

6. Timeline and Milestones

Project start date, end date, and intermediate milestones. For longer projects, a Gantt-style schedule or table is essential. Note any holidays, blackout periods, or known scheduling constraints.

7. Fees and Payment Schedule

Three common structures:

  • Fixed price — Total fee for the deliverables, paid in installments (often: 30% on signing, 30% at midpoint milestone, 40% on acceptance)
  • Time and materials — Hourly or daily rates with a not-to-exceed cap. Monthly invoicing
  • Milestone-based — Payment tied to acceptance of specific deliverables

Specify currency, SST treatment, expenses policy, and payment terms (e.g., net 30 from invoice). For higher-value SOWs, include a security or escrow mechanism.

8. Project Team and Key Personnel

Named provider personnel and their roles. Whether personnel are dedicated or shared. Process for changes — replacement requires equivalent skill and client approval. Client's project sponsor and points of contact.

9. Governance and Reporting

How the project is managed:

  • Frequency of status reports (weekly, bi-weekly, monthly)
  • Format and content (progress, risks, issues, planned next steps)
  • Steering committee meetings and attendees
  • Escalation path for issues

10. Acceptance Process

The procedure for accepting deliverables:

  • Provider notifies completion in writing
  • Client has a defined review period (typically 5–10 business days)
  • Within that period, client either accepts in writing or rejects with specific reasons
  • If rejected, provider has a defined cure period to address the issues
  • If no response within review period, deliverable is deemed accepted

11. Change Management

How scope changes are handled. Standard process:

  • Either party proposes a change in writing
  • Provider assesses impact on scope, schedule, and fees
  • If both parties agree, a Change Order is signed amending the SOW
  • Until signed, the original SOW remains in force

Without a documented change process, every scope discussion becomes an argument.

12. Assumptions and Dependencies (Reiterated)

Restate critical assumptions in the SOW even if mentioned elsewhere. If an assumption fails, the project plan is invalidated and a Change Order may be needed.

13. Special Terms

Any project-specific terms that override or supplement the MSA — e.g., specific IP arrangements for a deliverable, specific data security requirements, specific subcontracting permissions.

14. Signatures

Authorised signatories for both parties. Date of execution.

Worked Example — Deliverable with Acceptance Criteria

Deliverable D-03: Customer Segmentation Analysis Report

Description: A written report analysing the Client's customer base into four to six distinct segments, with profiles and recommended engagement strategies for each.

Format: Microsoft Word document, approximately 30–40 pages, accompanied by a Microsoft PowerPoint executive summary.

Delivery Date: 15 July 2026

Acceptance Criteria:

  1. Report covers all four data domains listed in Appendix C: transaction history, demographic data, channel usage, product holdings
  2. Identifies between four and six segments with sample sizes of at least 1,000 customers each
  3. Each segment profile includes: demographic summary, behavioural patterns, revenue contribution, and at least three recommended engagement strategies
  4. Executive summary is no more than 10 slides
  5. Final draft reviewed and approved in writing by the Client Marketing Director within 10 business days of submission

The Scope-Schedule-Cost Triangle

A classic project management principle that SOWs must respect:

  • Fix two and the third must give
  • If scope is fixed and schedule is fixed, cost is the lever (more resources, more cost)
  • If scope is fixed and cost is fixed, schedule is the lever
  • If schedule and cost are fixed, scope must be flexible

SOWs that pretend to fix all three set up the project to fail. A good SOW makes the trade-off explicit and the change-order mechanism robust.

Change Orders

The most under-used document in service projects. A Change Order is essentially a mini-SOW that:

  • References the original SOW
  • Describes the change in scope
  • Quantifies impact on deliverables, schedule, and fees
  • Is signed by both parties before work proceeds

Providers should refuse to do meaningful additional work without a signed Change Order. Clients should respect that the SOW is a contract, not a starting point for endless renegotiation.

Common SOW Mistakes

  • Vague deliverables. "A strategy document" is not a deliverable; "A 40-page market entry strategy report covering five priority countries" is
  • No acceptance criteria. Without criteria, "acceptance" becomes "client's mood that day"
  • No out-of-scope list. Everything not mentioned becomes a potential scope dispute
  • Soft milestones. "End of June" is weaker than "30 June 2026"
  • No client obligations. Provider depends on client inputs that arrive late, but client takes no responsibility
  • No assumptions documented. Critical project assumptions left in email threads
  • No change-order process. Scope creep becomes a daily battle
  • Payment tied to "completion". "Completion" needs to be defined; deemed acceptance after a review period is essential
  • Personnel not named. Star consultant promised in the pitch is swapped for a junior on day one
  • Conflict with MSA not addressed. Order of precedence between MSA and SOW must be stated

SOW vs Proposal vs Contract

  • Proposal — Pre-engagement document selling the engagement. Not binding
  • SOW — Post-engagement document defining the actual project. Binding, signed by both parties
  • Standalone Service Contract — Combines what an MSA + SOW would do, for one-off engagements

Generate a Statement of Work with Popupnote

The Statement of Work Generator on Popupnote produces a structured SOW with project background, scope (including in-scope, out-of-scope, assumptions, and dependencies), deliverables with acceptance criteria, timeline, fees and payment schedule, governance, change management, and signature block. It is designed to sit under a Master Service Agreement or stand alone as a single-engagement contract. The generator runs in your browser without any account required.