Statement of Work (SOW): How to Write One, With Example and Template

This guide shows you what belongs in a statement of work, how it differs from a scope of work, a requirements specification and a contract, and how to turn a signed SOW into a project plan.

🔽 You'll also find a template to copy and our free checklist for your next statement of work.

What Is a Statement of Work (SOW)?

A statement of work (SOW) is a formal document that defines which work a contractor performs for a client, which results it delivers, by when and at what price. In project management, the SOW is the reference point for every later discussion about scope.

A SOW records:

• Objectives and expected results
• Scope of work, meaning what is included and what is not
• Deliverables and milestones
• Schedule and deadlines
• Acceptance criteria
• Price and payment terms
• Assumptions, constraints and client responsibilities

The PMI's PMBOK Guide describes the procurement statement of work as a document that describes the procurement item in enough detail for prospective sellers to judge whether they can provide it. That is why clients often write the SOW before a tender and attach it to the request for proposal (RFP).

Scope of work or statement of work? The scope of work only describes the work itself: "what gets done". The statement of work contains the scope of work as one section and adds who works, when, where, to which standards and for which payment.

Why Is a Statement of Work So Important?

A statement of work prevents scope disputes before they start: both sides sign what gets delivered, when it is accepted and how it is paid. Without it, scope grows unchecked and every change becomes a negotiation.

A carefully written SOW:

1. Sets clear expectations for everyone involved.
2. Gives all stakeholders one shared picture of what success looks like.
3. Prevents scope creep, because it names deliverables and exclusions precisely.
4. Lowers project risk, because assumptions and client responsibilities are on paper.
5. Secures accountability through milestones, acceptance and signatures.

This applies to external projects with vendors or subcontractors and equally to internal projects, where the SOW defines which department delivers what by when.

Who Writes the Statement of Work?

The statement of work is usually written by the party that requests the work: the client's project manager or procurement team. In service projects, the contractor often drafts the SOW from its proposal. Legal and procurement review the draft, and both parties agree before anyone signs.

How Does a SOW Differ From a Requirements Specification, Project Charter and Contract?

The SOW defines which work is agreed at which dates, acceptance criteria and prices. The requirements specification supplies the basis for it: what the client needs and, in a second document, how the contractor will build it. The project charter and the contract complete the set.

In Germany, DIN 69901-5 separates these two specifications: the client writes the requirements specification (Lastenheft), the contractor writes the functional specification (Pflichtenheft) that describes how it will meet them.

Which contract type and pricing model fits your project is covered in our article time and materials vs fixed price: contract types compared.

What Should a Statement of Work Include?

A statement of work should include every point client and contractor could later disagree on: scope, results, dates, acceptance, payment and exclusions. Start with notes on all aspects of the project; the mind map below shows the 14 areas.

1. Introduction: Name the parties and describe the work in two or three sentences. Refer to the contract the SOW is attached to, such as a master agreement with prices and legal terms.

2. Purpose of the project: State why the project starts and how you will measure its benefit, such as time saved, revenue or return on investment.

3. Scope of work: Describe which work is included, with which processes, hardware and software. State explicitly what is not included. This exclusion list prevents most change claims.

4. Place of work: Define where the team works: at the client's site, the contractor's site or remotely, and which equipment and access it needs.

5. Tasks: Break the scope down into work packages. Organize them by work breakdown structure, phase or milestone and estimate the effort per package.

6. Milestones: Set the start, end date and interim dates. If the contract caps billable hours per week or month, the cap belongs here.

7. Deliverables: Define each result with quantity, format and due date, for example "filing concept, PDF, 20 pages maximum, due in week 3".

8. Schedule: Assign a date to each deliverable, from analysis through build and test to closure. Use relative dates instead of calendar dates, such as "two months after contract signature". A late signature then doesn't shift the whole plan. Also set dates for formal reviews.

9. Standards and testing: List standards, legal requirements (e.g. GDPR) and tests. State who tests, with which equipment and which resources.

10. Defining success: Write measurable acceptance criteria. Instead of "fast search", write "search result in under 10 seconds in 20 of 20 test cases". In agile projects, the Definition of Done (DoD) goes here.

11. Requirements: List prerequisites and client responsibilities: access, contacts, certifications, travel.

12. Payments: Set the price and payment schedule: upfront, by time or by milestone. Tie payments to acceptance and retain a share until final acceptance.

13. Other: Record anything that fits no other category: security rules, travel costs, post-project support and the change request procedure.

14. Closure: Define how results are accepted, who checks and signs them and how the records are archived.

Free Checklist

What Does a Statement of Work Example Look Like?

