By Ryan Kramer, founder of Wisegrid. Last updated July 2026.
A scope of work (SOW) is the document that defines exactly what will be delivered on a project: the deliverables, the tasks that produce them, the timeline and milestones, the acceptance criteria, and, just as importantly, what is not included. It is the reference both sides return to when someone asks “wait, is that part of the project?”, which is why a good one is written before that question gets expensive.
This guide walks through every section a scope of work needs, gives you the complete template to copy, shows a worked example, and untangles the three terms people use interchangeably: scope of work, statement of work, and project scope statement.
Key takeaways – A scope of work answers five questions: what will be delivered, what work produces it, when, how “done” will be judged, and what is explicitly excluded. – Exclusions are the highest-value section. Almost every scope dispute lives in work the client assumed was included and the team assumed was not. – Deliverables need acceptance criteria, written as checkable statements. “Modern, professional website” is an argument waiting to happen; “passes the launch checklist in Appendix A” is not. – Scope of work and statement of work overlap but differ: the statement of work is the broader contractual document; the scope of work is its what-gets-done core. A project scope statement is the internal PM equivalent. – The SOW is not done when it is signed. It has to turn into a tracked plan, or the document and the delivered work drift apart.
What is a scope of work?
A scope of work is the written definition of a project’s boundaries: the deliverables to be produced, the work required to produce them, the schedule and milestones, the standards by which completion will be judged, and the assumptions and exclusions that fence the whole thing in. Between a client and a vendor it usually forms part of the contract; between internal teams it is the agreement that stops a project from quietly growing.
Its real job is economic. Every project accumulates moments where someone wants more than was planned: another revision round, one more integration, “small” additions that compound. Without a written scope, each of those moments is a negotiation the delivery side usually loses; with one, the conversation shifts from “is this included?” to “this is a change; here is what it does to the schedule and price.” The SOW does not prevent change; it makes change visible and priceable.
Scope of work vs statement of work vs project scope statement
The three terms get used loosely, and both “scope of work” and “statement of work” abbreviate to SOW, which does not help. The working distinctions:
| Term | What it is | Where it lives |
|---|---|---|
| Statement of work | The broader contractual document governing an engagement: scope plus pricing, payment schedule, invoicing terms, governance, legal terms, signatures | Attached to or referenced by the contract (often under a master services agreement) |
| Scope of work | The what-gets-done core: deliverables, tasks, timeline, acceptance criteria, exclusions | Usually a section of the statement of work, or a standalone document on lighter engagements |
| Project scope statement | The internal PM equivalent: deliverables, boundaries, acceptance criteria, assumptions and constraints for a project team, no commercial terms | Inside the project plan or charter; PMBOK-style projects produce one during scope planning |
In practice: if there is a client and money, you are writing a scope of work, possibly inside a statement of work. If it is an internal project, you are writing a project scope statement, which is the same content minus pricing and legal boilerplate. The template below serves both; delete the commercial rows for internal use.
The sections of a scope of work
1. Project overview and objectives. Two or three sentences: what the project is, for whom, and the outcome that defines success. Objectives should be checkable at the end (“reduce checkout steps from five to two”), not aspirational (“improve the customer experience”).
2. Deliverables. The heart of the document: every artifact the project hands over, listed individually with enough specificity to be counted and checked. “Website” is not a deliverable; “responsive marketing site of up to 12 templated pages, deployed to the client’s hosting” is.
3. Tasks / scope of services. The major work areas that produce the deliverables (discovery, design, build, testing, launch support). This section tells the reader what activity is covered, which matters when a dispute is about effort (“we assumed you’d migrate the data”) rather than artifacts.
4. Schedule and milestones. Phases, milestone dates, and the review gates between them. Anchor dates to dependencies where you can (“design sign-off + 6 weeks”) so one slip does not falsify the whole table.
5. Acceptance criteria. For each deliverable, the checkable conditions under which it is accepted, plus the review process itself: who reviews, within how many business days, how many revision rounds are included, and what happens when the review window lapses (deemed acceptance after N days is common and worth agreeing up front).
6. Exclusions. The explicit not-included list, written from experience of what clients in this kind of project tend to assume: content writing, data migration, ongoing maintenance, third-party license costs, post-launch changes. Every line here is a future dispute pre-resolved.
7. Assumptions and dependencies. What must be true, and what you need from the client by when. Pair each client-owed item with a consequence (“dates shift day-for-day with late materials”), or the dependency has no teeth.
8. Roles, governance, and change control. Who owns what on both sides, who can approve a change, and the change process: proposed in writing, priced for schedule and cost impact, approved before the work happens.
9. Commercial terms. Price, payment schedule, invoicing, expenses. On contractual engagements this may live in the statement of work or master agreement instead; make sure it lives somewhere and is referenced.
10. Signatures. Named approvers on both sides, with dates. Unsigned scopes protect no one.
The scope of work template
Copy this structure directly; the bracketed prompts tell you what each line needs.
SCOPE OF WORK
Project: [name] · Client: [name] · Date: [date] · Version: [v1.0]
1. OVERVIEW & OBJECTIVES
[2-3 sentences: what, for whom, and the measurable outcome(s).]
2. DELIVERABLES
D1. [Deliverable, with quantity/spec: "up to 12 templated pages"]
D2. [...]
3. SCOPE OF SERVICES (TASKS)
Phase 1 [Discovery]: [major activities]
Phase 2 [Design]: [...]
Phase 3 [Build/Deliver]: [...]
4. SCHEDULE & MILESTONES
M1 [Kickoff] [date]
M2 [Design sign-off] [date or "M1 + N weeks"]
M3 [Delivery/launch] [...]
5. ACCEPTANCE CRITERIA
D1 accepted when: [checkable conditions]
Review process: [who reviews] within [N business days];
[N] revision rounds included; deemed accepted after [N] days
without written feedback.
6. EXCLUSIONS (NOT IN SCOPE)
- [Everything a reasonable client might assume is included
but is not. Be blunt.]
7. ASSUMPTIONS & CLIENT DEPENDENCIES
- [Assumption or client-owed item, its due date, and the
consequence if late.]
8. ROLES & CHANGE CONTROL
[Client owner], [vendor owner]. Changes are requested in
writing, assessed for schedule/cost impact, and approved by
[names] before work begins.
9. COMMERCIAL TERMS
[Price, payment schedule, invoicing, expenses; or reference
to the governing agreement.]
10. APPROVALS
[Name, role, signature, date] x2A worked example
The key sections for a fictional but realistic engagement, a marketing site redesign:
Overview. Redesign and rebuild Meridian Outfitters’ marketing website on their existing CMS, replacing the current 40-page site with a templated 12-page architecture. Objectives: launch before the Sep 15 campaign; pass Core Web Vitals on the ten highest-traffic pages.
Deliverables. D1: sitemap and wireframes for 12 page types. D2: visual design system (desktop + mobile comps for all 12). D3: built and deployed templates on the client’s CMS. D4: content migration of the 40 existing pages into the new templates. D5: launch checklist execution and two weeks of post-launch defect fixes.
Milestones. Kickoff Jul 14 · Wireframe sign-off Jul 28 · Design sign-off Aug 18 · Build complete Sep 5 · Launch Sep 12.
Acceptance. D2 accepted when all 12 page types are approved in writing by the client’s marketing director; two revision rounds included, further rounds change-controlled. D3 accepted when templates render the approved designs on the current versions of Chrome, Safari, Edge, and Firefox at the breakpoints listed in Appendix A and pass the launch checklist.
Exclusions. Copywriting and photography (client provides all content); SEO strategy beyond preserving existing URL redirects; CMS license and hosting costs; maintenance after the two-week post-launch window; any pages beyond the 12 templates.
Dependencies. Client provides brand assets by Jul 21 and final page copy by Aug 25; CMS staging access by Jul 16. Late materials shift downstream dates day-for-day.
Notice the shape: quantities on every deliverable, sign-off owners named, revision rounds counted, and the exclusions list aimed precisely at what a marketing client tends to assume (copy, photos, extra pages). That last section is the one this example project would have been sunk without.
The mistakes that cause scope disputes
- Uncounted deliverables. Any deliverable without a quantity or spec (“social assets”, “revisions”) will be interpreted generously by the other side. Count everything countable.
- Adjectives as acceptance criteria. “Modern”, “intuitive”, and “high-quality” are opinions. Criteria must be checkable by both sides reading the same words.
- No exclusions section. The most common omission. If the document only says what is included, everything else is ambiguous, and ambiguity resolves against whoever wants to get paid.
- Client dependencies without consequences. “Client provides content by Aug 25” means nothing on Aug 26 unless the document says what happens next.
- Change control that exists only on paper. If the team absorbs “small” changes without invoking the process, the tenth small change is unbillable. The first change request sets the precedent; make it formally, however friendly the wording.
- The signed SOW going in a drawer. If the delivery plan is rebuilt from memory in a task tool, scope drifts from the document within weeks, and nobody notices until the acceptance meeting.
From signed SOW to tracked project
The document only protects you if the plan the team executes is visibly the same list of deliverables the client signed. The practical move: the day the SOW is signed, turn it into the project’s tracking sheet, one row per deliverable and milestone with owner, due date, acceptance criterion, and status, plus client-owed dependencies as dated rows, so the chase list lives where the work does.
In Wisegrid that structure is reusable: build the SOW-shaped project once (deliverables sheet, dependency rows, a status dashboard the client can be shown), save it as a blueprint, and provision an identical, pre-filled copy for every new engagement in under a minute. Date-triggered automations chase the client-owed items so “content due Aug 25” actually produces a nudge on Aug 25.
The full build is in the companion guide: From scope of work to tracked project in Wisegrid.
FAQ
What is a scope of work?
The document defining a project’s boundaries: deliverables, the work that produces them, schedule and milestones, acceptance criteria, and explicit exclusions. Between client and vendor it usually forms part of the contract.
What is the difference between a scope of work and a statement of work?
The statement of work is the broader contractual document (scope plus pricing, payment terms, governance, legal terms); the scope of work is its core section defining what gets done. Both abbreviate to SOW, so confirm which document your counterparty means.
What is a project scope statement?
The internal project management version of a scope of work: deliverables, boundaries, acceptance criteria, assumptions, and constraints, produced during scope planning, without commercial terms. Same content discipline, no contract attached.
How do I write a scope of work?
Work through the ten sections above in order: overview, deliverables (counted), tasks, schedule, acceptance criteria, exclusions, assumptions and dependencies, roles and change control, commercial terms, signatures. Then have someone read it looking only for ambiguity.
How detailed should a scope of work be?
Detailed enough that a disputed item can be resolved by reading the document rather than by negotiation. Quantities, checkable acceptance criteria, and a blunt exclusions list are where detail pays; task-level minutiae is where it does not.
Is a scope of work legally binding?
When it is part of a signed contract or statement of work, its terms are generally binding as part of that agreement. For anything with meaningful money attached, have your contract reviewed by a lawyer; this guide is about writing clear scope, not legal advice.
Turn the signed scope into the plan the client watches
One row per deliverable, dependencies with dates, and a client-facing dashboard, provisioned from a blueprint for every new engagement.
Start free → · From SOW to tracked project → · Client onboarding checklist →
About the author Ryan Kramer is the founder of Wisegrid, a higher-capacity Smartsheet alternative with project blueprints, date-triggered automations, and client-facing dashboards included in the normal $9 and $19 tiers. He writes about turning client agreements into systems that keep both sides honest. More from Ryan →