A statement of work is the contractual document in a software project that sets out exactly what the supplier will deliver: the deliverables, milestones, timeline, acceptance criteria and price. It turns an agreed scope into a binding commitment that both the supplier and the buyer sign.
What a statement of work is for
When you commission custom software, the statement of work (often shortened to SoW) is the document that makes the deal concrete. It takes everything discussed in conversations and proposals and writes it down as a firm commitment: this is what you will receive, this is when, and this is what it costs.
Its job is to remove ambiguity. If a dispute arises later about whether something was included, the statement of work is the document everyone turns to. The Project Management Institute, a recognised authority on project management, treats a clear definition of scope and deliverables as the foundation of any well-run project.
For a buyer, the statement of work is your protection. A vague one leaves room for the project to drift; a precise one gives you a fixed reference point you can hold a supplier to.
What a good statement of work contains
A statement of work should leave no important question unanswered. A sound one for a small or medium-sized business project covers most of the following:
- Deliverables: a specific list of what the supplier will hand over, such as a working system, documentation and source code.
- Scope: a clear line around what is included and, just as importantly, what is excluded.
- Milestones and timeline: the dated stages of the project and what is finished at each one.
- Acceptance criteria: how each deliverable will be judged complete, so "done" is not a matter of opinion.
- Price and payment schedule: the cost and when each instalment falls due, often tied to the milestones.
- Assumptions and responsibilities: what the supplier expects from you, such as access to staff, data or systems.
Public-sector procurement works the same way. The UK Government's Sourcing Playbook stresses defining requirements and deliverables clearly before a contract is awarded, for the same reason an SME buyer should: an unclear specification is the root of most disputes.
Statement of work vs software requirements specification
These two documents are easy to confuse, because both describe the project, but they do different jobs and a good project has both. A software requirements specification describes what the software must do, feature by feature: it separates functional and non-functional requirements and is the detailed picture of the product.
The statement of work is the contractual agreement of what will be delivered, by when and for how much. It is concerned with the commercial commitment, not the feature detail. In practice the requirements specification is often attached to the statement of work as the definition of scope: the specification says what is being built, the statement of work says it will be built, on this date, for this price.
A simple way to hold them apart: the requirements specification answers "what should the software do?", while the statement of work answers "what am I paying for, and what do I get?".
What a buyer should check before signing
The supplier usually drafts the statement of work, but it is a two-sided agreement and you should read it as carefully as any contract. Before you sign, satisfy yourself on these points:
- Are the deliverables specific? "A reporting module" is vague; a named list of reports, fields and formats is not.
- Are the acceptance criteria testable? You should be able to read each one and know objectively whether it has been met.
- Is the pricing model clear? Check whether it is fixed price or time and materials, and what each payment covers.
- How are changes handled? A change-control clause sets out how new requests are priced, which is your main defence against scope creep.
- Who owns the finished code? Paying for software does not automatically make you the owner: the statement of work or the wider contract must say so.
If any of these is missing or woolly, raise it before signing. A reputable supplier expects questions and will tighten the wording. The cost of fixing a vague clause now is a short conversation; the cost of fixing it later is a dispute.
Where the statement of work fits in a project
The statement of work is normally signed at the end of the discovery phase, once the scope and a realistic estimate are known. Discovery does the thinking; the statement of work records the decision and commits both sides to it.
It often sits inside a wider master agreement that carries the general legal terms, with a separate statement of work for each piece of work. That structure lets you run several projects with one supplier without renegotiating the legal basics every time.
Treated well, the statement of work is not red tape. It is the shared, written understanding that keeps a project honest from the first milestone to final acceptance.
A clear statement of work protects both sides A precise statement of work is the difference between a project you can hold a supplier to and one that quietly drifts. Red Eagle Tech's bespoke software development service gives you a clear, plain-English statement of work before any build is commissioned, so you know exactly what you are paying for. If you would like to talk an idea through, the form below is the place to start.
