A statement of work template is a document that sets out a project's scope, roles, timelines and deliverables before work starts. As of Nov 2026, Atlassian says it also covers payment terms, milestones and the overall project plan. It can carry legal weight, so have a lawyer check anything you'll sign.
If you freelance, consult or run an agency, you may first need one when a client asks for it, or after a project has drifted and everyone remembers the agreement differently. It's the document that says what you'll deliver, by when, and how you'll both know it's finished.
One thing to be clear about before you use the layout below. ProjectManager describes a statement of work as a legally binding agreement between a client and a vendor or service provider. I'm not a lawyer and this page isn't legal advice. Treat what's here as a working layout, and ask a solicitor or lawyer to check any contract before you rely on it.
What goes in each section
The sections below combine Atlassian's how-to steps with the parts ProjectManager says its template covers.
| Section | What to write | Why it's there |
|---|---|---|
| Objectives | What the project's meant to achieve, in plain words | Everything else in the document should trace back to this |
| Scope | What's included, plus any specific requirements or constraints | ProjectManager says a detailed SOW minimises the risk of scope creep |
| Deliverables | Each thing you'll hand over, named and described | Both sides can see exactly what's being produced |
| Tasks and phases | The work broken into manageable sections | Atlassian says this shows everyone how the work gets done |
| Roles and responsibilities | Who does what: client, contractor, team members, stakeholders | Nobody has to assume that someone else has it covered |
| Timeline and milestones | Realistic dates for each phase, plus the critical milestones | It gives you a roadmap to completion |
| Resources and budget | People, materials, equipment and budget constraints | Atlassian says this helps with planning and allocation |
| Payment terms | The payment schedule and what triggers each payment | Atlassian lists payment terms as an essential detail |
| Acceptance criteria | How each deliverable gets checked and signed off | It's how you both know the work's finished |
| Changes and approvals | How changes get requested, and who can approve them | ProjectManager says to anticipate changes while you're drafting |
| Terms and conditions | Intellectual property, confidentiality and dispute resolution | Atlassian includes these, and it's the part to show your lawyer |
A statement of work layout to copy
Paste this into a blank document and write in full sentences under each heading. Delete anything that doesn't apply to the project in front of you.
Copy this statement of work template
STATEMENT OF WORK
Project name:
Client:
Provider:
Date and version:
1. OBJECTIVES
What this project will achieve:
2. SCOPE
What's included:
What's not included:
3. DELIVERABLES
Deliverable, description, format:
4. TASKS AND PHASES
Phase, tasks, who does them:
5. ROLES
Name, role, responsibilities:
What the client needs to provide, and by when:
6. TIMELINE AND MILESTONES
Milestone, due date:
7. RESOURCES AND BUDGET
People, materials, equipment, budget limits:
8. PAYMENT TERMS
Payment schedule, and what triggers each payment:
9. ACCEPTANCE
How each deliverable is reviewed, who signs it off, and how long they have:
10. CHANGES
How to request a change, how time and cost get assessed, who can approve it:
11. TERMS
Intellectual property, confidentiality, dispute resolution (lawyer to review):
12. SIGN-OFF
Names, roles, signatures, dates:
Writing it, in the order that helps
Atlassian's how-to gives the sequence, and I've added ProjectManager's tips where they fit. ProjectManager calls this the first project document you'll create, and says you shouldn't rush it or leave it until the last minute.
- Define the objectives. Atlassian says to start with what you want to achieve, then record the scope, deliverables and any constraints that could affect the project.
- Outline the requirements. Break the work into manageable sections and describe each phase. Atlassian says this helps everyone understand how the work gets completed.
- Set out responsibilities and roles. Atlassian wants every party included: client, contractor, team members and stakeholders.
- Set timelines and milestones. Keep the dates realistic for each phase, and name the milestones that matter most.
- Specify resources and budget. List people, materials and equipment, and note any budget limits.
- Add the terms. Atlassian lists payment schedules, acceptance criteria, intellectual property rights, confidentiality agreements and dispute resolution. This is the point to bring in legal help, not after signing.
- Get someone else to read it. ProjectManager says to let others review your draft before you submit it. If a colleague can't explain the scope back to you, it isn't clear enough yet.
On style, ProjectManager's advice is direct: avoid jargon and the passive tense, and use verbs and short declarative sentences. Where you have to get technical, explain the term. It also suggests adding a checklist, because a statement of work covers a lot and leaving something out can cause problems later.
Where disputes tend to start
Here's the part people miss, and the first half's my view, not a vendor's. I'd expect most disagreements to begin with a deliverable that has no stated way of being accepted. "Website copy" can be finished in your eyes and nowhere near finished in your client's, and neither of you is lying.
Both vendors point at this. Atlassian puts acceptance criteria in its terms and ties the whole document to deliverables and milestones. ProjectManager's template outlines objectives, deliverables, milestones, payment terms and acceptance criteria in one place, and it says that having it written down makes it easier to settle disagreements about what was agreed. So for each deliverable, I'd write down who reviews it, what they're checking and how long they've got.
Planning for scope changes
Every project shifts, so the sensible move is to plan for it on day one. ProjectManager's heading for this is "Be Flexible and Anticipate Changes", and it has three practical suggestions:
- Develop a change request form while you're drafting the statement of work, not when the first change turns up.
- Note the types of change that are acceptable to stakeholders, and how you'll assess the cost and time involved.
- List the people who have the authority to approve changes, so nobody has to work it out mid-project.
That last one matters more than it looks. If a client's junior colleague can ask for extra work by email, and nothing says who's allowed to agree it, you've got a problem that no template will solve.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
SOW, proposal or contract
ProjectManager says a statement of work isn't the same as a project charter, which is mainly aimed at stakeholders. Beyond that, here's how I think about the other two, and this is my view, not a legal definition.
A proposal is your pitch: why you, and how you'd approach the job. If you're still at that stage, start with these free proposal templates. A statement of work comes once the job's agreed in principle and sets out the detail. As for a contract, ProjectManager's description of an SOW as legally binding means you shouldn't assume it's only a planning document. I can't tell you how yours would be treated, so ask your solicitor or lawyer how it should sit alongside any contract you've got.
Once it's signed, you can turn the milestones into a day-to-day project plan for the team.
Is a template enough?
The downside: it's easy to fill in every heading, feel covered and never check that the wording fits this client and this job. ProjectManager makes the same point from another angle: not all statements of work are the same, and they change with the industry and the project. A template won't give you legal cover by itself either.
The pro is real, though. Atlassian says a template standardises the components across projects and helps ensure consistency, so you don't forget a section under pressure. ProjectManager notes it's used well beyond IT, including by marketing managers running campaigns.
How I'd approach it
I'd keep it short enough that your client will read every line, and skip any section that's only there to look thorough. I'd spend most of my time on deliverables, acceptance and changes, because that's where I'd expect the trouble to come from. Then I'd pay for a lawyer's review on anything sizeable.
Frequently asked questions
What is a statement of work?
It's a document that defines a project's scope, roles, timelines and deliverables. ProjectManager describes it as a legally binding agreement between a client and a vendor, so it's worth taking seriously.
What is the difference between an SOW and a contract?
ProjectManager calls an SOW legally binding, so don't assume it's only a planning document. How yours is treated, and how it fits with any contract, is a question for a solicitor or lawyer.
What should an SOW include?
Atlassian lists scope, roles, timelines, deliverables, payment terms and milestones, plus terms covering acceptance criteria, intellectual property, confidentiality and dispute resolution. ProjectManager adds that you should plan for changes.
Who writes the SOW?
Atlassian says it's typically the project lead or a team member with in-depth project knowledge. ProjectManager suggests letting others review the draft before it goes out.
How long should a statement of work be?
Neither vendor sets a length. ProjectManager wants explicit detail, and the one limit I'd add is that your client has to be willing to read all of it.
