What makes a good SOW
A strong SOW removes ambiguity. Every section should answer a question that could become a dispute later. The goal is for both parties to read the same document and have the same expectations.10 key sections
- Project overview — what the project is, who the stakeholders are, and the business problem being solved
- Scope of work — detailed requirements with acceptance criteria for each deliverable
- Out of scope — explicit exclusions to prevent scope creep
- Timeline and milestones — phases, dates, dependencies, and what triggers the next phase
- Pricing and payment schedule — total cost, rate structure, payment triggers, and late payment terms
- Team and roles — who works on what, seniority levels, and availability
- Acceptance criteria — how each deliverable is evaluated and approved
- Change management — how scope changes are requested, evaluated, and priced
- IP and code ownership — who owns the deliverables after the project ends
- Service commitments and SLAs — response times, uptime, bug-fix windows, and support terms
Common mistakes
Acceptance criteria
Acceptance criteria define when a requirement is considered complete. Without them, “done” is subjective.Given/When/Then format
The most effective format for acceptance criteria borrows from behavior-driven development:Examples
Requirement: User authenticationTips for writing acceptance criteria
- Write them before development starts, not after
- Cover the happy path and at least one failure scenario
- Include measurable outcomes (response times, status codes, email delivery)
- Avoid implementation details — describe what, not how
- Each criterion should be independently testable
Out of scope
The out-of-scope section is your most important legal protection. It defines what the project does not include.Why it matters
Without an explicit out-of-scope section, clients may reasonably expect features that “seemed obvious.” This leads to unpaid work, strained relationships, and margin erosion.How to write exclusions
Be specific. Instead of “additional features,” list the exact things that are not included:Common assumptions to document
Include a section for assumptions — things that must be true for the project to succeed as scoped:- Client provides API credentials for third-party services by [date]
- Content (copy, images, translations) is provided by the client
- The existing database schema does not change during development
- Staging environment is provided by the client or provisioned within the first week
- Code review and approval turnaround is within 2 business days
IP and code ownership
One of the most contentious areas in software projects. Define it clearly before work begins.Three common models
Work for hire
The client owns all code, designs, and deliverables upon payment. The provider retains no rights.License model
The provider retains ownership and grants the client a perpetual, non-exclusive license to use, modify, and deploy the code.Hybrid model
Client-specific business logic is transferred to the client. Reusable libraries, frameworks, and tools remain with the provider.SLA definitions
Service Level Agreements define the operational commitments after delivery or during an ongoing engagement.Key SLA metrics
Severity levels
Story points estimation
Story points measure relative complexity, not absolute time. They help teams estimate effort consistently across different requirement types.Common scale
Converting to hours
The conversion depends on the team’s velocity, but common baselines:These are estimates, not guarantees. Always include a buffer (15-25%) for unknowns, code review, testing, and deployment.
Estimation tips
- Estimate with the team, not alone — diverse perspectives catch blind spots
- Compare new requirements to recently completed ones (“is this bigger or smaller than X?”)
- If you can’t decide between two values, pick the higher one
- Anything above 8 points should be broken into smaller requirements
- Re-estimate after discovery if the brief was vague
Change management
Change management defines how modifications to the agreed scope are handled during the project.Standard process
1
Change request submitted
The client describes the change — what they want added, modified, or removed.
2
Impact assessment
The provider evaluates the change against the current scope: effort (story points/hours), timeline impact, and cost delta.
3
Approval or rejection
The provider presents the assessment. The client approves, negotiates, or withdraws the request.
4
SOW amendment
If approved, both parties sign an amendment to the SOW documenting the new scope, revised timeline, and additional cost.
5
Work proceeds
The change is integrated into the project plan and tracked alongside the original requirements.
Pricing change requests
Common approaches:What to include in the change clause
Risk matrix
A risk matrix helps you identify, assess, and plan for things that could go wrong.Structure
How to use a risk matrix
- Review risks at the start of each phase
- Assign an owner for each high-impact risk
- Include the cost of mitigation in your estimate (buffer)
- Update the matrix when new risks are discovered or existing ones change
Cloud migration specifics
Cloud migration projects have unique SOW requirements beyond standard software development.Additional sections to include
- Current state assessment — existing infrastructure, dependencies, and data volumes
- Migration strategy — lift-and-shift, re-platform, re-architect, or hybrid
- Rollback plan — how to revert if migration fails, including time and cost estimates
- Data migration plan — schema mapping, transformation rules, validation criteria
- Downtime window — agreed maintenance windows and communication plan
- Compliance requirements — data residency, encryption at rest/transit, audit logging
- Performance baselines — current metrics to compare against post-migration
- Training and handoff — knowledge transfer sessions, runbooks, operational documentation
Common cloud migration risks
Rate cards and pricing models
Rate card structure
A rate card lists hourly or daily rates by role and seniority:Pricing models compared
Pricing tips
- Always include a buffer (15-25%) for unknowns in fixed-price projects
- For T&M, set a monthly cap so the client has cost predictability
- In retainers, define what happens to unused hours (roll over, expire, or credit)
- For milestone payments, tie triggers to acceptance criteria, not dates
- Include a mobilization fee for projects that require significant upfront setup (infra, environments, CI/CD)
- Specify currency and payment method explicitly — wire transfers, Stripe, and crypto all have different processing times and fees