A statement of work example fills the 14 sections with real quantities, dates and amounts. The shortened example below describes the rollout of a document management system (DMS) at an engineering firm with 40 workstations. The companies and figures are invented; the math is correct.

Statement of work: DMS rollout, Annex 1 to the master agreement

Where does the fixed price come from? The contractor estimates 400 hours at €95, which is €38,000 on a time and materials basis, and adds 15% for the quantity risk: €43,700. How this compares with billing by the hour is shown in time and materials vs fixed price.

Statement of Work Template to Copy

Copy the template into your word processor and replace everything in square brackets. Don't delete a section; write "not applicable" if a point doesn't apply. That way everyone sees you checked it.

STATEMENT OF WORK
Project: [project name]   Version: [1.0]   Date: [YYYY-MM-DD]
Annex [no.] to the agreement dated [date]

1  Introduction
   Client: [company, contact]
   Contractor: [company, contact]
   Summary: [2 to 3 sentences]

2  Purpose of the project
   Current situation: [...]
   Goal and metric: [e.g. search time under 10 seconds]

3  Scope of work
   Included: [...]
   Not included: [...]

4  Place of work
   [on site / remote / mixed, required access]

5  Tasks and work packages
   WP1 [name], effort [h]
   WP2 [name], effort [h]

6  Milestones
   M1 [name], [weeks or days after signature]
   M2 [name], [...]

7  Deliverables
   [result], [format, quantity], due at [milestone]

8  Schedule
   Start: [x weeks after signature]   Duration: [x weeks]
   Reviews: [dates]

9  Standards and testing
   [standards, legal requirements, test procedures]

10 Acceptance criteria
   [measurable criterion per deliverable]

11 Requirements and client responsibilities
   [infrastructure, contact person, time budget]

12 Price and payments
   Pricing model: [fixed price / time and materials / T&M with cap]
   Payment schedule: [% and amount per milestone]

13 Other
   Change procedure: [form, deadline, hourly rate]
   Travel costs, post-project support: [...]

14 Closure and signatures
   Accepted by: [name, role]
   Client: ________________  Date: ______
   Contractor: ____________  Date: ______

What Types of Statements of Work Are There?

Statements of work differ by project type; the 14-section structure stays the same. You shift the focus by industry:

• IT rollout: Integration steps, test environments, user acceptance tests and data protection under GDPR, as in the example above.
• Project management services: Weekly hours of the project manager, responsibility for reporting, budget and risk, and the approach (waterfall, agile or hybrid).
• Construction project: Building standards, site inspections, safety requirements, materials and a schedule from site preparation to final acceptance.
• Internal project: Process improvement or software rollout between departments. The project charter replaces the contract here; the SOW still defines scope, dates and acceptance.

How Do You Turn a SOW Into a Project Plan in Merlin Project?

You turn a signed SOW into a project plan by transferring work packages, milestones and acceptance criteria one to one into the project structure. In Merlin Project, you proceed like this:

1. Copy the structure: Create each work package as a group and milestones M1 to M4 in the work breakdown. If you collected the sections in the mind map first, switch via View > Work Breakdown > Entry; Merlin Project turns all nodes into activities and groups (see from mind map to project plan). You can download the 14 sections of this article as a Merlin Project file.
2. Store the SOW: Attach the signed document via Insert > Attachment > File to the milestone "Contract signed". The attachment keeps every version of the file as a revision history.
3. Make acceptance criteria checkable: Attach the criteria from section 10 as a Checklist to the acceptance milestone. The checklist shows the status Planned, In Progress, Overdue or Complete.
4. Map the payment schedule: Enter the agreed amount in the Finance Inspector on the Budget tab under Approved and distribute it across the milestones.

The SOW inside the project document

The Attachments view lists all checklists, files and risks of your project. The Attached to column shows which activity or milestone an attachment belongs to. You find the SOW, the acceptance checklist and open risks in one place. Try Merlin Project free for 30 days.

Signatures: The Final Step

A SOW without signatures binds no one. Have all key stakeholders sign before work begins:

• Project sponsors or management
• Vendors or third-party representatives
• Team leads, if they carry direct responsibility

The signed SOW is your evidence in a dispute: it documents agreement on scope, schedule and acceptance criteria.

Sources

• DIN 69901-5:2009-01, Project management, project management systems, Part 5: Concepts (definitions of Lastenheft and Pflichtenheft)
• Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide), 6th edition, chapter 12 Project Procurement Management
• Computerworld: How to write a statement of work
• ProjectManager.com: Statement of Work Definition & Examples

If you have any questions about this blog article or would like to discuss it, we look forward to your contribution in our forum.