Outcome
The business or user result is stated without pretending that an unverified outcome is guaranteed.
Software SOW review: test the deal, not the document.
A polished statement of work can contain every familiar heading and still fail at delivery. Review whether scope, proof, decisions, and money form one usable system.
A software SOW is review-ready when every paid milestone connects a defined deliverable to acceptance criteria, evidence, a decision owner and window, a failure path, and the matching payment rule.
The 12-point software SOW review
Deliverables
Every paid output is identifiable: feature, environment, data, document, training, or access.
Exclusions
Likely adjacent work that is not priced is named.
Dependencies
Buyer, provider, and third-party inputs have owners, dates, and schedule effects.
Milestones
Stages represent reviewable progress and connect to deliverables and value.
Acceptance
Each material deliverable has observable, agreed pass conditions.
Evidence
The parties know which links, records, tests, files, or logs support the decision.
Review path
A named role, review window, rejection reason, correction, and resubmission path exist.
Price & change
Currency, tax, expenses, schedule, assumptions, defect correction, and new-work approval are explicit.
Ownership & licenses
Rights to code, design, data, accounts, pre-existing tools, open source, and third-party assets are addressed.
Security & data
Access, environments, secrets, personal data, incidents, deletion, and required testing match the risk.
Support & handover
Warranty defects, maintenance, response, documentation, credentials, knowledge transfer, and exit are separated.
Rewrite one vague milestone
Before
Customer dashboard — $6,000
Design and develop a modern customer dashboard with analytics and responsive behavior. Two rounds of feedback included.
Review-ready structure
Authenticated dashboard milestone
- Deliverable: the listed dashboard screens on the agreed staging environment, with buyer and administrator roles.
- Acceptance: each named role completes the agreed test paths using the supplied fixture data; unauthorized access is denied.
- Evidence: staging build, version tag, role test report, responsive captures, and known-issue list.
- Reviewer: buyer product owner, within five business days.
- If it fails: rejection cites the unmet criterion; in-scope correction is resubmitted once before escalation.
- Payment: $6,000 after explicit acceptance of this milestone.
Illustrative structure only. The actual screens, roles, tests, review period, correction rights, and payment model must be negotiated for the deal.
Review in three passes
- Coverage: identify every incorporated proposal, appendix, design, backlog, message, policy, and external specification. Confirm the controlling version.
- Connections: trace every deliverable through milestone, acceptance, evidence, review, correction, and payment. Record every broken link.
- Stress cases: simulate a buyer delay, failed integration, disputed defect, data incident, late review, provider exit, and handover to a new team.
Do not ask only “is this clause present?” Ask “could both sides execute it on the worst reasonable day of the project?”
When to add a specialist review
Delivery structure is only one layer. Bring in the appropriate qualified reviewer when the deal includes regulated or sensitive data, material security exposure, complex intellectual property, employment classification, cross-border tax, sector rules, open-source obligations, unusual indemnities, or a loss the business cannot absorb.
Frequently asked questions
What should a software SOW include?
At minimum: the outcome, in-scope deliverables, exclusions, dependencies, milestones, acceptance criteria, evidence, reviewer and review window, price and change rules, ownership and licensing, security and data duties, support, and handover.
What is the difference between a proposal and a statement of work?
A proposal usually sells an approach and price. A statement of work should identify the work the parties are actually agreeing to perform and how delivery will be evaluated. Labels vary, so review the incorporated content rather than trusting the document title.
Should a lawyer review a software SOW?
For material risk, regulated data, complex IP, cross-border work, or terms you do not understand, use qualified legal and security reviewers. This checklist improves the delivery questions; it is not legal advice.
Can an agile project use a fixed SOW?
Yes, if the commercial model explains what can evolve, who prioritizes, how capacity or outcomes are measured, and how changes affect price and timing. Agile delivery does not mean undefined commercial terms.
Primary guidance used
The checklist is an original Ratly32 framework informed by official guidance. Those sources support the principles; they are not a substitute contract and do not make government purchasing rules applicable to a private deal.
- U.S. FAR 37.602 — required results and measurable performance standards
- GOV.UK Digital, Data and Technology Playbook — problem, deliverables, acceptance, sign-off, governance, and knowledge transfer
- GOV.UK Contracting for Agile — evolving requirements, agreed acceptance criteria, and commercial-model fit
- U.S. DFARS 227.72 — software deliverables, rights, documentation, delivery schedules, and acceptance requirements
- NIST IR 8397 — software verification techniques including automated, structural, black-box, and security testing
Start with the free structure check, use the acceptance criteria library to make “done” testable, then move the agreed structure into the Deal Spec builder.
Next move
Turn the review into a working Deal Spec.
Carry the proposal’s unresolved questions into milestones, acceptance, evidence, ownership, support, and dispute terms.