The statement of work is where good intentions become obligations. It is also the last inexpensive moment to prevent a dispute — because everything left ambiguous in the SOW will be resolved later, under pressure, in whichever party's favour holds the leverage. A thorough SOW is not bureaucracy; it is the cheapest insurance a software buyer can buy.
Scope — and its boundary
A good SOW defines not only what is included but what is explicitly excluded. The exclusions are where change requests originate. If the boundary of scope is left implicit, every later disagreement becomes a negotiation you are likely to lose, because you are already committed.
Acceptance criteria
For every deliverable, the SOW should state how it will be judged complete — objectively, in terms both parties can verify. Without acceptance criteria, 'done' becomes a matter of opinion, and the party being paid tends to have the more optimistic one.
The clauses buyers most often miss
- Non-functional requirements — performance, security, availability and scalability as measurable targets, not adjectives.
- Change control — how changes are requested, priced and approved, agreed before the first one arrives.
- Intellectual property — unambiguous ownership of code, assets and credentials on payment.
- Warranty and defect resolution — who fixes what, for how long, at whose cost, after delivery.
- Documentation and handover — the material required for you or another vendor to take the software forward.
- Exit and transition — what happens, and who owns what, if the relationship ends early.
Everything a statement of work leaves ambiguous will be resolved later — under pressure, and rarely in the buyer's favour.
The commercial and technical substance of an SOW should be right before it reaches a lawyer for drafting. Getting the requirement, the acceptance criteria and the non-functional targets defined first is exactly the work that protects the outcome — and it is far cheaper than the dispute it prevents.