SOW Template for Engineering Projects

The SOW that burned me said "integration with the customer's billing system." Everyone nodded. To us that meant a webhook that pushed invoices. To the customer it meant real-time, bidirectional sync with reconciliation — a different project by an order of magnitude. We found out in week six, and the argument over who ate the difference cost more goodwill than the $40k change order that eventually settled it. One noun, "integration," carrying two incompatible projects inside it.

A Statement of Work is a written agreement on what's being delivered, by when, for what cost, and under what conditions. Its real job isn't legal cover — it's to drag exactly that kind of ambiguity into the open before anyone writes code, while the two sides still like each other enough to define terms honestly. It's most associated with vendor contracts, but a lightweight internal SOW between teams earns its keep the same way. This guide is a working template, what each section is actually for, and the specific places SOWs fail.

When to Write One

An SOW is worth the effort for:

• Vendor or contractor engagements

• Internal projects with formal cross-team commitments

• Multi-month efforts with clear deliverables

• Anything funded as a discrete project with a budget

It's overkill for:

• Internal team work that's part of normal operations

• Exploratory work where scope is genuinely unknown

• Small, short-duration tasks

The Working Template

# Statement of Work: [Project Name]

Version: 1.0
Date: YYYY-MM-DD
Effective: [Start date]
Parties: [Names/teams/organizations]

## 1. Background
[Why this project, in plain language]

## 2. Objectives
[What success looks like, at the project level]

## 3. Scope
In scope: [bullet list]
Out of scope: [bullet list, explicit]

## 4. Deliverables
[Numbered list with descriptions and acceptance criteria]

## 5. Timeline
[Milestones and key dates]

## 6. Responsibilities
[Who does what; RACI summary]

