What a good statement of work looks like for a software project

March 18, 2026 · 2 min read · HQT

A statement of work is the document most likely to prevent an argument later. We have read many, and the good ones share a structure. Here is what we look for and what we write into our own.

Objective, in one paragraph

What problem is being solved and how will the agency know it worked? If this paragraph is hard to write, the project is not ready.

Scope and, just as importantly, out of scope

List what is included at the level of features or deliverables. Then list what is explicitly excluded. Out-of-scope lists prevent the most common source of friction, which is an assumption on one side that something was obviously included.

Deliverables with acceptance criteria

Every deliverable gets a sentence describing how it will be accepted. "A working application" is not testable. "A web application that passes the attached acceptance test cases, an automated accessibility scan with no critical findings, and a manual screen reader review of the three primary workflows" is.

Roles and responsibilities

Who from the agency will make decisions, provide data, review deliverables, and how quickly. Projects stall when nobody on the agency side has the authority or time to answer questions.

Schedule and milestones

Dates tied to deliverables, with the dependencies on agency input called out. If a milestone depends on the agency providing test data by a certain date, say so.

Assumptions

Environment access, licenses, data availability, and anything else the price depends on. When an assumption fails, the statement of work says what happens.

Change process

How scope changes are proposed, priced, and approved. Small projects still need this.

Warranty and support

What happens after acceptance, for how long, and what a support agreement would look like if the agency wants one.

None of this is novel. It is simply done carefully, and it is worth the hour it takes.