What Is a Statement of Work (SOW)? Parts, a Sample and a Pre-Signing Checklist
A statement of work (SOW) says exactly what a supplier will do for a customer: the work, the deliverables, the timing, how success is judged and what it costs. Most disputes over projects trace back to a sentence in the SOW that two people read in two ways. This guide explains the parts, shows how a SOW relates to a master agreement, walks through a complete made-up sample with the arithmetic, and ends with a checklist to use before you sign. It is general information, not legal advice.
What a SOW is
A statement of work is a narrative description of the work one party will do for another on a specific project. It covers the activities, the deliverables and the timeline. When it is signed, or attached to a signed contract, it normally becomes part of the agreement and can be enforced like the rest of it.
Virginia’s state IT procurement manual (published by VITA) gives a handy test. A good SOW answers five questions: what is to be done, who does it, when, where and how. It also asks for measurable performance standards, so both sides can tell when the work is finished. See the manual’s section on preparing a quality SOW. Its advice is written for government IT buying, but the principles apply to almost any services project.
Who writes it? Usually the buyer writes a SOW to go with a request for proposals, or the supplier drafts one after the first discussions and the buyer reviews it. Either way, both sides should read every line, because they are both bound by it.
SOW vs MSA vs SLA
These three documents are often confused. They sit at different levels.
| Document | What it covers | How often | Typical contents |
|---|---|---|---|
| MSA (master services agreement) | The relationship: general legal terms for all projects | Once, then reused | Payment terms, confidentiality, liability limits, ownership of work, disputes, ending the agreement |
| SOW (statement of work) | One project | One per project | Scope, deliverables, schedule, price, acceptance criteria, responsibilities |
| SLA (service level agreement) | Ongoing service quality | Often attached to the MSA | Measurable standards such as availability, response time and support hours |
A guide from Ironclad describes the MSA as the parent and each SOW as a child that inherits its general terms. It also says that if a SOW and the MSA conflict, the MSA’s order-of-precedence clause usually settles it, unless the SOW expressly says it overrides a particular section. In practice that means two things for you:
- Do not paste legal terms such as payment or liability into a SOW unless you mean to change the MSA. Conflicts often come from careless copying out of an older SOW.
- Sign the MSA before or together with the first SOW. A SOW with no MSA has to carry all the legal terms itself.
Some organizations use the words “work order” or “order form” instead of SOW. Check what a document actually contains, not what it is called. Rules differ by country and by industry, so have a lawyer review anything with real money or risk attached.
For more on how contracts are managed from start to finish, see contract lifecycle management.
The parts of a SOW
The Virginia manual says a SOW should at least include an introduction, background, scope, applicable directives, performance requirements, deliverables, and quality assurance and acceptance criteria. Our table below turns that into a practical list. Not every project needs every row. Small projects can combine several.
| Part | What it says | Common mistake |
|---|---|---|
| 1. Purpose and background | Why the project exists and what outcome the buyer wants | Skipping it, so no one remembers the goal when trade-offs come |
| 2. Scope: in and out | What is included, and what is clearly not | Describing only what is in. The “out” list prevents most arguments |
| 3. Tasks and responsibilities | Who does what, on each side | Assuming the buyer will supply content, data or access without saying so |
| 4. Deliverables | Each item handed over, with format and due date | Vague nouns such as “a solution” or “support” |
| 5. Schedule and milestones | Start, end, and the dates in between | Dates with no dependencies, so a late input never moves the plan |
| 6. Place and period of work | Where the work happens and for how long | Leaving out travel, access or working-hours rules |
| 7. Acceptance criteria | How the buyer decides a deliverable is done, and how long review takes | “To the buyer’s satisfaction” with no test |
| 8. Price and payment | Fixed price, hourly or another basis, and when invoices are due | Payment not tied to accepted deliverables |
| 9. Assumptions and dependencies | What the plan relies on, such as inputs and approvals by certain dates | Leaving assumptions unwritten, then arguing over who caused delay |
| 10. Change control | How changes are requested, priced and approved | Verbal changes with no written trail |
| 11. Standards, security and key people | Rules the work must follow, who must do it, contacts | No plan for what happens if a named person leaves |
Two other cautions from the Virginia manual are worth remembering: avoid repeating terms that already appear elsewhere in the contract, because repeats can drift out of sync, and avoid conflicting requirements inside the document.
A complete sample
The company, people and numbers below are made up. The point is the level of detail.
Statement of work: website for Northwind Café
Parties: Northwind Café (“Client”) and BrightPixel Studio (“Supplier”). Governed by the master services agreement dated [date]. If this SOW conflicts with that agreement, the agreement prevails.
1. Purpose: Replace the Client’s one-page site with a site that shows the menu, takes catering enquiries and works well on phones.
2. Scope in: Design and build of 8 pages (Home, Menu, Catering, About, Contact, Gallery, Events, Privacy); a catering enquiry form that emails the Client; basic search-engine setup (page titles and descriptions); training for two staff.
Scope out: Photography, writing of text (Client supplies it), online payments, hosting and ongoing maintenance.
3. Responsibilities: Supplier: design, build, testing, training. Client: supply final text and photos by the end of week 2, name one decision-maker, and give feedback within 3 business days.
4. Deliverables and schedule: M1 approved design for Home and Menu pages: end of week 2. M2 working test version of all 8 pages: end of week 5. M3 live site and staff training: end of week 6.
5. Acceptance: A milestone is accepted when it passes this test list: every page loads without errors on current versions of two major browsers and on a phone; the enquiry form delivers a test message to the Client’s inbox; all supplied text and photos are in place. The Client has 5 business days to review and must either accept or list the failed items in writing. Up to two correction rounds are included per milestone.
6. Price and payment: Fixed price $14,400: 30% on signing ($4,320), 40% on acceptance of M2 ($5,760), 30% on acceptance of M3 ($4,320). Invoices are due in 14 days.
7. Assumptions: If Client text or feedback is late, the affected milestone date moves by the same number of days.
8. Changes: Any change to scope, schedule or price needs a written change request approved by both named contacts before work starts.
Check the arithmetic: 30% of $14,400 is $4,320, 40% is $5,760, and 4,320 + 5,760 + 4,320 = 14,400. Notice what this SOW does well. It lists what is out of scope. It ties two-thirds of the money to accepted work. It gives the test for acceptance, and it says what happens when the client is late.
Vague wording vs precise wording
| Vague | Why it causes trouble | Precise |
|---|---|---|
| “A modern, user-friendly website” | Everyone defines “modern” differently | “An 8-page site built to the approved design that passes the test list in section 5” |
| “Ongoing support” | No limit on hours or response times | “30 days of email support after launch, replies within 2 business days” |
| “As soon as possible” | No date to measure against | “By 14 November” |
| “To the Client’s satisfaction” | Allows endless rejection | “Accepted when the test list passes or after 5 business days with no written objection” |
| “Supplier will fix bugs” | What counts as a bug, and for how long? | “Supplier will fix faults in delivered features reported within 30 days of launch” |
| “Reasonable changes included” | “Reasonable” is an argument waiting to happen | “Two correction rounds per milestone. Other changes follow section 8” |
The “5 business days with no written objection” wording is a form of deemed acceptance. It is common, but it favors the supplier. A buyer should read it carefully and may ask for a reminder notice before acceptance happens automatically.
Acceptance and change control
Acceptance, step by step
- The supplier delivers and says so in writing.
- The buyer tests against the criteria in the SOW, not against a new wish list.
- The buyer accepts, or sends a written list of what failed.
- The supplier corrects, and the cycle repeats up to the agreed limit.
- Acceptance triggers the payment tied to the milestone.
Change control, with an example
Changes are normal. The risk is a change that no one prices. Suppose the Northwind client asks to add two pages (a jobs page and a news page) halfway through. A written change request records:
| Item | Detail |
|---|---|
| Change | Add a Jobs page and a News page |
| Price | 2 pages × $450 = $900 |
| New total | $14,400 + $900 = $15,300 |
| Schedule effect | M2 and M3 each move by 3 working days |
| Approved by | Both named contacts, in writing, before work starts |
Without that record, the work happens anyway and the invoice becomes a quarrel. For more on this pattern, read about scope creep in project management and, for contracts specifically, preventing contract scope creep. Teams that work in short cycles may want a different shape of contract: see how to design an agile contract.
Checklist before you sign
SOW checklist
- Does it say why the project exists and what outcome is wanted?
- Is there an in-scope and out-of-scope list?
- Is every deliverable named, with a format and a date?
- Is it clear who does what on both sides?
- Does each deliverable have a test for acceptance and a review period?
- Is payment tied to accepted work, not just elapsed time?
- Are assumptions written down, with what happens if they fail?
- Is there a change process that needs written approval?
- Does it avoid repeating or contradicting the master agreement?
- Do the dates have dependencies (what must happen first)?
- Is there a plan if a key person leaves?
- Has someone who did not write it read it cold and explained it back?
- For significant money or risk, has a lawyer reviewed it?
Learn more
Poorly managed contracts can be expensive. Our article on the cost of poor contract management shows where the losses come from. If you want to work in this field, see the contract administrator job description and compare training in our contract management program guide. Everything is collected in the contract management hub.
Online providers such as Coursera and Udemy list contract management courses. We may earn a commission if you sign up, at no cost to you. We are not affiliated with any university. Check each syllabus to see whether it covers drafting scopes of work.
Frequently asked questions
What is a statement of work?
A document describing the work a supplier will do on one project: scope, deliverables, schedule, price, responsibilities and how the result will be accepted.
Is a SOW legally binding?
Usually, yes, once it is signed or incorporated into a signed contract. The details depend on the contract and the law where you are, so ask a lawyer about a specific case.
What is the difference between a SOW and an MSA?
An MSA sets general legal terms for a long-term relationship. A SOW describes one project under it. One MSA can have many SOWs.
What is the difference between a SOW and a scope statement?
A project scope statement describes what is and is not included in a project, usually from the project owner’s view. A SOW is the contract-facing document and adds deliverables, timing, responsibilities, acceptance and payment. The scope section of a SOW often comes from the approved scope statement.
Who writes the statement of work?
Either side. Buyers often write it to go with a request for proposals. Suppliers often draft it after talks begin. Both must review it.
How long should a SOW be?
As long as the project needs and no longer. A small project may need two pages. A complex one may need many. Clear and complete beats short.
What is a performance work statement?
A document used in some government buying that describes the results wanted rather than the steps to take. It is often used when the buyer cares about outcomes and the supplier chooses the method. Plain SOWs fit best when the task is well understood.
Browse certificate, course and degree programs side by side.