How to Write a Statement of Work for a Government Solicitation

This is Part 3 of The Solicitation Author’s Handbook, a vendor-neutral series for people in offices of government who write solicitations. Parts 1 and 2 covered pre-drafting work and vehicle selection. This part covers the document’s center of gravity. Educational information, not legal advice; your procurement code controls.

Four documents that get called the same thing

Terminology first, because these get used interchangeably and should not be.

• A statement of work (SOW) describes the work to be performed: tasks, deliverables, schedule, and acceptance. It is the most common instrument and the default assumption of this chapter.
• A scope of work is, in most usage, the boundary-setting section within a SOW: what is in, what is out. Some jurisdictions use the terms interchangeably; your definitions section should say which convention you follow.
• A performance work statement (PWS) describes required outcomes and measurable performance standards while leaving the method to the vendor. It pairs with a quality assurance surveillance plan that says how you will measure.
• A statement of objectives (SOO) goes further still: a short statement of goals from which vendors propose their own work statements. It maximizes room for innovation and demands the most evaluation maturity.

The choice among them mirrors Part 2’s logic. The more confident you are in the method, the closer you sit to a classic SOW; the more you want the market to bring the method, the closer you move to a PWS or SOO.

Outcomes are the spine

The single highest-leverage habit in solicitation authorship is writing requirements as outcomes with numbers attached. “Reduce average permit processing from 40 days to 10,” “support 400 concurrent counter transactions statewide,” “close the books each month with zero manual reconciliation spreadsheets.” Outcome requirements do three jobs at once: they keep the field open to approaches you have not imagined, they give evaluators something honest to score, and they become the acceptance criteria and service levels of the eventual contract without translation.

Feature lists do the opposite. A forty-line checklist copied from a demo describes one vendor’s product, invites every other vendor to parrot “compliant” down the column, and leaves you awarding on theater. Keep features where they genuinely are constraints (an integration that must exist, a data standard that must be met) and let outcomes carry everything else.

The brand-steering trap

Naming a product, or describing one so precisely that only it qualifies, is the most damaging habit in public solicitation drafting. It narrows your field to one, it invites protest from everyone else, it signals a wired award even when the intent was innocent, and it surrenders your price leverage before the first response arrives. If a named product is truly the constraint (an existing system being extended, a mandated statewide platform), say so openly and explain why, or use the sole-source process honestly. Otherwise write the capability, not the brand, and add the phrase your code likely already provides: any named item is illustrative and equivalents are acceptable.

This series practices what it preaches: nothing in it steers toward any vendor, including the one publishing it.

What belongs in the SOW

A serviceable structure, adaptable to your template:

1. Background and problem. Two or three paragraphs from Part 1’s memo. Vendors write better proposals when they understand why.
2. Scope boundaries. What is included, what is explicitly excluded, and what is optional or future phase. Ambiguity here becomes change orders later.
3. Requirements and outcomes. Numbered, testable, each traceable to the problem. Mark each as mandatory, scored, or informational (Part 4 covers why that distinction changes everything).
4. Constraints that are real. Security posture and applicable frameworks, accessibility obligations, data ownership and residency, records retention, integration points with named existing systems, transition-in from the incumbent and transition-out at the end. Transition-out is the clause everyone forgets and the one that determines whether you can ever leave.
5. Deliverables and schedule. What arrives, when, in what form, and who accepts it against what criteria.
6. Service levels and remedies. Uptime, response times, resolution times, with measurement method and consequence, stated plainly.
7. Governance. Meeting cadence, reporting, escalation, key personnel and substitution rules.

Data ownership deserves its own paragraph

Whatever you buy, the data the system holds is the public’s, held in trust by your office. Say so in the SOW: the government owns its data, receives it on request and at termination in documented open formats at no additional charge, and the vendor’s rights to use it are limited to operating the service. The absence of this paragraph is cheap for a vendor and expensive for you, and it is the single clause most correlated with painful exits years later.

Writing so vendors can price honestly

Every ambiguity in a SOW is priced somewhere. A vague requirement gets priced as risk, padding every bid; or priced as the cheapest possible reading, winning the award and then living with you as a dispute. Sizing information is the antidote: transaction volumes, user counts, locations, data sizes, peak loads, current-state systems. Publishing real numbers does not weaken your position; it narrows the spread between bids to the things you actually want to compare.

The SOW checklist

• Every requirement is numbered, testable, and traceable to the problem statement.
• Outcomes carry the spine; features appear only where they are genuine constraints.
• No product is named except as a disclosed, justified constraint with equivalents addressed.
• Data ownership, transition-out, and acceptance criteria are present.
• A stranger to the project could estimate effort from the sizing information provided.
• Someone outside the drafting team has read it and marked every sentence they could not act on.

Part 4 turns to the response side of the table: writing requirements and response structures that strong vendors can actually answer, and the quiet reasons they sometimes decline to.

The Solicitation Author’s Handbook is published by GovSoft as a public resource for offices of government. It is educational information, not legal advice.