## 7. Assumptions
[What we're taking as given]

## 8. Dependencies
[What this project relies on from outside]

## 9. Acceptance Criteria
[How completion is determined]

## 10. Pricing and Payment
[Cost structure; payment terms]

## 11. Change Process
[How scope changes are handled]

## 12. Risks
[Known risks and mitigations]

A typical SOW is 5-15 pages. Longer than that and important details get buried.

Background and Objectives

Background explains why the project exists. One paragraph.

Objectives describe success at the project level. Not requirements (those are deliverables), not features — outcomes.

Example: "Reduce time-to-onboard for new enterprise customers from 30 days to 10 days. Improve onboarding NPS from 38 to 50."

Objectives are how you'll know the project succeeded. Deliverables are the things you'll build.

Scope: The Most Important Section

Scope is where most disputes start. Be specific.

• In scope lists what's being delivered. Specific enough that you can determine whether something is included.

• Out of scope explicitly excludes things that could plausibly be misunderstood as included.

The Out of Scope list is the single biggest dispute-preventer. "We will build the new onboarding flow. We will not migrate existing customers; that's a separate project." Even if obvious to you, write it down.

Deliverables

Specific things being built or produced. Each deliverable has:

• A unique identifier (D1, D2, ...)

• A description (what it is)

• Acceptance criteria (how we know it's done)

• A delivery date or milestone

Example:

D1: Self-service onboarding wizard
Description: A multi-step web interface guiding new admin users through initial configuration including SSO setup, user invitation, and integration connection.
Acceptance criteria:
- All 5 configuration steps functional in production
- Mobile-responsive on iOS Safari and Chrome
- Completes successfully in <10 minutes for 90% of test users
- Documented for support team
Delivery: Phase 2 milestone (Week 8)

Deliverables are concrete. "Improved onboarding" is not a deliverable; the specific wizard is.

Timeline

Milestones with dates. Not detailed schedules — milestones.

Example:

- Week 2: Discovery complete, requirements baselined
- Week 4: Phase 1 deliverables (D1, D2) demo
- Week 8: Phase 2 deliverables (D3, D4) demo
- Week 10: User acceptance testing
- Week 12: Production launch
- Week 14: 30-day post-launch review

Each milestone should have a check-in. The SOW commits to dates; without checks, dates drift unnoticed.

Responsibilities

Who does what. A RACI table or a written description.

Critical clarifications:

• Who provides infrastructure?

• Who provides design assets?

• Who handles testing?

• Who handles deployment?

• Who handles support after launch?

If the SOW says "Vendor will deliver the system," but the receiving team is supposed to provide the staging environment, write that down. Otherwise the vendor will charge for it later, or the receiving team will be surprised.

Assumptions

What we're taking as given.

• "Customer will provide access to staging environment within 1 week of start."

• "Existing API endpoints will not change during the engagement."

• "Customer's data complies with our standard schema."

Assumptions are how the SOW protects against scope creep. When an assumption proves false, that's a trigger for the change process.

Dependencies

External things this project needs.

• A specific design system being completed

• An infrastructure team standing up the required environment

• A vendor delivering a related component

Dependencies should be tracked with owners and dates. A dependency that slips affects the SOW; document it explicitly.

Acceptance Criteria

How completion is determined. Specific, testable, agreed in advance.

For each deliverable, the acceptance test. Who performs it, how long they have, what counts as acceptance.

Acceptance: Customer has 5 business days to test each deliverable. Acceptance occurs when criteria are met OR after 5 business days with no written rejection. Rejection must include specific failures against criteria.

The time bound matters. Without it, "we're still testing" can drag indefinitely.

Pricing and Payment

Total cost, structure, payment terms.

• Fixed price — total amount, often tied to milestones

• Time and materials — hourly or daily rates with caps

• Hybrid — fixed for defined deliverables, T&M for additional work

For T&M, specify rates, expected hours, and the cap above which approval is required.

Payment terms: Net 30 is standard; Net 15 is faster; Net 60 is slower. Specify what triggers an invoice — calendar date, milestone delivery, or completion.

Change Process

How scope changes are handled.

• Who can request a change?

• How is it documented?

• How is it priced (if relevant)?

• Who approves?

• How does it become part of the SOW?

The pattern: a Change Request (CR) is written, reviewed, priced, approved, and added as an amendment. The original SOW remains; the CR augments it.

The single most useful clause: nothing changes unless there's a written, approved CR. Verbal agreements don't bind.

Risks

Known risks and how they'll be handled.

• "If the upstream API changes during the project, we'll re-baseline timeline. Estimated impact: 1-2 weeks."

• "If the design system isn't complete by Week 4, we'll proceed with placeholder designs and revisit. Estimated rework: 20%."

Risks are honest acknowledgments. The SOW that pretends no risks exist is the one that produces the bitterest disputes when they materialize.

What Goes Wrong

A few patterns to watch for.

Scope inflation. Initial SOW covers X; weeks in, the team is also doing Y and Z without formal change. Counter by treating scope drift as a CR even if no money changes hands.

Vague deliverables. "Improved performance" without specifics. Disputes about what was achieved are guaranteed.

Missing assumptions. When an unstated assumption proves false, who pays for the rework? Without assumptions documented, default expectation drives the answer.

Acceptance without time bound. "We're still reviewing" becomes a way to delay payment indefinitely.

Ignored change process. Changes happen by handshake; the SOW becomes irrelevant. The first dispute exposes that the SOW protected no one.

Internal SOWs

Internal SOWs — between teams in the same organization — are useful for the same reasons external ones are. Less formal, but with the same core sections.

A working internal pattern: a one-pager covering objectives, scope, deliverables, timeline, dependencies, and responsibilities. Skip pricing; keep everything else.

The discipline of writing it down catches the disagreements before they become problems.

Key Takeaway

A Statement of Work documents what's being delivered, by when, by whom, for what cost. The critical sections are scope (with explicit out-of-scope), deliverables with acceptance criteria, assumptions, dependencies, and the change process. A working SOW is 5-15 pages. Use for vendor engagements and formal internal projects; skip for routine work. The point isn't legal cover — it's shared understanding that survives months and turnover. When something feels obvious, write it down. The obvious-to-you is often invisible-to-them.