How To Write A Project Statement Of Work: Template & Example

Published in

The Digital Project Manager

9 min readJun 18, 2019

The SoW (statement of work or scope of work) is one of the best, and worst weapons in a project manager’s arsenal of tools. It’s the best because a statement of work (SoW) is so often the one piece of documentation that saves you from a world of trouble. And a statement of work is the worst, because it’s a lot of work to produce — and even just a tiny mistake, can have massive repercussions.

In this statement of work guide, we’re going to help you create a SoW that will be your best weapon. We’ll provide you with a scope of work template and statement of work example so you’re set with everything you need to create your own statements of work.

Keep reading to understand our scope of work definition, a statement of work definition and the differences between the two. We’ll provide a scope of work sample, that’ll help you define your own statement of work format. This is a complete guide to writing a scope of work that works.

How To Create Statement Of Work Overview

What Is A Statement Of Work? A SoW Definition

Let’s start with the basics; what is a sow? And why do we keep switching between these different terms — statement of work, scope of work and SoW?

In project management, SoW is an acronym for Statement of Work. Alternatively, SoW (sometimes written SOW or sow) can also be used as an acronym for Scope of Work.

Put simply, a SoW, or statement of work is an agreement between a client and agency that defines what’s included within a project, and what’s not.

The statement of work is the project contract. The statement of work sets and aligns expectations. It can contain all kinds of detail to help with that alignment including detail around deliverables, process, defining what’s acceptable, what’s not, clarifying the price, timeline, invoicing schedule and much more. In fact, you could put all kinds of things into a statement of work if you wanted — it’s just best to keep it as lean as possible.

A Statement Of Work Defines The Work To Be Done

SoW’s provide the extra layer of detail that cost estimates and project plans usually don’t include to describe exactly what’s being done and delivered — and what’s not. The statement of work (SoW) provides high level overarching project information and defines detailed deliverables, standards, criteria and requirements for each phase.

It’s where you put the meat on the bones of the project, and as you do, you get an opportunity to flesh out the details of what you’re going to deliver in your project.

It’s a lot of work, but that’s not necessarily a bad thing as it’ll help refine your approach. In creating a statement of work you’ll probably end up adjusting your estimate and your timeline as you remember things that you should have added but forgot to.

This level of detail provides reassurance to the client as to what will be delivered and ensures that there really is a shared understanding on what the project will deliver and achieve.

This is about as close as you’ll get as a project manager, to being a lawyer! For both the agency and the client the statement of work becomes the bible in determining what’s ‘in scope’ and what’s ‘out of scope’. That matters because ultimately the statement of work serves as the reference point for determining what’s included within the project cost, and what’s not. If you’re able to get your statement of work (SoW) right, it’ll save you a world of pain later in a project

The statement of work contains all the project details wrapped up in one document. If you’ve already created a project plan or timeline and a project estimate, then the statement of work is the icing on the cake, it’s got all the juicy detail, and ties everything together.

What Is Project Scope And Why Does It Matter?

Project scope describes what’s being done, and critically — how much of it. Project scope is the extent, range, breadth, reach, confines, dimension, reach, realm, gamut, spectrum or spread of the work that’s to be done.

To illustrate why it’s important, take the example of a website build. Suppose you agree with a client that you’ll create them a new website for $100k. That’s great but what exactly will the client get for their $100k. Is it just a one-page site, or are there 100 pages? Who’s creating the content for the site? And who’s loading it? Who’s hosting it and who owns the code? The project scope defines all these questions and more so that there’s a shared understanding of a project.

Statement Of Work Or Scope Of Work — What’s The Difference?

Let’s clear this up. What’s the difference between a statement of work and a scope of work — are they the same thing? Pretty much — a statement of work usually refers to the document itself, whereas the scope of work is the extent of work that the document codifies and defines.

So the terms SoW, statement of work, and scope of work can be used interchangeably; they all describe the agreement of work to be done. Hereafter, for simplicity, we’re going to use the term statement of work.

Do You Really Need A Statement Of Work?

Please do. It’ll save you a world of pain later. Ultimately, a statement of work is about managing and documenting expectations. And as with any agreement, it’s always best if those making the agreement, know exactly what they’re agreeing to.

I get it — it’s tempting to not bother with a statement of work; after all, who likes paperwork? Particularly if you subscribe to an agile approach to documentation — as little as possible and only where really necessary — doesn’t that mean that the days of producing a statement of work are over?

