What to include in a Statement of Work

Quick answer

A good Statement of Work sets out the scope, the deliverables, the acceptance criteria and definition of done, the increments, what is out of scope, the assumptions, who does what, how changes are handled, who owns the result, any costs outside the hourly rate and how progress is reported. If a reasonable person could read it and know what will be built and how it will be judged finished, it is doing its job.

What a Statement of Work is for

A Statement of Work, or SOW, is the document both sides sign before work begins. It sits alongside the main agreement and describes this particular piece of work: what will be built, how it will be checked and on what terms.

A clear SOW protects both sides. You know what you are paying for. The delivery team knows what it has to deliver and when it is finished. When questions come up halfway through, as they always do, the SOW is the first place everyone looks.

At 2good, payment follows acceptance against a signed Statement of Work, so the SOW carries real weight. If something is not written down, it cannot be tested, and if it cannot be tested, it cannot be accepted. The same discipline helps on any project, however it is bought.

The sections of a good SOW

Background and objective

Two or three paragraphs on the business problem and what success looks like. This gives the team context for the many small decisions that a specification cannot cover. "Supervisors spend an hour a day chasing job status on the phone; the system should show the status of every open job on one screen" says more than a page of feature names.

Scope

A description of what is included, organised by feature or module. For each one, describe the users involved, the actions they can take and the business rules that apply. Keep it concrete: screens, fields, reports and the data that moves between them.

Deliverables

The things you will receive. Working software deployed to an agreed environment is the obvious one, along with the source code in your repository, documentation, any design files and a delivery note for each increment. Listing them avoids the end of project surprise of discovering that "documentation" meant a short readme.

Acceptance criteria and definition of done

This is the most important section. For each feature, write checks that can be tested: given this input, the system does this. Then add a general definition of done that applies to everything, such as code reviewed by a senior engineer, tests passing, deployed to the test environment, and documentation updated. Our guide on writing a specification you can accept against shows how to phrase criteria so they leave little room for argument.

Increments

Break the work into increments, each producing something you can test. State what is in each one and the order in which they will be built. Increments give you early sight of progress and a natural point to accept and pay.

Out of scope

A short list of things that will not be done in this SOW. It feels negative to write, and it prevents more disputes than any other section. Typical entries include data migration from old systems, integrations with named third party tools, a mobile app, and support after go live, unless any of these are explicitly included.

Assumptions

The conditions the plan relies on. For example: the client will provide sample data by a given stage, the existing accounting system has an API the team can use, users will access the system through a modern browser. If an assumption turns out wrong, the plan may change, and writing it down makes that fair to both sides.

Roles and responsibilities

Who does what on each side. Name the person who can make decisions and accept work for the client, and the project manager and senior reviewer on the delivery side. Note what the client is expected to provide, such as content, test users, access to systems and timely feedback.

Change process

How changes to scope are requested, estimated, approved and recorded. A simple process works best: a written request, an estimate of hours and impact on the plan, written approval, and an update to the SOW or a change log. Changes are normal; unrecorded changes cause trouble.

Ownership

Who owns the source code, documentation and intellectual property, and from what point. At 2good these belong to the client on acceptance and payment, and that is written into the SOW. Our article on who owns the code in outsourced software covers this in more depth.

Costs outside the hourly rate

Hosting, domain names, paid APIs, software licences, app store fees and similar costs. State which apply, who pays for them, and whose name the accounts are held in. Agreeing these in writing before work starts avoids awkward conversations later.

Reporting

How you will see progress: the frequency of updates, the format, regular sync calls, and a report of hours and deliverables against scope. Good reporting means nothing at acceptance comes as a surprise.

An example outline: a job card system

Here is how those sections might look for a Rajkot engineering firm replacing its Excel job sheets with a simple web based job card system. It is a sketch to show the shape, and a real SOW would go into more detail under each heading.

| Section | Outline | | --- | --- | | Objective | Replace Excel job sheets with a web system that shows the status of every job and the hours booked against it | | Scope | Customer and job records; job cards with operations, machine and operator; status updates from the shop floor on a tablet; a supervisor dashboard; a monthly hours report | | Deliverables | Deployed web application, source code in the client's repository, admin guide, user guide, delivery note per increment | | Increments | Customers, jobs and job cards; shop floor status updates; dashboard and reports | | Acceptance criteria | A supervisor can create a job card with three operations in under two minutes; an operator's status update appears on the dashboard within a minute; the monthly report totals match a manual check on sample data | | Definition of done | Senior review complete, tests passing, deployed to test, documentation updated | | Out of scope | Integration with Tally, invoicing, mobile app, migration of past years' Excel data | | Assumptions | Client provides a sample of current job sheets and a list of machines and operators; shop floor has reliable Wi-Fi | | Roles | Client: production manager approves and accepts. Delivery: project manager, senior reviewer, developers, QA | | Change process | Written request, estimate in hours, written approval, entry in the change log | | Ownership | Code, documentation and IP belong to the client on acceptance and payment | | Other costs | Cloud hosting and domain in the client's name, paid by the client | | Reporting | Weekly written update and sync call; hours and deliverables against scope per increment |

A system of this kind might sit in a block or two of hours, and the MVP hours estimator will give you a first view of size before you write the full document.

Common gaps to check

Before signing, read the SOW with these questions in mind:

• Could someone outside the project tell from the acceptance criteria whether a feature is done?
• Is everything you assumed would be included either in scope or explicitly out of scope?
• Is there a named person on your side with authority to accept work?
• Are hosting, licences and other costs assigned to someone?
• Is ownership stated, with the point at which it passes to you?
• Do you know how and how often you will hear about progress?

If any answer is unclear, fix the document before work begins. A day spent on the SOW saves weeks later.

Where to start

The specification starter gives you a structured outline to fill in, which becomes the core of your SOW. You can read the terms that sit around it on the offer, and when you have a draft, contact us to review it together.

Contract terms vary by country and by situation, so have your lawyer review the SOW and agreement before you sign.