What is a scope of work, and who pays when it changes.
Every definition of a scope of work treats it as a planning document. It's really a payment document, and you find that out on the day a client asks for something the scope never named.
A scope of work is the document that describes exactly what an agency is delivering on a project: the work itself, what's excluded from it, when each piece arrives, and what has to be true before a piece counts as finished. It gets written as a planning document and it gets used as a payment document. The first time a client asks for something the scope never named, whatever that document says decides whether the next three weeks get billed or absorbed.
What is a scope of work?
A scope of work is a written description of the work a client is buying, specific enough that either side can check a later request against it. It names the deliverables, draws the boundary around them, sets the dates they arrive on and states the standard each one has to meet. In agency work it rarely stands alone. It usually sits inside a statement of work, or attaches to a contract as an appendix, describing the work itself while the surrounding paperwork handles payment terms, ownership and what happens if either side walks away.
The term gets used loosely enough that naming what a scope of work isn't does about as much work as the definition. An estimate prices work nobody has described closely enough to price properly, and a proposal argues for an approach while the client is still deciding, whereas a scope of work assumes the deciding is finished and the number is fixed. It also isn't the contract, though it almost always travels attached to one, and knowing how those two documents connect is what settles things when they appear to say different things.
It also goes by several other names, some of which mean the same document and some of which don't.
What is another word for scope of work?
The closest is statement of work, and it isn't quite a synonym. These are the names you'll meet on client work, and which of them you can treat as the same thing:
| Name | Same document? | Who uses it |
|---|---|---|
| Statement of work (SOW) | Different: the same description wrapped in the fee schedule, invoicing dates and approval rules | Agencies, consultancies, procurement teams |
| Project scope | Usually the same, and often the heading a scope of work sits under | Agencies and in-house teams |
| Work description | The same document under an informal name | Freelancers and small studios |
| Terms of reference | Close: the same job for advisory and research work, adding objectives and reporting lines | Governments, nonprofits, consultants |
| Scope statement | Different: a short unpriced summary of the scope inside a project plan | Project managers |
| Specification | Different: the technical requirements a deliverable must meet, which a scope of work can point to | Engineering, manufacturing, construction |
What does a scope of work actually decide?
It decides who pays for the next request. The clearer expectations and the calmer planning that everyone attributes to a good scope are downstream of that single function, and it's the function that goes missing whenever the document gets described as a planning tool.
Some weeks in, a client asks for something and somebody opens the scope to see whether it's covered. Either the description is loose enough that the request reads as included, and you build it for nothing, or it's specific enough that the request sits visibly outside it, and you price it and the total moves. It only turns adversarial when the document can't answer the question and both people argue from memory.
Money leaks through that gap continuously rather than dramatically. One absorbed request feels like goodwill, and the same request on every project for a year is a line item you never billed, and what that pattern costs an agency is worth reading with your own numbers next to it.
A scope of work is written to plan the project and read to price an argument.
What should be included in a scope of work?
Eight sections, and whether each one is countable matters more than the order they appear in:
- Overview. One paragraph on what the client is trying to achieve, so later judgment calls have something to be judged against.
- Deliverables, with counts. Named and counted rather than described, because six tracking screens is checkable and a tracking experience is not.
- Acceptance conditions. The test each deliverable has to pass before it counts as done, and who applies it.
- Schedule. Dates attached to deliverables rather than to weeks, plus the limits the fee was priced under.
- Exclusions. What's out, each with a price if it's added later.
- Assumptions. What the client supplies and when, since timelines usually slip on content or access that never arrived.
- Change procedure. What happens when somebody asks for work that isn't on the list.
- Fee basis. Fixed, per unit or time and materials, with the unit rates that price anything extra.
One technique makes the rest easier: write the exclusions first. Deciding what's out before listing what's in forces the boundary into the open, which is why drawing the line between in scope and out of scope comes before counting deliverables.
Two of those get written badly almost everywhere. Deliverables get described instead of counted, and exclusions get written as a list of refusals instead of a priced menu. For the section by section version, with the vague line sitting next to the rewritten line that holds, how to write a scope of work covers each one in order, and a scope of work format filled in as a sample shows the finished shape on the page.
Who writes the scope of work, the client or the agency?
The agency, in almost every case, because it's the side that knows how the work breaks down and what a realistic count of screens, pages or rounds is. The client's job is to read it line by line before signing, with most attention on the exclusions and the acceptance conditions.
The exception is a client with a procurement team, which often drafts its own scope and sends it out with a request for proposals. The workable pattern then is a hybrid: the client drafts and the agency redlines, adding the counts, exclusions and change procedure the draft usually lacks, and both sides sign the merged version. Sign a client draft without redlining it and you've agreed to price their description of the work rather than yours.
What does a scope of work look like on a real project?
Take Halden Freight Co., a regional shipping company whose customers currently call a phone line to ask where a container is. They want a portal those customers can sign into instead. The engagement is nine weeks at $19,700 fixed, and the deliverables section reads as four priced lines rather than as a paragraph about a portal.
Shipment tracking screens, six at $1,450 each: $8,700
Email and text notification system: $3,900
Admin views, documentation and handover: $4,500
Total, nine weeks: $19,700
Every number in there is doing a second job. The per screen rate exists so that a seventh screen already has a price before anybody asks for one, and the four lines together mean that when a request arrives there's a unit sitting ready to attach it to. A scope that says build a customer portal for $19,700 is the same deal and answers none of the questions to come. Halden's portal is a software build, and the same four lines carried through a larger one, with the acceptance and change wording a development engagement needs, are written out in our software development scope of work template.
What happens when the client asks for something the scope doesn't name?
You price it, the client approves it in writing, and the work starts after that rather than before it. On the Halden project the request lands in week six and it's a perfectly reasonable one: since customers are signing in anyway, can they see their invoices in here and pay them?
Read against a scope that promised a customer portal, that request is arguably included, and the argument is unwinnable because both readings are honest. Read against the four lines above, it's two screens the scope never listed plus a payment connection nobody priced, which comes to $2,900 for the screens at the stated rate and $1,200 for the payment work. That's $4,100, a little over a fifth of the original fee, and two weeks added to a nine week schedule. The difference between billing that and swallowing it isn't the client's goodwill on the day. It's one paragraph written seven weeks earlier.
Written that way, the exclusion stops being a refusal and becomes a price the client can say yes to, so the week six conversation is a purchase rather than a disappointment.
The change procedure is the other half of the same mechanism: requests outside the scope get quoted in writing, work begins after written approval, and approval means a reply from a named person rather than a nod in a status call. Agencies running a standing change request form tend to get this right, because the form makes that sequence the default.
Does every project need a scope of work?
No, and writing a full one for every job is how agencies end up with a template nobody fills in properly. The threshold sits roughly here: one deliverable, under about $5,000, under two weeks, one person on the client side who can approve things. Below all four, a paragraph in the confirming email does the same work if it names the deliverable, the revision rounds and what another round costs. Above that line, or the moment more than one person on the client side has an opinion, write it down.
A scope of work is a payment document that reads like a plan
Write it with that in mind and the sections stop being a checklist. Deliverables get counted because a count is what you bill against, exclusions carry prices because a client can accept a price where they can only resent a refusal, and acceptance conditions exist because otherwise finished is an opinion.
None of that makes the document enforceable on its own, and that isn't its job. It strips out the ambiguity that turns a routine request into a negotiation, so Halden's week six request is a $4,100 quote instead of a disagreement about what the word portal meant. If you're starting from a blank page, the section by section version is the next thing to read, and a project scope printed in full shows what a finished one looks like from top to bottom.
Frequently asked questions
What is a scope of work?
A scope of work is a written description of what an agency is delivering on a project: the deliverables counted rather than described, the work explicitly excluded from them, the dates each piece arrives, and the test each one has to pass before it counts as finished. It rarely stands on its own, and usually sits inside a statement of work or attaches to a contract as the section covering the work itself.
What does "beyond my scope of work" mean?
It means the request falls outside the work someone agreed to do, so nobody has priced it or approved it yet. In client work the phrase only carries weight if the scope of work drew the boundary in advance, which is why a priced exclusions section does more for you than the sentence you say in the moment.
What does the scope of a job mean?
The scope of a job, or of a role, is the set of responsibilities an employee is hired to cover, and it lives in a job description. A scope of work in the contracting sense is different: it describes the deliverables a client is buying from an outside supplier, with counts, dates and a price. When someone says a request is beyond their scope, the first sense is about their role and the second is about what a contract covers.
What should be included in a scope of work?
Eight sections: an overview of what the client is trying to achieve, the deliverables named and counted, acceptance conditions for each, a schedule tied to deliverables rather than weeks, the exclusions with a price on each, the assumptions about what the client supplies, a change procedure, and the fee basis with its unit rates.
What's the difference between a scope of work and a statement of work?
A scope of work covers what gets built, while a statement of work wraps that same description in the commercial terms: the fee schedule, the invoicing dates and the rules about whose approval counts. Many small agencies write a single document and use either name for it, which works as long as the sections that decide money are genuinely in there.
Is a scope of work legally binding?
On its own a scope of work is a description rather than an agreement, so whatever weight it carries comes from the contract or statement of work it's attached to and the signatures on that. Wording and local law change the answer, so have your own template read by a lawyer in your state. What a specific scope reliably does, separately from any question of enforceability, is remove the ambiguity that makes the argument possible in the first place.
Who writes the scope of work, the client or the agency?
The agency writes it in almost every case, because the agency is the side that knows how the work breaks down and what a realistic count of screens, pages or rounds looks like. The client should still read it line by line before signing, and the sections worth their attention are the exclusions and the acceptance criteria, since those two decide what they get and what they'll be asked to pay for later.