You've reached the scope statement in your Statement of Work, and the cursor is blinking. This is the paragraph that decides what the project includes, what it leaves out, and which assumptions everything else rests on. Get it sharp and the rest of the SOW almost writes itself.
This page is about the scope statement section inside a SOW. It's not a "statement of work vs scope of work" debate. We'll explain what the section does, show you what belongs in it, and hand you a paste-ready example with an in-scope / out-of-scope table you can adapt today.
Key takeaways
- The scope statement defines what work is included in the project, what is excluded, and the assumptions the project depends on.
- It should include the project objective, in-scope work, out-of-scope items, assumptions, constraints, and dependencies.
- Every deliverable in the SOW should fit within the scope statement, and any new requests outside that boundary should be handled through a change order.
- CreateMySOW helps you build a complete SOW with a clear scope statement, defined project boundaries, and aligned deliverables.
What the scope statement does in a SOW
A scope statement says what the project will do and, just as importantly, what it will not.
The scope statement is the boundary line of your project. It names the objective, lists what's in scope, mirrors that with what's out of scope, and records the assumptions the estimate depends on. Everything inside the line is the work you've agreed to do. Everything outside it is either a separate engagement or a change order.
That boundary is what lets both sides agree, months later, whether a new request was already part of the deal or something new. A sharp boundary reduces the risk of that disagreement. It doesn't remove the risk entirely, but it gives you a written line to point at instead of two memories that no longer match.
If you're still mapping the bigger picture, it helps to know what a Statement of Work is before you tighten this one paragraph inside it.
Scope statement vs scope of work vs deliverables
These three terms get used interchangeably, and they shouldn't be. They answer three different questions: what's the boundary, what's the full description, and what are the outputs.
| Term | What it is | Example |
|---|---|---|
Scope statement | The boundary - what's in, what's out, and the assumptions that hold | "We will redesign the marketing site (8 pages). Blog migration is out of scope." |
Scope of work | The fuller narrative of the work, methods, and phases | "Discovery, wireframes, design, build, and one round of revisions across four sprints." |
Deliverables | The concrete outputs the client receives | "Figma files, a staged build, and a handover doc." |
They're related but distinct. The scope statement draws the line; the scope of work describes the journey inside it; the deliverables are what crosses the finish line. If you want the full side-by-side, we cover statement of work vs scope of work on its own page rather than re-arguing it here.
What to include in a scope statement
A scope statement that holds up has a predictable shape. Work through these six elements in order, and you'll have a boundary that's hard to misread.
- Objective. One or two sentences on what the project sets out to achieve, in plain terms.
- In-scope work. A specific list of what you will deliver. Name quantities, page counts, rounds, or environments wherever you can.
- Out-of-scope exclusions. An explicit list of what you will not do, even when a reader might assume it's included.
- Assumptions. The conditions you're counting on - client-supplied content, access, sign-off timelines - that make the estimate valid.
- Constraints. The fixed limits the work runs inside, such as budget, deadline, platform, or compliance rules.
- Dependencies. What you need from the client or a third party, and by when, for the work to proceed.
Together these six turn a vague promise into a defined boundary. The next section makes the case that one of them carries more weight than the rest.
Why the out-of-scope list matters most
Most disputes start with something the client assumed was included.
The out-of-scope list is the cheapest dispute insurance in the document. An inclusions list tells people what they're getting; an exclusions list closes the gaps where expectations quietly drift. It costs you a few minutes to write and can save you a tense call about work you never agreed to do for free.
For a sample website redesign, a tight exclusions list might read:
- Content writing - we'll place client-supplied copy; we won't write it.
- Blog post migration - the existing blog stays on its current platform.
- Ongoing maintenance - support after launch is a separate retainer.
- Third-party license fees - plugins or stock assets are billed to the client.
Each line is a small fence. Put up enough of them and the boundary tends to hold under pressure.
How to write a scope statement step by step
You don't need to invent the structure from scratch. Follow these five steps and the section comes together quickly.
- State the objective. Write one or two sentences on the outcome, in language the client would use.
- List the inclusions. Spell out the in-scope work with quantities and limits, not adjectives.
- Mirror them with exclusions. For each inclusion, ask "what nearby thing am I not doing?" and write the out-of-scope line.
- Capture assumptions and constraints. Record what has to be true for the estimate to hold, and the fixed limits you're working within.
- Confirm every deliverable falls inside the boundary. Cross-check against the deliverables section so nothing you've promised sits outside the line you just drew.
That last step is the quiet quality gate. If a deliverable lives outside your scope statement, one of the two is wrong - fix it before the SOW goes out.
A fillable scope statement example you can copy
Here's a real, copyable boundary statement. Swap the bracketed parts for your project and you're most of the way there.
Scope statement. [Vendor] will [redesign the marketing website, 8 pages] for [Client] to [improve conversion and refresh the brand]. In scope: [design and build of 8 responsive pages, one round of revisions, and staging deployment]. Out of scope: [content writing, blog migration, ongoing maintenance, and third-party license fees]. This estimate assumes [the client supplies final copy and brand assets within 10 business days and provides timely sign-off at each milestone]. Constraints: [a fixed launch date of (date) and the existing CMS platform].
Pair it with an in/out table so the boundary is scannable at a glance:
| In scope | Out of scope |
|---|---|
Design and build of 8 pages | Content writing |
One round of revisions | Blog post migration |
Staging deployment | Ongoing maintenance |
Handover documentation | |
New feature requests after sign-off |
Keep it specific to your project. When the boundary feels right, build the whole SOW with the generator so the rest of the document lines up with it.
Why a fuzzy boundary causes scope creep
A vague boundary is one of the leading ways scope creep gets in. When "redesign the site" isn't pinned to a page count, every extra page can feel like it belonged in the project all along.
The cost is real and common. PMI's 2018 Pulse of the Profession found that 52% of all projects face scope creep. A sharp scope statement won't make that number disappear, but it gives you the written line you need to route new requests through the change-order process instead of absorbing them.
Common mistakes in the scope statement
A few patterns show up again and again. Watch for these:
- No exclusions. An inclusions-only statement leaves every gap open to interpretation.
- A vague objective. "Improve the website" can mean almost anything; tie it to something measurable.
- Hidden assumptions. If the estimate depends on it, write it down - don't keep it in your head.
- Scope mixed into the deliverables list. The boundary and the outputs are different sections; blending them blurs both.
- Boilerplate that doesn't match the project. Reused language that names the wrong work is worse than no language at all.
How the scope statement connects to the rest of your SOW
The scope statement is the section everything else leans on. The boundary drives the deliverables, governs which requests become change orders, and frames how you'll agree the work is done. Draw it well and the rest of the document tends to fall into place.
Once your SOW is drafted, send it for signature and track approvals in PandaDoc. CreateMySOW builds the document; PandaDoc gets it signed and keeps the approval trail in one place.
