Software Statement of Work (SOW) Template and Guide
ยท 9 min read
A software statement of work (SOW) describes what will be built, what will be delivered, how each delivery is accepted, when it happens and how changes are handled. The template below has twelve sections you can copy into your own document, with plain guidance on what to write in each. It is meant for build work that follows a discovery phase, when the scope is known well enough to describe.
This article is practical guidance, not legal advice. Have a lawyer review any contract, SOW or master agreement before you sign it.
What a software SOW covers
The project management body of knowledge (PMBOK) defines a statement of work as "a narrative description of products or services to be supplied under contract", as quoted in this university procurement guide. For software, that narrative answers six questions:
- Why is the work being done (background and objectives)?
- What is in scope, and what is explicitly not?
- What will be handed over (deliverables)?
- How does the client decide a deliverable is done (acceptance)?
- When does each part happen (milestones)?
- What happens when the scope changes?
In many client relationships the SOW sits under a master services agreement (MSA). The MSA holds the legal terms that apply to all work: liability, confidentiality, intellectual property, governing law. Each SOW then describes one project. If you have an MSA, keep legal wording there and keep the SOW about the work. If you do not, the gap is a reason to talk to a lawyer, not to paste clauses from the internet.
The template, section by section
Copy the headings below. The notes under each say what belongs there.
| No. | Section | What to write |
|---|---|---|
| 1 | Parties and references | Who the client and supplier are, the agreement this SOW falls under, a version number and date |
| 2 | Background | Two or three paragraphs on the business and why the project exists |
| 3 | Objectives | The goals the work supports, with the measures you will use |
| 4 | Scope of work | What will be built: features, platforms, integrations |
| 5 | Out of scope | What will not be built or done under this SOW |
| 6 | Assumptions and dependencies | What the plan relies on: access, client inputs, third-party systems |
| 7 | Deliverables | Each item handed over, with its format |
| 8 | Acceptance | How and by whom each deliverable is checked, and how long that takes |
| 9 | Milestones and schedule | Phases, dates or durations, and what ends each one |
| 10 | Roles and responsibilities | Named contacts on both sides, who decides what |
| 11 | Change control | How a change is requested, estimated, approved and recorded |
| 12 | Fees and payment schedule | The commercial model and when invoices are due |
Keep the language concrete. "A responsive web application" is weaker than "a web application that supports the latest two versions of the major desktop and mobile browsers, at 375 px wide and up".
Scope: in, out and assumptions
Scope is where most disputes start, so spend the most time here.
In scope should list features at the level of user-visible capability, not tasks. For example:
- Technicians can see their visits for the day, record work, parts and photos, and capture a customer signature.
- The app works without a network connection and syncs when one is available.
- Visits are read from and written to the client's existing dispatch system through its API.
Point to the requirements list (as an appendix or a referenced document) rather than copying every requirement into the SOW. A line such as "the Must requirements in Appendix A, version 1.3" is precise and keeps the SOW readable.
Out of scope is just as important. Name the things a reasonable client might expect but will not get: data migration from an old system, an admin console, a second language, store submission, ongoing hosting, support after the warranty period.
Assumptions and dependencies turn hidden risks into stated ones:
- The client provides API access and test credentials by a stated date.
- The dispatch system's API supports creating and closing visits.
- One named product owner on the client side answers questions within two working days.
- Designs are approved before development of each milestone starts.
If an assumption turns out to be false, the change control section (below) applies. That link is what makes assumptions useful rather than decorative.
Deliverables, acceptance and milestones
A deliverable is something the client receives and can check. Software, source code in a named repository, deployment scripts, test reports, a handover document and training sessions can all be deliverables. "Development" is not.
For each deliverable, state:
- What it is and in which form (a build in a named environment, a document, a recording).
- Acceptance criteria: what has to be true for it to count as done. For software, this is usually "passes the acceptance criteria of the requirements in scope for this milestone" plus agreed quality checks.
- Review period: how many working days the client has to accept or list defects, and what happens if they do neither. Many SOWs treat silence after the period as acceptance; whether that suits you is a point to agree, not assume.
- Defect handling: which issues block acceptance (for example, a Must requirement fails) and which go to a fix list.
Milestones then group deliverables in time. A useful milestone ends with something the client can see and test, such as "offline visit recording works end to end in the test environment", rather than "backend 50% complete".
A discovery roadmap gives you most of this section. The example below is from a report for Fieldwise, an invented field-service app (all names and figures are made up): four milestones, each with an effort range and a target date, and the assumptions the estimate depends on.
Give durations or date ranges, and state what they assume. Estimates made early in a project carry wide uncertainty; Construx's cone of uncertainty explains why commitments made before requirements are clear tend to miss. That is one reason to write the SOW after discovery, not before it.
Change control and payment terms (what to decide, not legal wording)
You do not need legal language to agree on how the project will behave. You need answers to a short list of questions, which a lawyer can then put into the right form.
Change control
- Who can request a change, and in what form (a written change request with a description and a reason)?
- Who estimates its effect on cost, schedule and other scope, and how quickly?
- Who can approve it on each side?
- Does work on the change start before approval? (Usually not.)
- Where are approved changes recorded, so the SOW plus its changes always describes the current agreement?
Payment
- Which model: fixed price per milestone, time and materials against a rate card, or a capped time-and-materials budget?
- What triggers an invoice: a date, a milestone being accepted, or monthly hours?
- What happens to payment if acceptance is delayed by the client?
- How are expenses handled, if at all?
Fixed price works when scope is well defined and changes go through change control. Time and materials suits work where scope is expected to move. Either way, the payment schedule should line up with the milestones above, so payments follow visible progress.
Using the discovery output to fill it in
A finished discovery already contains most of what an SOW needs. The mapping is close to one to one:
| SOW section | Discovery output it comes from |
|---|---|
| Background | Background and problem statement |
| Objectives | Goals and success metrics |
| Scope of work | Requirements (Must and Should), users, journeys and flows |
| Out of scope | Requirements marked Won't, and anything agreed as excluded |
| Assumptions and dependencies | Roadmap assumptions, integrations from the architecture |
| Deliverables and acceptance | Requirements' acceptance criteria, UI screens |
| Milestones | Roadmap milestones with effort ranges and dependencies |
| Roles | Stakeholders, with who decides |
| Risks to note | Risks, blockers and open questions |
Open questions deserve a specific mention. If something important is still unanswered when the SOW is drafted, either answer it first or write it down as an assumption with a change-control consequence. An unanswered question left out of the SOW tends to become a dispute. In the Fieldwise example, a blocker such as "IT needs to expose two new dispatch API endpoints; no date is agreed yet" belongs in the SOW's dependencies, with what happens if the date slips:
If you need a structure for the discovery itself, the discovery phase template lists the ten sections. The full Fieldwise example report shows how a completed discovery's requirements, roadmap and risks would feed the sections above. Discovery Phase AI produces that kind of report as Markdown, PDF, Word or PowerPoint, which you can attach to or reference from the SOW, but the SOW itself is a document you and your client write and sign.
For background on why the discovery comes first, see the discovery phase in software development.