SOW Template for Engineering Projects
Updated: Oct 19
A statement of work for a software engagement says "integration with the customer's billing system." Everyone signs. To the supplier, that means a webhook that pushes each new invoice to the billing system. To the customer, it means real-time, two-way sync with nightly reconciliation and error handling. That's a project several times larger. Both sides find out in week six. The argument over who absorbs the difference costs more goodwill than the change order that eventually settles it.
This is a composite, but the shape is common. One noun carried two incompatible projects, and the SOW had nowhere that forced anyone to say which one they meant.
A statement of work (SOW) is the written agreement on what's being delivered, by when, for what cost and under what conditions. Its real job isn't legal cover. It's to drag that kind of ambiguity into the open before anyone writes code, while both sides still want to define terms honestly. It's most associated with supplier contracts, but a lighter internal version between teams works the same way. This post gives you the template and the five places SOWs most often fail.
When to write one
Situation | SOW? | Notes |
Supplier, contractor or agency engagement | Yes | Alongside the contract; have counsel review the legal terms |
Formal commitment between internal teams | Yes, lighter | Skip pricing; keep scope, deliverables, acceptance, dependencies |
Discovery where the scope is genuinely unknown | Short one, for the discovery only | Its deliverable is the definition the next SOW needs |
Routine team work, short tasks | No | A ticket is enough |
If you're choosing between suppliers, the RFP Template for Software Vendor Selection comes first. If the work is internal and you haven't agreed what "done" means, write a project charter first.
The template
# Statement of Work: [Project name]
Version: [1.0] Date: [YYYY-MM-DD] Effective: [start date]
Parties: [names, teams or organisations; one named contact each]
1. Background: why this work exists, in plain language
2. Objectives: the outcomes it serves (not the deliverables)
3. Definitions: every term that could be read two ways, defined
4. Scope
In scope: [bullets, using the defined terms]
Out of scope: [the things either side might assume are included]
5. Deliverables: D1, D2 ... each with description, example,
acceptance criteria, due milestone
6. Timeline: milestones and dates, with a review at each
7. Responsibilities: who provides environments, data, design,
testing, deployment, support after launch
8. Assumptions: each with what happens if it proves false
9. Dependencies: what the work needs from outside, owner and date
10. Acceptance process: who tests, with what, how long, what
counts as acceptance or rejection
11. Pricing and payment: model, amounts or rates, ceiling,
what triggers an invoice
12. Change process: how a change is requested, sized, approved
13. Risks: known risks, owner, mitigation
Five to fifteen pages is typical. The length should come from definitions and acceptance criteria, which prevent disputes, not from boilerplate, which doesn't.
1. Define the nouns both sides will read differently
The billing dispute wasn't caused by a missing section. It was caused by an undefined word in a section everyone read. Before anything is signed, go through the scope and the deliverables and circle every noun that could describe projects of very different sizes: "integration", "migration", "dashboard", "support", "reporting", "admin", "real-time". Each one goes into the definitions section with the decisions that set its size.
For "integration", those decisions are direction, timing, volume, failure handling and reconciliation:
Billing integration (D3) means:
Direction: one way, our system to the customer's billing system
Trigger: on invoice creation; no batch backfill of past invoices
Volume: up to 5,000 invoices a day
Failures: retried 3 times over 1 hour, then listed on an
exceptions report for the customer's finance team
Reconciliation: not included (see Out of scope)
Example: invoice INV-1042 for 3 line items appears in the
billing system within 5 minutes, with matching totals
The example line does as much work as the rest. A concrete input and expected output is very hard for two people to read differently.
The test: give the scope section to one person on each side and ask each to describe deliverable D3 in their own words, separately. If the descriptions would cost different amounts to build, the term isn't defined yet.
2. Describe results, not hours or methods
US federal acquisition rules give a useful discipline for this. FAR 37.602 asks agencies, where practicable, to "describe the work in terms of the required results rather than either 'how' the work is to be accomplished or the number of hours to be provided", and to assess performance against measurable standards.
For an engineering SOW, that means each deliverable states what will exist and how you'll know it works, not the activity that produces it. "Two developers for eight weeks on onboarding" is a resourcing plan. "A self-service onboarding wizard that 90% of test admins complete in under 10 minutes" is a deliverable.
D1: Self-service onboarding wizard
Description: web flow that takes a new admin through SSO setup,
user invitation and connecting one integration
Example: a new admin at a 50-person customer completes all steps
and invites 50 users from a CSV
Acceptance criteria:
- All 5 steps work in production for the customer's identity provider
- Works in current Chrome, Edge and Safari, desktop and mobile
- 90% of 10 test admins complete it in under 10 minutes, unassisted
- Support runbook delivered and walked through with the support lead
Due: milestone 2 (week 8)
The test: for each deliverable, could someone who wasn't in the negotiation decide on the due date whether it was delivered, using only the SOW? If they'd need to ask what was meant, the deliverable describes an activity, not a result.
3. Make acceptance end
Acceptance is where payment and goodwill meet, and the commonest failure is that it never formally finishes. "We're still testing" can stretch for weeks while invoices wait and the team moves on. The acceptance process needs four things written down:
Who tests, named by role, and with what data and environment.
How long they have: a fixed review window per deliverable.
What happens when the window closes: acceptance is deemed to occur if no written rejection arrives in time.
What a rejection must contain: specific failures against the stated criteria, not "it doesn't feel finished".
Acceptance: the customer's product owner tests each deliverable in
staging with the agreed test data set within 5 business days of
delivery notice. The deliverable is accepted when its criteria are met,
or if no written rejection is received within 5 business days.
A rejection must list each criterion not met; the supplier fixes and
redelivers, and a new 5-day window starts.
The test: for the next deliverable due, can you name the person who will accept it, the date the window closes, and what happens if they say nothing?
4. Tie every assumption to what happens if it's false
The assumptions section is the SOW's protection against scope creep, but only if each assumption says what follows when it fails. "The customer will provide staging access" is a wish. "If staging access isn't provided by day 5, the timeline moves day for day, and work beyond that is billed under the change process" is an agreement.
Good candidates for assumptions: access and environments, data quality and format, the stability of the other side's APIs, response times for decisions and reviews, and who provides designs or content.
The test: for each assumption, is there a sentence saying what happens to the timeline and the cost if it proves false, and who bears it? If not, you'll negotiate that in the middle of the project, when both sides have the least goodwill.
5. Choose the pricing model by how well defined the work is
The pricing model isn't just a commercial choice. It decides who carries the risk of the unknowns. US federal acquisition rules set out the trade-off plainly:
Model | Who carries the risk | Suits work that is | FAR reference |
Fixed price | The supplier: "maximum risk and full responsibility for all costs and resulting profit or loss" | Defined well enough to price, with reasonably definite specifications | 16.202-1, 16.202-2 |
Time and materials | The buyer: "no positive profit incentive to the contractor for cost control or labor efficiency" | Impossible to estimate accurately when the contract is placed | 16.601 |
Time and materials with a ceiling | Shared: the supplier exceeds the ceiling at its own risk | Uncertain, but with a budget limit both sides accept | 16.601(d) |
A supplier asked for a fixed price on vague scope will build the risk into the price, or will define the scope narrowly once work starts. That's how the billing dispute happened. If the work can't yet be defined well enough for a fixed price, split it: a short, time-and-materials discovery with a ceiling, whose deliverable is the definitions and acceptance criteria. Then a fixed-price SOW for the build.
For payment, say exactly what triggers each invoice (a date, a milestone delivered, or a milestone accepted) and the payment terms you agreed. Tying payment to acceptance gives the acceptance process real force.
The test: could both sides write the same acceptance tests for every deliverable today? If yes, fixed price is reasonable. If not, price the discovery first.
The change process
Every SOW changes. The change process decides whether changes are agreed or simply happen. The pattern: a written change request describing the change, its effect on deliverables, timeline and cost, approved in writing by a named person on each side, then added to the SOW as a numbered amendment.
Two clauses do most of the work. Nothing in scope changes without an approved change request, whatever was said in a meeting. And small changes still go through the process, even when no money changes hands, so the record matches reality.
The test: list the changes made since the SOW was signed. Does each have a written, approved change request? Any that don't are where the next dispute starts.
Internal SOWs
Between teams in the same organisation, the same sections earn their place without the commercial ones. A one- or two-page version with definitions, scope, deliverables with acceptance criteria, dependencies, responsibilities and a change process catches the same disagreements. "The platform team will provide an API" needs the same definition as "integration" does.
A worked example
Here are the key sections of the billing engagement from the opening, written to prevent the dispute. The figures are illustrative.
Statement of Work: Invoicing to Billing System Integration v1.2
Definitions
Billing integration: see D3 definition (one way, on creation,
up to 5,000/day, retries then exceptions report, no reconciliation)
Scope
In: D1 invoice event publisher; D2 field mapping for 3 invoice
types; D3 billing integration as defined; D4 exceptions report
Out: two-way sync; reconciliation; backfill of past invoices;
changes to the customer's billing configuration
Assumptions
A1 Sandbox access to the billing system by day 5. If late: timeline
moves day for day; idle time billed under the change process.
A2 Billing API version stays as at signature. If changed: rework
sized and agreed as a change request.
Acceptance
Customer finance lead tests each deliverable in staging with the
agreed 200-invoice data set; 5 business days; deemed accepted if no
written rejection listing failed criteria.
Pricing
Phase 0 discovery (done): T&M, ceiling 40 hours, produced the
definitions above
Phase 1 build: fixed price, invoiced 30% on D1 acceptance, 70% on
D3 and D4 acceptance
Change log
CR-01 Add credit notes to D2 mapping: +3 days, +fixed fee;
approved by both named contacts, 14 April
The reconciliation the customer wanted is still possible. It's now a visible, priced choice instead of a surprise in week six.
What to do this week
Take the SOW for your current or next engagement. Circle every noun in the scope and deliverables that could describe projects of different sizes, and write a definition with an example for each. Check that every deliverable has acceptance criteria someone outside the negotiation could apply, and that acceptance has a window and a deemed-acceptance clause. Add "if false" to every assumption. Then ask whether both sides could write the same acceptance tests today. If not, price a discovery first. When the supplier is still being chosen, the Vendor Evaluation Scorecard Template helps compare proposals against the same definitions.
Final takeaway
Most SOW disputes start with a word, not a section. Find the nouns that could describe projects of very different sizes, such as "integration", "migration" and "support", and define each with the decisions that set its size and a concrete example. Describe deliverables as results someone outside the negotiation could check, not hours or methods. Make acceptance end: a named tester, a fixed window, deemed acceptance and rejections tied to criteria. Write what happens when each assumption proves false. Choose fixed price only when both sides could write the same acceptance tests today, and price a discovery first when they can't. Then run every change through a written request, so the SOW still describes the project you're actually doing.
Sources
US Federal Acquisition Regulation (FAR) 37.602, Performance work statement: agencies shall, to the maximum extent practicable, "describe the work in terms of the required results rather than either 'how' the work is to be accomplished or the number of hours to be provided" and enable assessment against measurable performance standards. https://www.acquisition.gov/far/37.602
FAR 16.202-1 and 16.202-2, Firm-fixed-price contracts: places on the contractor "maximum risk and full responsibility for all costs and resulting profit or loss"; suitable where there are reasonably definite functional or detailed specifications and fair prices can be set at the outset. https://www.acquisition.gov/far/16.202-1, https://www.acquisition.gov/far/16.202-2
FAR 16.601, Time-and-materials contracts: "no positive profit incentive to the contractor for cost control or labor efficiency"; may be used only when it is not possible at the time of placing the contract to estimate accurately the extent or duration of the work; includes a ceiling price that the contractor exceeds at its own risk. https://www.acquisition.gov/far/16.601
Related reading
Part of the Engineering Templates & Playbooks guide — ShiftQuality's collection of ready-to-adapt templates.
