The Discipline of Delivery · companion to Chapter 4
Statement of Work
The clauses that actually win and lose disputes, and how to write acceptance criteria that are measurable and binary.
SOW mastery guide — interactive learning modules
📄
What is a SOW?
The contract that defines what you're buying
A Statement of Work is a formal document that defines the work a vendor must perform — what they deliver, when, how quality is measured, and what it costs. It is the single most important document in any vendor engagement. If it's vague, you will lose every dispute.
Legally binding
Scope definition
Milestone-based
Acceptance criteria
SOW vs related documents
SOW vs MSA
MSA = overarching legal terms (liability, IP, NDA). SOW = project-specific work under that MSA. You can have one MSA with many SOWs.
SOW vs RFP
RFP asks vendors "how will you do it?" SOW tells the chosen vendor "here is exactly what you must do." RFP comes first, SOW comes after vendor selection.
SOW vs SLA
SLA defines ongoing service performance (uptime, response time). SOW defines project deliverables. A SOW can reference SLAs for operational services.
SOW vs Change Order
Once a SOW is signed, any scope/cost/timeline change must go through a formal Change Order. Never agree to changes verbally.
Three types of SOW
Design/detail SOW
Describes work at a high level — good for early-stage or exploratory engagements where full requirements aren't known yet.
Level of effort SOW
Defines hours/resources required rather than deliverables. Used for staff augmentation or T&M engagements.
Performance SOW
Defines outcomes and standards the vendor must achieve. Vendor chooses how. Best for managed services. Most outcome-focused.
Hybrid SOW
Fixed-price for defined phases + T&M for enhancements. Most common in IT software projects. Balances certainty with flexibility.
✅
Every clause a PM must know
Click each to expand — must-have vs nice-to-have flagged
⚠️
Common SOW mistakes & how to avoid them
What causes disputes, delays, and cost overruns
⚖️
Good vs bad SOW language
✓ Write it this way
The vendor shall deliver a tested, production-ready REST API by 30 Aug 2026
Response time for P1 incidents: < 1 hour from ticket creation
Acceptance period: 10 business days after delivery
All source code shall be delivered in a Git repo with README
Vendor shall provide weekly status reports every Monday by 5pm
✕ Never write this
The vendor will deliver the API soon
Vendor will respond to issues in a timely manner
Client will review and approve deliverables as needed
Code will be provided at project end
Vendor will keep client updated on progress
🧾
SOW section-by-section template
Fill-in-the-blank structure for IT software projects
Running a project that is slipping? Book a 30-minute delivery review with Siva: we look at your plan, your numbers and the one thing to fix first.
Companion to Chapter 4 of The Discipline of Delivery by Siva Prasad. Read the chapter to understand why the discipline matters, then use this guide to practise the how.