Statement of work template for software development
A statement of work (SOW) is the part of a contract that says exactly what a supplier will deliver to a client: the work, the deliverables, the dates, the price, and how the client accepts the result. For a software project it is the document every later argument comes back to — so it has to name what was agreed precisely enough to settle one. Below is a free template, what each section is for, and the clauses that matter most once the work starts. It is a working template, not legal advice: have a lawyer review the contract it sits in.
Someone says “looks good” and three weeks later there’s a dispute about whether that was formal acceptance or just a preliminary review. The signed SoW wins legally, but it almost never wins practically.
— r/projectmanagement, in a thread titled “In software delivery, when Jira, meeting notes, and the SoW disagree, what wins?”, July 2026
What a statement of work should include
- Parties, and the agreement it sits under — usually a master services agreement.
- Background and objectives: why the project exists, in two or three sentences.
- Scope of work: what will be done.
- Deliverables, each with its acceptance criteria.
- Out of scope: what is not included, especially what the client might assume.
- The requirements it is based on, named by version and attached.
- Assumptions and client responsibilities: access, content, decisions, response times.
- Schedule and milestones.
- Acceptance: how each deliverable is reviewed, by whom, and how long they have. At the end, a project sign-off confirms all of them.
- Change control: how changes are requested, priced and approved.
- Price and payment: the pricing model and the payment schedule, tied to milestones.
- Contacts and authority: who can approve what, on each side.
- Warranty and support after go-live.
- Signatures.
Statement of work vs scope of work vs MSA
| Document | What it is | How long it lasts |
|---|---|---|
| Master services agreement (MSA) | The legal terms for the whole relationship: liability, IP, confidentiality, payment terms | Years; covers many projects |
| Statement of work (SOW) | One project under the MSA: scope, deliverables, schedule, price, acceptance | One project |
| Scope of work | The section of the SOW that describes the work itself | Part of the SOW |
| Change order or change request | An agreed change to the SOW: what changes, what it costs, what moves | One change |
“Scope of work” and “statement of work” are often used for the same thing, and both are shortened to SOW. The difference matters only when someone asks where the price and the acceptance terms are: in a statement of work, they are in the same document. A project scope statement is the scope on its own, without the price and terms.
The template
Copy it into Google Docs or Word. Everything in square brackets is yours to fill in.
STATEMENT OF WORK [number]
Under: [master services agreement],
dated [date]
Client: [company], represented by
[name, role]
Supplier: [company], represented by
[name, role]
Project: [project name]
Version: [x.y] Date: [date]
1. BACKGROUND AND OBJECTIVES
[Why the project exists and what it
must achieve, in two or three
sentences.]
2. SCOPE OF WORK
[The work the supplier will do:
discovery, design, development,
testing, deployment, support.]
3. DELIVERABLES
D1 [deliverable]
Acceptance criteria: [how the
client will check it; or "the
acceptance criteria of requirements
[IDs] in the specification below"]
D2 [ ]
4. REQUIREMENTS
The deliverables are built to
[requirements document], version [x.y],
signed off on [date], attached as
Annex A.
5. OUT OF SCOPE
- [what is not included, that someone
might assume]
6. ASSUMPTIONS AND CLIENT RESPONSIBILITIES
- The client provides [access, content,
data] by [date].
- The client answers questions within
[n] working days.
- [any assumption the price depends on]
7. SCHEDULE AND MILESTONES
M1 [milestone] [date]
Deliverables: D1
M2 [ ] [date]
Deliverables: [ ]
8. ACCEPTANCE
- The client reviews each deliverable
within [n] working days of delivery.
- It is accepted when it meets its
acceptance criteria, confirmed in
writing by [name, role].
- [If no response within that time, the
deliverable is accepted.]
- Defects found later are handled as
[warranty fixes].
9. CHANGE CONTROL
- Any change to the scope, the
deliverables or the requirements is a
change request.
- The supplier answers each request
within [n] working days with its
effect on cost and dates.
- No change is worked on until
[name, role] approves it in writing.
10. PRICE AND PAYMENT
Pricing model: [fixed price / time and
materials / capped time
and materials]
Price: [amount], excluding
[taxes]
Payment: [share] on signing,
[share] on acceptance
of M1, [share] on
acceptance of M2
11. CONTACTS AND AUTHORITY
Client: [name, role]: approves
deliverables and changes
Supplier: [name, role]: delivery lead
12. WARRANTY AND SUPPORT
[Period after go-live, what is covered,
response times.]
SIGNATURES
Client: [name, role] Date: [ ]
Supplier: [name, role] Date: [ ]
The clauses that matter once work starts
The requirements, by version. “Annex A, version 1.0, signed off on 28 January” settles arguments that “the requirements” never will. One commenter’s advice: “Requirements should be part of contract as detailed as possible via attachments, and then block milestone payments as others said” (r/projectmanagement, 2025). The requirements sign-off template produces that version.
Out of scope. What is not included is as important as what is. Written down, it heads off “but we assumed” conversations.
Acceptance, with a time limit. A review window, written acceptance, and — if both sides agree — what silence means. On large programmes: “Base contract says explicitly that silence is consent” (r/projectmanagement, 2026). The UAT sign-off template is the acceptance document at the end.
Change control. Who may ask, how a request is priced, who approves it, and that nothing is worked on before approval. Without it, small favours add up: “over a few weeks you’re effectively running a different contract than the one you priced” (r/agency, 2026). See the change request template, change request vs pull request and scope creep.
Statement of work for agile software development
A fixed scope at a fixed price assumes the requirements are known at the start. In agile work they are not, so the SOW fixes something else:
| Model | What is fixed | What moves | Suits |
|---|---|---|---|
| Fixed price, fixed scope | Scope, price, dates | Nothing without a change request | Well-understood work, after a discovery phase |
| Time and materials | The rate and the team | Scope, total cost | Work whose scope will be found along the way |
| Capped time and materials | The rate and a ceiling | Scope, within the ceiling | A middle ground for both sides |
| Fixed capacity (sprints) | Team size and number of sprints | What is built, chosen sprint by sprint | Product work with a product owner on the client side |
Fixed price needs the most precise SOW. Someone who prefers fixed-price projects: “The problem with fixed price is that you need a very solid specification and contract. If you don’t clients will scope creep on you” (Hacker News, 2021). A discovery phase is one way to get there.
In an agile SOW, the acceptance clause names what is accepted per sprint or release, and the change clause says how the backlog is reprioritised — who decides, and what happens to work that is swapped out.
How to write a statement of work
- Start from signed-off requirements, or run a discovery phase first.
- List the deliverables one by one, each with how the client will check it.
- Write out of scope with the client, out loud.
- Write down every assumption the price depends on.
- Tie each payment to a milestone, and each milestone to deliverables.
- Write the acceptance and change clauses before anything else is negotiated.
- Name the people who can approve, on both sides.
- Version the SOW, and attach the requirements it refers to.
Why statements of work fail in practice
The SOW is signed once; the project changes every week. The thread quoted above opened like this:
Each stage has its own version of “what was agreed.” The SoW says one thing, the delivery tool says another, acceptance often happens informally on a call, and by invoicing time nobody can point to a clean record of what’s actually owed or why.
— r/projectmanagement, July 2026
Another reply: “SoW should legally win but in practice whoever has the clearest contemporaneous record wins the actual argument” (r/projectmanagement). And the number of change requests says something about the SOW itself: “The more change request you have the more you know that your business case or original SOW is unfit for purpose” (r/projectmanagement, 2026).
Keep the record as you go: every approved change as a new version of the requirements, every acceptance in writing, each tied to the SOW it amends.
Where Specroot fits
This is the problem Specroot works on: a statement of work whose requirements stay one agreed, versioned record — with every change and every acceptance tied to it — instead of a document that the delivery tools quietly overtake. Specroot for agencies and consultancies.
Read next
- Discovery phase in software development: what the client should sign off — What the discovery phase of a software project is, what it produces, the questions to ask, and what the client should sign off before development starts.
- Change request vs pull request — A change request changes what was agreed; a pull request changes the code. Scope creep vs change requests, change orders, and the change request process.
- Requirements sign-off template — A free requirements sign-off template and email to copy: what to include, how to get a client to actually sign off, and what to do at the first change.