This guide covers the key concepts behind professional Statements of Work for software projects. Whether you’re writing your first SOW or refining your process, these practices help you deliver clear, defensible proposals that protect both you and your client.
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
| Mistake | Consequence |
|---|
| Vague requirements (“build the app”) | Client expects more than you scoped |
| No out-of-scope section | Every feature request becomes your responsibility |
| Missing acceptance criteria | ”Done” becomes a matter of opinion |
| No change management process | Scope creep is unpriced and untracked |
| Pricing without rate basis | Client can’t verify how costs were calculated |
| Unclear IP ownership | Disputes over code ownership after delivery |
| No termination clause | Neither party has a clean exit path |
Before sending any SOW, read it from the client’s perspective. If any section could be interpreted two ways, rewrite it.
Acceptance criteria
Acceptance criteria define when a requirement is considered complete. Without them, “done” is subjective.
The most effective format for acceptance criteria borrows from behavior-driven development:
Given [a precondition or context]
When [an action occurs]
Then [the expected outcome]
Examples
Requirement: User authentication
Given a registered user with valid credentials
When they submit the login form
Then they are redirected to the dashboard and a session token is set
Given a user with invalid credentials
When they submit the login form
Then an error message is displayed and no session is created
Given a logged-in user
When they click "Log out"
Then their session is invalidated and they are redirected to the login page
Given a customer with items in their cart
When they complete the Stripe checkout flow
Then a payment intent is created, the order status changes to "paid",
and a confirmation email is sent within 60 seconds
Given a failed payment (declined card)
When the Stripe webhook fires with status "failed"
Then the order remains in "pending" status and the customer sees a retry option
Tips 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:
| Too vague | Specific and defensible |
|---|
| ”Additional features" | "Native mobile apps (iOS/Android) are not included; this project covers web only" |
| "Other integrations" | "Integration with Salesforce, HubSpot, or any CRM besides the one specified in scope" |
| "Future enhancements" | "Multi-language support, A/B testing framework, and advanced analytics dashboards” |
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
If an assumption turns out to be false, it triggers the change management process.
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.
All deliverables produced under this agreement are "work for hire."
Upon full payment, the Client owns all intellectual property rights,
including source code, documentation, and designs.
The Provider retains the right to use general knowledge, techniques,
and non-proprietary tools developed during the engagement for future projects.
License model
The provider retains ownership and grants the client a perpetual, non-exclusive license to use, modify, and deploy the code.
The Provider retains ownership of all deliverables. Upon full payment,
the Client receives a perpetual, irrevocable, non-exclusive license
to use, modify, and deploy the deliverables for their business purposes.
The Client may not resell or sublicense the deliverables without written consent.
Hybrid model
Client-specific business logic is transferred to the client. Reusable libraries, frameworks, and tools remain with the provider.
Custom application code specific to the Client's business is transferred
to the Client upon full payment (work for hire).
Pre-existing libraries, frameworks, components, and tools used by the
Provider remain the Provider's property. The Client receives a perpetual
license to use these components as part of the delivered application.
SLA definitions
Service Level Agreements define the operational commitments after delivery or during an ongoing engagement.
Key SLA metrics
| Metric | Definition | Example |
|---|
| Uptime | Percentage of time the system is available | 99.9% (8.76 hours downtime/year) |
| Response time | Time to first human response for a support request | 4 business hours for critical, 24 hours for normal |
| Resolution time | Time to fix or provide a workaround | 8 hours for P1, 48 hours for P2, 5 business days for P3 |
| Deploy frequency | How often updates are shipped | Weekly releases, hotfixes within 24 hours |
| RTO (Recovery Time Objective) | Maximum acceptable downtime after a failure | 4 hours |
| RPO (Recovery Point Objective) | Maximum acceptable data loss (time) | 1 hour (hourly backups) |
Severity levels
| Level | Criteria | Example |
|---|
| P1 — Critical | System is down, revenue is impacted, no workaround | Payment processing fails for all users |
| P2 — High | Major feature broken, workaround exists | Search returns wrong results but users can browse manually |
| P3 — Medium | Minor feature broken, low user impact | Export button doesn’t work in one browser |
| P4 — Low | Cosmetic issue, enhancement request | Alignment is off on a settings page |
Story points estimation
Story points measure relative complexity, not absolute time. They help teams estimate effort consistently across different requirement types.
Common scale
| Points | Complexity | Typical scope |
|---|
| 1 | Trivial | Config change, copy update, simple bug fix |
| 3 | Small | Standard CRUD, basic UI component, simple integration |
| 5 | Medium | Feature with business logic, API with validation, multi-step workflow |
| 8 | Large | Complex integration, data migration, real-time feature, multi-role system |
Converting to hours
The conversion depends on the team’s velocity, but common baselines:
| Points | Junior | Mid | Senior |
|---|
| 1 | 2-4h | 1-2h | 1h |
| 3 | 8-12h | 4-8h | 3-5h |
| 5 | 16-24h | 10-16h | 6-10h |
| 8 | 32-48h | 20-32h | 12-20h |
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
Change request submitted
The client describes the change — what they want added, modified, or removed.
Impact assessment
The provider evaluates the change against the current scope: effort (story points/hours), timeline impact, and cost delta.
Approval or rejection
The provider presents the assessment. The client approves, negotiates, or withdraws the request.
SOW amendment
If approved, both parties sign an amendment to the SOW documenting the new scope, revised timeline, and additional cost.
Work proceeds
The change is integrated into the project plan and tracked alongside the original requirements.
Pricing change requests
Common approaches:
| Method | When to use |
|---|
| Same hourly rate | Default for T&M and retainer contracts |
| Fixed price per change | When changes are well-defined and isolated |
| Percentage surcharge | For rush changes (e.g., +25% for changes requested mid-sprint) |
What to include in the change clause
Changes to the agreed scope require a written Change Request.
The Provider will assess impact within 2 business days and provide
a cost and timeline estimate. Work on the change begins only after
written approval from the Client. Changes not approved in writing
are considered out of scope.
Emergency changes (P1 production issues) may be implemented immediately
and documented retroactively within 24 hours.
Risk matrix
A risk matrix helps you identify, assess, and plan for things that could go wrong.
Structure
| Risk | Probability | Impact | Mitigation |
|---|
| Third-party API changes or deprecation | Medium | High | Pin API versions, abstract integrations behind adapters, monitor changelogs |
| Key team member unavailable | Low | High | Document knowledge, cross-train, ensure no single points of failure |
| Scope creep from vague requirements | High | High | Detailed acceptance criteria, change management process, out-of-scope section |
| Data migration errors | Medium | High | Run migration on staging first, validate row counts, keep rollback scripts |
| Client delays on approvals | High | Medium | Define approval SLA in SOW, auto-proceed clause after N days |
| Performance issues at scale | Medium | Medium | Load testing before launch, define performance acceptance criteria |
| Security vulnerability in dependencies | Medium | High | Automated dependency scanning, update policy, responsible disclosure process |
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
| Risk | Mitigation |
|---|
| Unexpected data incompatibilities | Schema mapping review and test migration on a subset first |
| Application dependencies on legacy APIs | Dependency audit before migration, adapter layer if needed |
| Higher-than-expected cloud costs | Cost estimate with reserved instances, right-sizing review at 30/60/90 days |
| Extended downtime during cutover | Blue-green deployment, DNS-based failover, rehearsal runs |
| Compliance gaps in the new environment | Pre-migration compliance checklist, audit trail from day one |
Rate cards and pricing models
Rate card structure
A rate card lists hourly or daily rates by role and seniority:
| Role | Junior | Mid | Senior | Lead |
|---|
| Frontend Developer | $45 | $65 | $90 | $120 |
| Backend Developer | $50 | $70 | $95 | $125 |
| DevOps Engineer | $55 | $75 | $100 | $130 |
| QA Engineer | $40 | $55 | $75 | $100 |
| UX Designer | $45 | $65 | $85 | $110 |
| Project Manager | $50 | $70 | $90 | $120 |
Pricing models compared
| Model | Client pays | Provider risk | Best for |
|---|
| Fixed price | Agreed total upfront | High (provider absorbs overruns) | Well-defined scope, short projects |
| T&M (Time & Materials) | Actual hours × rate | Low (client absorbs variability) | Evolving scope, long-term engagements |
| Retainer | Fixed monthly fee | Medium (committed hours, flexible scope) | Ongoing support, maintenance |
| Milestone-based | Per deliverable | Medium (tied to completion) | Phased projects, external funding |
| Hour bucket | Prepaid block of hours | Low (use-it-or-lose-it) | Support contracts, ad-hoc work |
| Staff augmentation | Per person per month | Low (client manages scope) | Team scaling, long-term resource needs |
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
