In short
- A scope of work turns an idea into a document both sides can check against: what, when, how much, and what is out.
- Exclusions and acceptance criteria prevent more disputes than any other part.
- A good scope describes workflows, written plainly enough for a non-engineer to follow.
- It needs a change process, because every project learns something along the way.
Also called: SOW, Statement of work, Project scope, Written scope.
What a scope of work is
A scope of work, often shortened to SOW, is the document a software project is priced and judged against. It names the deliverables, the platforms, the workflows a user will be able to complete, the timeline, the payment schedule, and the things deliberately left out. For a fixed-price project it is what the price is fixed to. For hourly work it still gives both sides a shared picture of the goal.
A scope is different from a proposal. A proposal sells an approach. A scope commits to a result, in enough detail that someone outside the project could read it and say whether it was delivered.
One document, many uses
- PriceSet against what is written
- TimelineMilestones and the launch date
- AcceptanceWhen a deliverable counts as done
- ChangesMeasured against the original
- OwnershipWhen the code and designs are yours
What a good scope contains
| Part | What it says | Example of the right detail |
|---|---|---|
| Deliverables | What you receive at the end | Web app, iOS app, source code, design files |
| Platforms | Where it runs | Web for desktop and mobile browsers, plus iOS |
| Workflows | What a user can do, start to finish | A customer books a slot, pays, and gets a confirmation email |
| Exclusions | What is not included | No Android app or second language in this phase |
| Timeline | Milestones and the end date | Prototype in week one, launch in week six |
| Payment | Total, schedule, and what triggers each payment | Half at the start, half at acceptance |
| Acceptance | How you decide a deliverable is done | Each listed workflow works on the agreed devices |
| Ownership | Who owns the designs and code, and when | Client owns everything once the final payment clears |
| Change process | How new requests are priced and approved | Written request, a quote, then client approval |
Workflows deserve the most care. "User accounts" is a feature. "A new user signs up with email, confirms the address, and lands on a dashboard with one clear next step" is a workflow, and it can be built, priced, and tested.
How a scope gets written
From first call to signed scope
- 01DiscoveryAgree on the user and the job
- 02Draft scopeStudio writes it in plain words
- 03Review togetherClient marks anything unclear
- 04Fixed totalPrice set against the final text
- 05Sign and startChanges go through a request
The first draft usually comes from the studio after a product discovery call or workshop. The most useful thing a client can do is read it slowly and mark every sentence they might read differently from the studio. Then ask for those sentences to be rewritten until both sides mean the same thing.
At Choie, the written scope arrives within two days of a 30-minute intro call, with deliverables, dates, a fixed price, and the payment split. The people who write it are the people who will design and build the work, so nothing in it is a promise made on someone else's behalf.
Common gaps
- Missing exclusions. If the scope does not say something is out, the client will reasonably assume it is in.
- Features without workflows. "Notifications" can mean one email or a full preferences screen. Describe what the user experiences.
- No acceptance criteria. Without them, deciding what counts as done turns into a negotiation just as the final invoice is due.
- Vague content and data. Who writes the copy, who supplies the images, and who moves the old data across are often left out, and they take real time.
- Third-party services left unmentioned. Payment providers, email services, app store accounts, and hosting all have setup steps and running costs.
- Silence on ownership. The scope or contract should state when the code and designs become yours. Our guide on who owns the code covers what to look for.
A simple checklist
Before you sign, check that each of these is true from the document alone, without relying on what was said in a meeting.
- Every deliverable is listed by name.
- The platforms and devices are named.
- Each user workflow is described from start to finish.
- What is out of scope is written down.
- The timeline has dates or week numbers.
- The total, the payment schedule, and the trigger for each payment are clear.
- There is a test for when a deliverable counts as done.
- It says when the code and designs become yours.
- There is a written process for changes.
Work at Choie starts once the scope is accepted in writing and the first payment is in, and no tax is added on top of any price. Once the fees for a deliverable are paid, the designs and source code are the client's. The pricing page and how a project runs show the details.
Common questions
Who writes the scope of work?
Usually the studio or contractor writes it, after discovery conversations with the client. The client's job is to read it closely, question anything unclear, and confirm it matches what they need before signing.
Is a scope of work the same as a statement of work?
In everyday use, mostly yes. Both are shortened to SOW and both describe what will be delivered. In some contracts, the statement of work is the whole formal document and the scope of work is the section that lists the work.
How long should a scope of work be?
Long enough to describe every deliverable and workflow without ambiguity, and no longer. For a focused first release that is often a few pages. What matters is whether someone outside the project could use it to judge if the work was delivered.
What if the scope needs to change after signing?
Use the change process the scope describes. The change is written up, priced, and approved before work on it starts, and the timeline moves if it needs to. Choie agrees every change in writing too, and a change may move the price or the timeline.