How to Write a Good SOW
What this is and who it’s for
This runbook teaches you to write a Statement of Work for technical services or tooling that gets the agency outcomes instead of a vendor-favorable mess. It’s for the agency tech lead who knows what “done” looks like and the procurement officer who has to put it on a contract — you write it together or you write it wrong. Every category procurement runbook in this library builds on the backbone defined here; when one of them says “fork the SOW skeleton,” this is the skeleton. The job is to turn a capability you need into testable requirements, accepted deliverables tied to payment, and exit terms that keep the agency in control. If you find yourself editing a SOW the vendor drafted, stop — that document is built to protect the vendor, and you’re starting from the wrong side of the table.
Prerequisites
- You can describe the outcome you’re buying without naming a product. “Centralized, searchable error logs across all services” is a requirement; “Datadog” is a purchase decision you haven’t earned yet.
- You’ve read How to Use the Runbook Library so you know which category runbook your buy belongs to and what it expects from the SOW.
- You’ve read Vendor Management, the runbook for managing the vendor after the SOW is signed. The SOW is the instrument; vendor management is how you enforce it. Write the SOW knowing who will hold the vendor to it.
- You know your dollar value and contract path, because the threshold changes the process [VERIFY]. See Procurement notes.
The practice
Start from the requirement, not the vendor’s brochure. A good SOW is the agency’s description of the outcome it will pay for, written before any vendor is in the room. The most common failure is reactive drafting: a vendor sends a “sample SOW,” the agency edits it, and the agency signs a document engineered around the vendor’s deliverables, the vendor’s IP, and the vendor’s exit terms. Write your own from the skeleton in Reference implementation, then let vendors respond to it. The order matters — define the outcome, define “done,” tie payment to “done,” then price it.
Scope & objectives
State what the engagement covers and, just as important, what it does not. Lead with the outcome the agency needs (“a production-ready logging platform operated by agency staff by end of term”), not the activities the vendor will perform. List in-scope systems, environments, and integration points by name so “scope creep” has a baseline to be measured against. Name explicit exclusions; the cheapest change order is the one the SOW already says is out of scope. If the scope can’t be stated without a product name, the requirement isn’t ready.
Deliverables & acceptance criteria
This is where SOWs are won or lost, so define “done” before you define price. Every deliverable gets an acceptance criterion the agency can test objectively — a checklist, a measurable threshold, a demonstrable behavior — not “to industry best practices.” Tie payment to accepted deliverables, never to activity or hours logged: the agency pays when a deliverable passes its acceptance test, not when the vendor reports effort. State who accepts, how long the agency has to review, and what happens on rejection (cure period, then withholding). A deliverable with no acceptance test is a line item the vendor gets paid for regardless of whether it works.
Performance standards / SLAs with teeth
An SLA without a remedy is a wish. For each standard — availability, response time, resolution time, data latency — state the target, the measurement method, the measurement window, and the consequence of missing it. The consequence is the teeth: service credits, withholding, escalation, or termination for chronic breach [VERIFY against permissible remedy terms in Maryland contracts]. Define who measures and reports; if the vendor self-reports with no audit right, the SLA is unenforceable. Set thresholds you’ll actually act on, because an SLA you won’t enforce trains the vendor to ignore all of them.
Data ownership / IP / exit & portability
The agency owns the code and the data — say so in plain words, every time, regardless of vendor or hosting model. All work product, source code, configuration, and data generated under the contract is the property of the agency, licensed back to the vendor only as needed to perform. Require export of all agency data in an open, documented format at no additional charge on termination, plus certified deletion from vendor systems. For custom-developed software, require either delivery of source or a source-escrow arrangement [VERIFY: escrow terms and triggers] so a vendor’s failure or exit doesn’t strand the agency. No proprietary format, no undocumented schema, and no “the platform is ours” clause may stand between the agency and its own data — that’s lock-in, and it’s the vendor’s renewal leverage.
Security & compliance requirements
State the required authorization framework and impact level as a pass/fail term, not a preference [VERIFY: applicable authorization framework — e.g. StateRAMP / FedRAMP — and required impact level for this data classification]. Specify how the agency’s data must be handled: encryption in transit and at rest, access controls, PII redaction or tokenization where applicable, and breach-notification obligations with a stated timeline [VERIFY against Maryland data-handling and breach-notification requirements]. Require the vendor to describe its controls and to permit audit or evidence of compliance for the term. Make the authorization a gate in evaluation; discovering at award that the vendor lacks it restarts the procurement.
Roles & key personnel
Name the roles on both sides and the decision rights that go with them. Identify the vendor’s key personnel by name or by qualification, and require agency approval before the vendor substitutes anyone in a key role — otherwise the senior engineers in the proposal get swapped for juniors after award. State the agency’s points of contact: who accepts deliverables, who approves invoices, who escalates. Define the cadence of status reporting and the format, so oversight isn’t improvised. Key-personnel clauses are how you buy the team you evaluated, not whoever is on the bench.
Pricing structure
Pricing structure allocates risk. Pick the structure that puts the risk where it belongs, then state how cost growth becomes visible before award.
Fixed-price
The vendor commits to a defined deliverable for a defined price. Risk sits with the vendor: if it takes longer than estimated, that’s the vendor’s cost, not the agency’s. Best when scope and acceptance criteria are well defined — which is why the deliverables section has to be solid first. The failure mode is padding (the vendor prices in its risk) and change-order friction when scope shifts, so a tight scope and a clear change process are the price of the protection.
Time-and-materials
The agency pays for hours worked and materials used at agreed rates. Risk sits with the agency: cost scales with effort, and there’s no built-in incentive for the vendor to finish efficiently. Use only when scope genuinely can’t be defined up front (early discovery, true research), and pair it with a not-to-exceed ceiling and deliverable-based acceptance so you’re not paying purely for activity. Left uncapped, T&M is the structure most likely to drift into “paying for level of effort.”
Not-to-exceed
A hybrid: the vendor bills like T&M but the total cannot exceed a stated ceiling. Risk is shared — the agency caps its exposure, the vendor absorbs overruns past the ceiling. A useful middle ground when scope is mostly known but carries some uncertainty. Still tie payment to accepted deliverables within the ceiling, or you’ve just capped the price of paying for activity.
Period of performance & option years
State the base period and any option years explicitly, with the conditions under which the agency may exercise an option. Tie option exercise to performance — the agency renews because the vendor met its SLAs and delivered, not by default. Spell out renewal pricing or a cap on escalation so an option year isn’t an open invitation to raise rates [VERIFY against allowable contract term limits in Maryland]. Make the option the agency’s to exercise, never automatic.
Transition-out / knowledge-transfer obligations
Write the exit before you sign the entrance. Require the vendor, on termination or non-renewal, to deliver a transition-out plan: data export in open format, source and configuration handoff, documentation, and a defined period of knowledge transfer to agency or successor-vendor staff. Make transition-out a paid, accepted deliverable in its own right, so the vendor has an obligation and an incentive to do it well. State the transition period and the cooperation standard — “reasonable assistance” is too soft; specify hours, artifacts, and a completion test. Without this clause, leaving the vendor is so expensive that you never leave, and the vendor knows it.
Outcome-based vs activity-based SOWs
How you frame deliverables decides who carries the risk of things going wrong. Choose the framing deliberately, because vendors will steer you toward the one that protects them.
Outcome-based
The SOW specifies results the agency can test — “logging platform operated by agency staff, passing the acceptance checklist, by end of term” — and ties payment to those results. Risk of inefficiency sits with the vendor: it gets paid for outcomes, not for trying. This is the framing that protects the agency, because acceptance is objective and payment follows working software. It demands real work up front to define “done,” which is exactly the work the deliverables section forces you to do.
Activity-based
The SOW specifies activities the vendor will perform — “provide 3 engineers for 6 months,” “deliver weekly status reports” — and pays for the activity. Risk sits with the agency: you pay whether or not the activity produces a working outcome. It feels safe because it’s easy to write, but it’s the framing every vendor-favorable SOW defaults to, because effort is always deliverable and outcomes are not guaranteed. Use activity-based framing only for genuine discovery work, and even then cap it and bolt an acceptance test onto every milestone.
After signing, the SOW becomes the contract you enforce. Managing the vendor against it — status cadence, SLA reporting, change control, option decisions — is its own discipline, covered in Vendor Management. Write the SOW so that runbook has something enforceable to work with.
Reference implementation
Fork this SOW skeleton. Every bracketed item is a decision a human must make or a value a human must verify; do not ship it with placeholders intact.
# STATEMENT OF WORK — [SERVICE / TOOLING NAME]
### 1. Scope & Objectives
The Contractor shall deliver [OUTCOME, stated as a result not an activity] for [AGENCY / SYSTEM]. In scope: [systems, environments, integrations]. Out of scope: [explicit exclusions]. Objective: by end of term, [AGENCY] staff shall be able to [operate / use / maintain] the result unaided.
### 2. Deliverables & Acceptance Criteria
For each deliverable:
- **Deliverable:** [name]- **Acceptance criterion:** [objective, testable — checklist / threshold / demonstrable behavior; NOT "industry best practices"]- **Acceptance authority:** [named agency role]- **Review period:** [N business days]; on rejection, [cure period] then payment withheld until accepted.
Payment is tied to ACCEPTED deliverables, not to activity or hours.
### 3. Performance Standards / SLAs
For each standard: target, measurement method, measurement window, REMEDY.
- **Availability:** [target] measured [monthly]; remedy: [service credit %].- **Response/resolution:** [targets by severity]; remedy: [credit / escalation].
Vendor self-reporting is subject to agency audit. Chronic breach ([N consecutive periods]) is grounds for termination for cause.
### 4. Data Ownership, IP, Exit & Portability
All data, source code, configuration, and work product are the property of [AGENCY]. On termination the Contractor shall, within [N days], export all agency data in [open, documented format] at no additional charge and certify deletion. Custom software: [source delivered | source escrow with release triggers]. No proprietary format shall prevent export of raw data.
### 5. Security & Compliance
The service/Contractor shall hold [authorization framework, e.g. StateRAMP / FedRAMP] at [impact level] for the term. Data handling: encryption in transit and at rest, access controls, [PII redaction / tokenization where applicable]. Breach notification within [N hours].
### 6. Roles & Key Personnel
Contractor key personnel: [roles / named individuals or qualifications]. Substitution of key personnel requires written agency approval. Agency roles: acceptance authority [name], invoice approver [name], escalation [name]. Status reporting: [cadence], [format].
### 7. Pricing Structure
Structure: [Fixed-price | Time-and-materials with NTE ceiling | Not-to-exceed]. Ceiling / NTE: [FILL IN per agency budget authority]. Payment schedule tied to accepted deliverables in Section 2. [For T&M/NTE: agreed rates by role, and the ceiling that caps exposure.]
### 8. Period of Performance & Option Years
Base period: [dates]. Option years: [N x 12 months], exercisable by [AGENCY] contingent on met SLAs and accepted deliverables. Renewal pricing: [fixed | capped escalation at N%].
### 9. Transition-Out & Knowledge Transfer
On termination or non-renewal the Contractor shall deliver a transition-out plan: data export (open format), source and configuration handoff, documentation, and [N hours/days] of knowledge transfer to [AGENCY] or successor staff. Transition-out is a paid, accepted deliverable with its own completion test. Cooperation standard: [specific artifacts and hours, not "reasonable assistance"].Use this acceptance-criteria checklist to test that each deliverable in Section 2 is actually acceptable, before you publish the SOW.
# ACCEPTANCE-CRITERIA CHECKLIST — apply to every deliverable
- [ ] Stated as a result, not an activity.- [ ] Objectively testable by someone other than the vendor.- [ ] Has a named acceptance authority on the agency side.- [ ] Has a defined review period and a rejection/cure path.- [ ] Payment is contingent on acceptance, not on effort or hours.- [ ] No "industry best practices" or other unmeasurable language.- [ ] The agency could prove non-conformance in a dispute.Every technical SOW needs these clauses. Use this checklist before you release a solicitation — a missing clause here is a known way agencies get locked in or left without recourse.
# CLAUSES EVERY TECHNICAL SOW NEEDS
- [ ] DATA OWNERSHIP — agency owns all data and work product, in writing.- [ ] EXIT / PORTABILITY — open-format export at no charge + certified deletion.- [ ] IP — agency owns custom code; source delivered or escrowed.- [ ] SECURITY & COMPLIANCE — required authorization as a pass/fail gate [VERIFY].- [ ] TRANSITION-OUT — paid, tested handoff and knowledge-transfer obligation.- [ ] SLAs WITH REMEDIES — every standard has a measurement and a consequence.- [ ] KEY PERSONNEL — substitution requires agency approval.Common pitfalls
- You’re paying for activity, not accepted deliverables. If payment milestones reference hours, level of effort, or “services performed” rather than deliverables that passed an acceptance test, the vendor gets paid whether or not anything works. Rewrite Section 2 so every payment is contingent on an accepted deliverable.
- Acceptance language says “industry best practices.” Unmeasurable acceptance criteria mean the agency can’t prove non-conformance, so the deliverable is accepted by default. Replace every vague standard with a checklist, a threshold, or a demonstrable behavior.
- The vendor owns the IP or the repo. If the SOW is silent on ownership, or grants the vendor the code and data, you’re locked in and the vendor holds your renewal leverage. Section 4 — agency ownership, open-format export, source delivery or escrow — is non-negotiable.
- There’s no transition-out clause. With no exit obligation, leaving the vendor means rebuilding from scratch, so you never leave and the vendor knows it. Make transition-out a paid, tested deliverable in Section 9.
- SLAs have no remedy. A target with no service credit, withholding, or termination right is a number the vendor can miss for free. Give every SLA teeth and the right to audit the vendor’s reporting.
- You copied the vendor’s draft SOW wholesale. A vendor-supplied SOW is engineered around the vendor’s deliverables, IP, and exit terms. Start from this skeleton and make vendors respond to it, rather than editing theirs.
Procurement notes
How SOWs fit into Maryland procurement depends on whether you’re issuing a task order under an existing master contract or running a standalone solicitation [FILL IN: where SOWs attach in Maryland procurement — task orders under a master contract vs. standalone RFP, and which office owns each path]. A task order under a master vehicle typically reuses the master’s terms and attaches the SOW as the scope; a standalone procurement carries the full clause set itself.
The state mandates certain clauses and templates that must appear regardless of what’s in this skeleton [FILL IN: required Maryland clauses and mandatory SOW/contract templates — confirm with your procurement officer]. Reconcile this skeleton against those before release; where they conflict, the mandated clause wins.
Thresholds change the process and the timeline [VERIFY: Maryland small-purchase and competitive-procurement thresholds, and how each changes the required process]. Below the small-purchase threshold you may avoid a full solicitation; above it you run a competitive process against this SOW. Confirm the current thresholds and a realistic timeline with your procurement officer before committing a date to anyone.
For managing the vendor against this SOW after award, see Vendor Management.
Maintenance
Owner: [FILL IN: runbook owner] · Last reviewed: 2026-05-31 · Next review: 2026-08-31