Nice try, but no.

As a project manager, it’s in your best interest to have something that enables you to say, ‘But this is what we agreed…’ — when you’re having a debate with a client over about whether your estimate for a banner ad campaign was also going to include a campaign landing page.

The failure to write (or properly write) a statement of work is all too often the reason clients and agencies end up in conflict. When there’s uncertainty or ambiguity it creates tension because it creates the potential for there to be a gap in understanding over what’s been agreed. The idea of a statement of work is not to catch a client out, but to level set on exactly what’s being done, how, when, and how much it’ll cost.

So assuming you need a statement of work, when should you produce it?

Producing a statement of work is a lot of work so you don’t want to create it prematurely when a client is still trying to decide if they want to do a project. But equally, you don’t want to start writing a statement of work (SoW) when the client has approved your estimate — you’ll hold up the project and have forgotten lots of the detail.

In our previous guide on estimating projects we talked about three phases of estimation; ballpark, budget and SoW estimation. It’s a good idea to start making notes for your statement of work in the ballpark estimation phase, then beginning the process of documenting as you’re creating the budget estimate so that by the time you’re creating the final statement of work estimate, you’ve got all the information you need ready to send the statement of work to the client quickly for signoff.

What Should A Statement Of Work Contain?

While creating a statement of work might sound reasonably simple, getting it right is not. If the statement of work is too vague, too broad or too generic, it can leave room for multiple interpretations, which leads to trouble later in a project. And if it’s too detailed, it can artificially constrain the project, so that you end up doing pretend work that’s not really needed, just because you said you would.

So what should a statement of work contain? What are the bits of a statement of work that are important? And what’s really a waste of time and redundant? There’s no one way to produce a statement of work (SoW) — but whether they’re five or fifty pages, they’re doing the same things, setting the parameters of the project so everyone knows the boundaries of the project.

As a minimum, it should clearly detail:

What the project is, why it’s happening, and what it will achieve (overview)
Who has approval (governance)
How the project will be completed (approach + phases + tasks)
What will be produced (deliverables)
When it will be delivered (timeline + milestones)
What it will cost (estimate + payment schedule)
What is and isn’t included (assumptions)

Should You Use A Master Services Agreement (MSA) Or Statement of Work (SoW)?

Depending on what previous legal contractual agreements you have in place with the client. It’s worth remembering that if this is the first project with a client, it’s likely that there needs to be an accompanying MSA (Master Services Agreement) in place which you’ll need to reference in your statement of work.

The MSA is a contract between an agency and a client in which both parties agree to the terms that govern future transactions or future agreements — like the statement of work. The idea of a MSA is to agree some basic terms so that any future transactions can be agreed more quickly. The MSA provides a strong foundation for future projects, and defines as many generic terms as possible so that they do not need to be repeatedly renegotiated; you only need to negotiate details of the project.

An MSA will typically address high level topics such as:

General Services — The kind of work you’re going to do for the client (strategy, service design, web design, content strategy, media buying etc.)
Payment Terms — How you’ll get paid, when you’ll get paid, the rate you’ll be paid at, what expenses are covered and which aren’t
Audits — How the client can ask you to prove you’re doing your job such as reviewing timesheet reports
Confidentiality — What you can and can’t say about the work you’re doing, to whom, and the implications if you say something you shouldn’t
Proprietary Rights — Who owns what when the job’s done (usually the sticking point is who owns the layered design files and code)
Term and Termination — How long the agreement lasts, who can end the agreement, for what reason, and what the implications or costs are
Representations — Ensures you can do the work, you’re not in conflict with other agreements
Warranties — What you’ll fix if whatever you make is broken and your fault
Indemnification — To guarantee against any loss which another might suffer
Insurance — The types and amount of insurance coverage you have to carry out the work
Project Management — What the roles for project managers on both sides will be
Support/Deployment — What assistance you’ll provide the client with implementation, and what additional support you’ll provide moving forward.

So while a MSA is the governing document for the entire relationship, the SOW usually deals with the specifics of a single project. If you don’t have a Master Service Agreement in place, you’ll want to include the kind of details outlined above in your statement of work. Obviously, if you do have a MSA in place, you can leave these out of the statement of work.

Read the full article to learn more:
- Statement of Work example
- How detailed should a Statement of Work be
- How to write a Statement of Work in 7 simple steps
- How to use a Statement of Work
- Scope of Work template

Originally published at www.thedigitalprojectmanager.com on January 9, 2018.