Statement of Work (SoW) - A Guide To How To Write A Scope of Work

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.
What are you going to find here:
• What is a statement of work? A SoW definition
• Do you really need a statement of work?
• What should a statement of work contain?
• Statement of work example
• How detailed should a statement of work be?
• A statement of work checklist
• How to create a statement of work: a step by step guide
• How to use a statement of work
• Further reading on creating a statement of work

3
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
© 2017 The Digital Project Manager. All Rights Reserved.
www.thedigitalprojectmanager.com
4
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.
5
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.
6
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?
7
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.
8
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)
9
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.
10
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.
11
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.
12
Statement Of Work Example

So a statement of work should contain; an overview, governance detail, the
approach, phases and tasks, deliverables, timeline and milestones, estimate +
payment schedule and assumptions. But if you’re looking for a statement of work
example, you’re probably wondering how should you structure all this
information so it doesn’t become totally overwhelming?
Sample Statement Of Work Breakdown For A

Digital Project
For most projects your statement of work then, should have two distinct parts.
The first section outlines the over-arching project information (which you can
often borrow from a previous project); the second section defines the detail of
each phase of the project.
Here’s a sample statement of work breakdown:
Project Information
• Project Summary
• Project Process
• Project Milestones
• Overall Project Governance
• Terms and Conditions
• General Assumptions
13
Phase breakdown
• Phase [n]: [Phase name]
• Phase description
• Deliverables and Assumptions
• Milestones + schedule
• Budget + payment
• Approvals
• Appendix A: Deliverable Descriptions
14
How Detailed Should A Statement Of

Work Be?
The challenging question for project managers when writing the statement of
work is deciding how much detail to include.
If you’re too scant in the details, it leaves a lot open to interpretation so there’s
flexibility to manoeuvre and pivot, but also opportunity for a client to try their
luck in getting things included within the project scope that weren’t included.
But include too much detail in the statement of work (SOW), you’ll find that
you’re stuck with an inflexible process and deliverables that might not be adding
to the overall value of the project. We rarely know exactly how a project is going
to go at the beginning of a project, so overly-defining it not only takes a long time
to write and get approved but you’ll find it makes it difficult to pivot the project
when necessary as you’ve defined away any flexibility.
So you need to strike the balance of making sure the statement of work get
signed off quickly while still ensuring that you’re raising the questions and
covering off potential problem areas.
Of course, there are lots of other things that you could put into a scope of work
like – definitions, project team, resource plans, supplier and client
responsibilities, acceptance criteria, specific service levels, reports, and that’s
just the tip of the iceberg.
So how detailed do you need to go? Well, if you think that there could be any
doubt or disagreement about anything in your statement of work, you probably
15
need to clarify if further. When projects go bad, the first place that the client will
reference is the statement of work – so if it’s not detailed enough, add in the
detail. You don’t want to bring up the statement of work, but when you do, it’s
worth having done it properly.
16
How To Write A Statement Of Work

(SoW): Checklist
Break it up: Don’t scope what you don’t know. Rather than trying to create a
statement of work for an entire project, split the project into phases and develop
separate statements of work for each phase as the project progresses.
Make a plan: Decide what you’re doing and how. Define the deliverables, and the
process required to produce them so you can clearly articulate what’s in and
what’s out of project scope.
Put it into context: Explain why you’re doing it. Make the purpose of the process
clear so even if the specifics of the plan evolve, the statement of work is clear on
how you’ll know if the process was a success.
Be specific: Set the project’s boundaries. Minimise the risk of misinterpretation
from your client by defining the extent of the work to done, and quantifying it
wherever possible so they don’t expect more than they’re paying for.
Make assumptions: Lay the ground rules. Use project scope statements to
explain mutual expectations and what has to hold true to properly execute the
project, being clear about what’s included, and what’s not.
Make it simple: Be clear and concise. Make it as short as possible, avoid words
with multiple interpretations, and ensure it’s easy to understand.
17
Share it: Make sure everyone knows. Keep it close, and know the statement of
work yourself – making sure your client and team are clear on what’s in and
what’s out by providing helpful reminders throughout the project.
18
How To Write A Statement Of Work

(SoW): A Step-By Step Guide
1. Break It Up
Not so much a step, but more a word of caution before you take the first step. It’s
tempting to try to create a nice, neat, fully baked statement of work at the
beginning of a project that includes strategy, UX, design, build, QA right through
to post deployment support.
It’s often what your clients want too – they ‘just’ need a statement of work for the
entire project so that they can secure funding. It can be tempting to oblige,
because you want to get things moving too and you don’t want to be the one
holding things up because you’re trying to get to the bottom of all the details,
right?
19
Hold your horse. It’s a terrible false economy. Not only is it going to take you a
long time to produce that statement of work properly, that statement of work is
going to be pretty much useless.
You might even feel like you’ve thought of everything and your statement of work
is watertight, but if the project hasn’t even started yet, your statement of work is
likely to be worthless even before the end of the first phase of the project.
It’s like going to meet an architect for the first time and asking them to tell you
how much it’ll cost to build a house. Their answer will be of course; ‘it depends’.
How big is it? How many rooms? What about the kitchen requirements? And
going into the finer details, how about fittings and finishes?
Like an architect could – you can tell them how much similar projects have cost in
the past, but that doesn’t mean that this project is necessarily similar in any way
to historic projects. So rather than relying on historic analysis, you’ve got to
break it up into more manageable chunks.
Know when you don’t know what you’re doing

Unless you’ve done this kind of project many times before, and this one is no
different, you’ve got very little to base your statement of work on. At the
beginning of the project, even if the client has written a comprehensive brief, if
you’ve not had a chance to define and architect the solution; there’ll be no
requirements, no UX, no design so trying to estimate development is going to be
tricky.
20
You need to know the solution before you can define the scope of the solution.
It’s like trying to estimate the cost of film production based on a script – without
a treatment and a pre-production phase, how can you know how much the
production will cost? Or an ad campaign without having first completed a
concepting phase. Know that it’s ok at this stage, to not to have all the answers.
Be honest with yourself, at worst, all you’ve got to base your statement of work
on is a snatched five minute conversation over a terrible conference line, or at
best, someone’s half-baked sketch on a scrap of paper. You don’t know what you
don’t know. So how can you create a complete statement of work?
Understand what your clients really need, and give

it to them
The reason your clients are pushing for that statement of work is because they’re
trying to make a viability call – can they make this project happen within their
budget? Your clients need to feel confident that if they’ve got a budget of X, then
it’s not going to end up costing them X + Y. The challenge for you is that at the
beginning of a project, no one knows exactly what is being created, yet alone how
long it’ll take, and consequently, how much it should cost.
What you can do is to develop a statement of work for only the things that you
really know. For the remainder of the project, split it into clear phases and assign
ballpark budgets for each of those phases. Here’s where you can use your
historic analysis to get an analogous estimate from previous projects to provide a
range which then can be finessed later.
21
How do you create that range? For starters, don’t make it too lean. Of course the
client’s going to happy if the number is low but it’s got to be realistic. The litmus
test for if the ballpark number is high enough should simply be; if you got this
budget, could you do something that meets the client’s expectations?
The planning horizon is closer than you think

So what do you really know, and what can you confidently estimate? At the very
least, with a well-defined project brief, you can create a robust statement of work
for an initial Define phase that then feeds into a Craft phase. As you complete the
initial Define phase, an output should be the development of the Craft phase
estimate, and you can continue refining your ballpark estimates phase by phase
throughout the entire project, developing one statement of work per phase as
you go.
An additional advantage of this is that it’ll take a fraction of the time it takes to
try and complete a statement of work for the whole project. Creating a statement
of work for just one phase, that’s well defined, is much quicker than trying to get
consensus on an unknown and somewhat mysterious future that’s about as well
defined as gazing into a crystal ball.
Don’t start with a plan to use contingency and

change requests
But what about contingency? Can’t you just create one statement of work and
plan to use the contingency if you have to? And if not, can’t you just issue a CR?
Please, no.
22
Planning from the start on nibbling on that little line item at the bottom of your
estimate shouldn’t be a given. Especially at the beginning of a project, when
you’re trying to develop and cultivate a new client relationship, it’s a terrible idea
to plan to have that conversation before you’ve been able to deliver them
something of value.
The last thing you want to be doing is having that conversation about using
contingency, or trying to explain to them that because you trussed up the
statement of work so tightly, you can legitimately issue a change request. The
client won’t be a happy bunny.
So don’t try to condense the entire project into a single statement of work. Don’t
over-extend beyond your planning horizon. Break it down.
23
2. Make A Plan
When you’re clear on what section of the statement of work you can feasibly
tackle, it’s time to begin the somewhat laborious task of detailing the phase
descriptions for the statement of work – it defines what you’re doing, how you’re
doing it and the deliverables for that phase of the project.
To recap, in the phase description, we’re looking to flesh out the following:
Phase breakdown
• Phase [n]: [Phase name]
• Phase description
• Deliverables and Assumptions
• Milestones + schedule
• Budget + payment
• Approvals
• Appendix A: Deliverable Descriptions
24
You should be able to base the phase breakdown on the draft estimate and
project plan that you should already have good client alignment on – the
statement of work is there to fill in the gaps of anything that could be open to
(mis)interpretation.
But it’s not uncommon (particularly with new business), for the estimate
and project plan to be bare bones, loosely defined at a high level, with few details
on the phase description, deliverables or any assumptions.
Make as many difficult decisions as you can

If that’s the case, in the process of creating the statement of work, you need to
make a clear plan of how you’re going to tackle the project. You might not know
everything, but you’ve got to start making some decisions.
If you delay those important decisions on the approach of how you’re going to
deliver the project, you’ll only have to make them a few weeks later, which might
impact your resourcing, the deliverables and the overall timeline and project
budget. It’s hard to make decisions at the beginning of the project, but it’s often
better to decide and be prepared to adapt it later, rather than making no decision
at all.
Solving this ‘what are we doing’ conundrum is particularly important in the early
phases of a project during the Define phase, there’s so much that you could do –
and no singular right way to do it. For example, during strategic development, do
you need stakeholder interviews, personas, journey maps and service blueprints
or will a simple solution strategy document do?
25
Similarly, during the Craft phase, do you need to do a complete content strategy
and creative concepting, or can you make do with what you’ve already got?
Together with your timeline and estimate, you’ve got to get some clarity on the
process and approach. There are always lots of things you could do, and your
role as project managers is to ensure you’re leading the team toward doing the
right things that’ll ultimately deliver success for the project.
Define or defer?
You’ll need to continually battle in writing a statement of work is whether to put a
stake in the ground and make a decision on exactly what you’re going to deliver
and how, or be vague and put off the decision making until later on in the project.
Sometimes deferring a decision is the only viable option but be sure to ask
yourself – if you really can’t define the plan properly, should you be including that
phase or activity within the statement of work at all?
If you decide to defer the decision on the process or the deliverable, at least try
to include some of the options for the deliverable, while being clear that you’re
not committing to them. For example, for design development you could say;
‘deliverables may include moodboards, style tiles, and design concepts delivered
as scamps’
Often, the client won’t even notice your vagary, sometimes they’ll trust you
anyway, and sometimes they don’t really care, but then all the pressure is on you.
You’re pinning your chances of success on the hope that the client just so
26
happens to like what you deliver. Sometimes it all goes swimmingly and you’re
golden. But what if it doesn’t?
What are you delivering?

The point of the statement of work is to ensure everyone’s on the same page.
Client-agency conflict frequently occurs around specific deliverables and whether
something was actually delivered – or not. The statement of work should ensure
that the description of the deliverable, or output is clear enough so that there is
no room for interpretation of whether it met the requirements of not.
So ensure you clearly define the deliverables and ensure that they’re well-
articulated with clearly stated acceptance criteria if needed. The goal here is to
get rid of the fuzziness. Are the deliverables clearly stated and described?
Make sure that the thing you’re doing or delivering is very clearly defined,
including the format. So rather than just saying ‘Deliverables for the design phase
will include mockups of webpages.’ Say instead – ‘Deliverables for the design
phase will be up to 10 x mockups assumed to be the homepage and a level 2
page (with 2 x additional variants of each) supplied as JPGs.’ It’s not a lot of extra
work to write out, but it takes away the risk of a client expecting an entire site
design or expecting ownership of layered PSD or Sketch files.
How are you delivering it?

As well as defining what you’re delivering, it’s worth including a description of the
process that you’re using to deliver it. This is important because if there’s
disagreement on the output, or deliverable, at least you can help the client
27
remember that while they may not like the final output (which is often subjective)
what they paid for was the agency to execute the agreed approach.
It’s still not a great negotiating position, but it’s better than not defining the
approach at all and leaving yourself at risk of the client suggesting the reason
they don’t like the outputs or deliverables is because the, ‘wrong’ process was
followed.
And what are you not delivering?

As much as it’s important detailing what you are doing, it’s important to detail
what you’re not doing too – don’t forget to add in negative scope. Negative
scope, specifically states work that will not be done under the statement of work.
Often adding clarity around what you’re not doing or delivering helps to block in
the canvas more clearly. This is all about expectation management – if the
deliverables are complex or a client might expect something to be delivered that
you’re not planning on delivering, be sure to articulate that clearly. Particularly if
on previous projects you’ve always done something a certain way, and you want
to change the process, don’t just leave it out, make it very clear what you’re not
doing.
28
3. Put It Into Context

Context is everything. Without proper context in SoWs, deliverables can be
subjectively deemed unacceptable and outputs are wide open to being
misinterpreted by clients. So how can you make sure your statement of works
genuinely limit liability and risk of rework? How can you shift the focus from
micro-evaluation to big picture thinking with your clients?
The key is in helping clients understand a shift in focus from ‘what’ we’re
delivering to ‘why’ we’re delivering it and ‘how’ it fits into the bigger picture so
they understand the context of the process and work delivered.
Successful Statement of works focus on overall

project success
It’s one thing to describe an activity and its outputs in your statement of work;
it’s another to complete the activity to the level and degree that your client is
going to be happy with.
29
Knowing why, or the purpose of the project and what success looks like for the
client enables you to work into each deliverable a recipe for success. This makes
each activity and its output makes it much easier to clarify with a client whether
or not the deliverable is fit for purpose. The real benefit of this is that it takes
away the subjectivity of clients in assessing whether or not something has been
completed properly.
This starts with stating the goals and objectives of each phase – in part these will
always be the ability to proceed to the next phase. You can even outline the fact
that ‘successful delivery of this phase is assumed to be viability of deliverables to
enable continuation to the next phase’. This provides flexibility to pivot to enable
an ability to meet the overarching goal and objective of the phase. If you can
demonstrate that it’s fit for purpose, at least in being able to progress to the next
phase of the project, it provides greater opportunities to change request (CR) a
client if they ‘…just don’t like’ something that you’ve produced.
Good enough is not a compromise, it’s part of the

journey
We’re trying to help the client understand that we’re not necessarily striving for
perfection at every step of the way but we’re going through a process that will
get us to where we need to go. To do that, we need to be really clear about the
purpose of everything that we do – so that it’s not just work for work’s sake, and
so it doesn’t unnecessarily hold up work later in the project. The beauty of digital
is that we can finesse things later if there’s time and budget to do so. The danger
is that we can get tied up finessing the wrong things because we lose sight of the
overall vision of the project.
30
Why are we doing this?

For example, while producing a storyboard for a video is useful, it’s purpose is to
align everyone on the flow, the style, the shots and bring the treatment to life –
it’s not the time to worry about whether or not the pictures are quite right or not.
We just need approval of it, so we can move into pre-production.
Similarly, for a website build, if you’re trying to get sign-off of a sitemap – the
reality is that the pages can be moved around pretty much anywhere so it’s a
starting point rather than something that has to be 100% locked down. You want
to simply get buy in that this is good enough – this is well enough on the right
track for us to continue going in the direction.
Without that context, and without the accompanying description of why we’re
doing the work and clearly outlining the purpose and goals for what we’re trying
to achieve, how can we really say that we’ve done it?
And did it do what it was supposed to do?

You must adequately describe what the work is and the criteria for how you both
will agree that something is successfully completed. Clients get upset when they
think they paid for something, but didn’t get what they asked for. So in your SoW,
define the activity, the outputs and deliverables with acceptance criteria for all
and be sure to demonstrate the linkage of how the deliverables feed into the next
activity. This is how we can ensure that we deliver something that the client is
going to be
31
Make it clearer than clear

Don’t forget that getting the context right is a mutual responsibility – with clients
needing to take ownership too. A statement of work (SoW) should clarify for both
client and agency what constitutes success or failure. For example, if you’re
working collaboratively with your client and they have responsibilities to deliver
specific assets or components into the project, such as image assets, set the
acceptance criteria for those assets to be considered complete. Often a lack of
proper assets that can hamstring a project’s success. So define carefully the
acceptance criteria for not only your own deliverables, but also those for which
you’re depending on your clients.
Make sure it’s all wrapped up in the project

information
When you’ve finished detailing all the phases and you’re clear about the context,
you should be in a good position to go back to the project information section of
the statement of work, and finish off the descriptions, particularly around the
project summary and process.
32
As a recap, check to see you’ve got the following covered:
Project Information
• Project Summary
• Project Process
• Project Milestones
• Overall Project Governance
• Terms and Conditions
• General Assumptions
33
4. Be Specific
It’s the grey, loosely defined deliverables that always come back to haunt you on
a project. Neglecting to resolve the grey areas will only lead to conflict later. So,
what are the areas within a statement of work (SoW) that you should specifically
look to clearly define?
Tighten everything up (with numbers when

possible)
Particularly with creative phases of projects, you don’t want to leave open to
interpretation whether or not you delivered properly. Clearly define the
acceptance and feedback loop. This is essential if you plan to complete the
project and still maintain a great relationship with your client.
Don’t be loose in describing activities like reviews and amends. When you
describe an activity such as ‘includes client feedback cycle’ it’s very different
from spelling out:
34
‘The client’s final written acceptance or consolidated feedback is due within 3 x
days of each deliverable submission. Up to 2 x rounds of consolidated feedback
and amends (timeboxed to a total of 8 x hrs) have been factored into the project
scope. Any requests for out of scope amends will be assessed and may result in
additional costs and delayed timescales.’
The difference in effort in writing this is minimal – but the clarity that it provides
the client and the platform it creates to create Change Requests for any
deviations is hugely important.
Be prepared for the reality of clients

Remember clients will often try to drop in additional reviews, late ‘I just got
around to showing my boss’ feedback, and last minute “tweaks” – some of which
may be major scope revisions on your end. So be clear how many review cycles
and changes you are committing to in the statement of work; and then be ready
to start filing change orders and set expectations up front that any deviation from
the statement of work will necessitate a change request (CR).
Timebox when you don’t know

Sometimes we’re not sure how long things should take, but don’t let that leave
you open to risk. Instead of avoiding the details or simply saying a task will take
“a reasonable amount of time,” instead write, “It is assumed the specified task
will take no more than 4 x hours.”
35
Make everything clear and unambiguous. The more precise you can make it, the
more quantitative, the better. And when you’re quantifying things, be sure to
adjust your estimate to reflect any changes.
Spell it out in full

Is there anything that could be misconstrued? Try not to use words with multiple
interpretations. This may seem like something of a no-brainer, but contracts and
their supporting documents are the realm of the fine-tooth comb. Do not use “the
project” when what you really mean is “the second round of business
requirements interviews.”
You can’t afford to be lose with your language and definitions. Be laborious in
spelling out every activity and deliverable. Never let phrases like “either” or
“and/or” into your SOW. Spell out exactly what you are going to do. But don’t
over commit. When don’t know exactly what you’ll do, avoid committing to
something you cannot; don’t use ‘will include’ when you really mean ‘could
include’.
Communicate to be understood (not to broadcast)

When you hear the fateful words; ‘that’s not what you said you’d be doing…’ from
your client, you’ve failed. Whatever the reason, you haven’t been clear enough in
communicating what’s going to be delivered. The last thing we want a client to do
is to refer to the statement of work (SoW), but if they do, we need to be 100%
sure that what they read in the SoW.
36
Here lies the challenge – of course in your statement of work it’s obvious to you
what you meant when you wrote it. And you think you’d have to be pretty stupid
to (mis)understand otherwise. But you wrote it. So when you’re developing your
statement of work you can’t afford to give yourself the benefit of the doubt
because the client certainly won’t.
The truth is, if you’ve written something in your statement of work that can be
misconstrued it’s your fault. The challenge of writing a great Statement of work,
and more broadly with communication, is that the onus is on the one delivering
the message – that’s you – to ensure you’re being fully understood.
When are you off the hook?

Finally, unless you’re working on a retained basis, it’s important to be very
specific in defining when exactly the project is complete. The scope of work
should clearly define when a project is complete and all in-scope deliverables are
delivered – and to what extent maintenance or ongoing support is included.
When the immediate bug fixes are complete, scope creep often surreptitiously
rears its ugly head. There should be a very clear line drawn between bug fixing
and enhancements. In part this is because some of the biggest and worst
mistakes to projects are made trying to make quick fixes to a project in the days
just after it has gone live.
In a pitch? Don’t share your recipe

There’s one caveat worth mentioning Especially when you’re working on a
competitive pitch, when you’re writing the scope of work don’t fully reveal how
37
you’re planning on approaching the completion of the work. It’s one thing to sell
the cookies, it’s another to give away the recipe. Sometimes with more
unscrupulous clients you can find that they ask for a scope of work so that they
can shop it around and get the best price with other agencies. In these instances,
make sure you’re not being too specific as it’ll make it very easy for them to get
others to quote on it. If they come back to you and say they want to proceed then
you can always rework the statement of work with additional details before
signing it.
38
5. Make Assumptions
A dog might be a man’s best friend but in the case of the project manager, that
best friend is always the ever-trusty and forever-loyal statement of work
assumptions. They’re your get out of jail free card, and often the difference
between delivering on budget or not.
Without assumptions, you’re the proverbial ship without an anchor and will be
tossed around in the storms of clients’ misunderstanding and soon find yourself
wondering where it all went wrong.
How far will you go?

A statement of work is great for outlining the approach and clearly outlining the
activities that will be undertaken as well as the deliverables. But it’s the
assumptions that detail how far you’re able to go to get the job done, within the
budget and the timeline. Assumptions enable you to block in the canvas – they
tell you how much you can afford to do; how long you can afford to take.
39
If you assume that the client knows what you’re assuming, it’s going to leave you
with an eggy face. Assumptions enable you to set boundaries of any activity and
the associated deliverables. There’ll be generic assumptions that should align
with your master services agreement (MSA) and activity/output/deliverable-
specific assumptions that you’ll need to tailor for each activity
Cover the basics with generic assumptions

With every scope of work (SoW) it’s worth reiterating some generic assumptions
that you can apply to any project and match up with your standard terms and
MSA. They define things like is the project cost timeboxed? How many review and
amend cycles are included – these tends to be the stickiest part of a project so
make sure it’s in there. Who’s going to pay for what 3 rd party costs? Is tax
included or excluded?
Here are some typical issues that can derail a project that it’s worth covering off
in your generic assumptions:
• How many clients you’re able to liaise with and who is their signing
authority
• How you will deal with client delays
• When clients will need to make themselves available for presentations
• How long clients will need to approve deliverables
• How many rounds of review and amends will be entertained
• What expenses are included and not, including travel, travel time, per
diems
40
• What third party costs are included including hosting, image rights and
fonts
• What happens if new information is uncovered that changes the project
scope
• How changes to project scope will be managed
• How often status reports will be provided with budget and risk details
• What the billing rate and invoicing cycle will be
• Who owns what when the project is over to clarify intellectual property
ownership
• Who takes responsibility for the copyright use of client-supplied assets
• Who takes responsibility for the grammar, spelling, factual and legal
accuracy of content
Project scope statement examples

Based on the generic assumptions outlined above, you can tailor this project
scope statement example which contains a host of generic assumptions that
you’ll want to include within your statement of work.
• The client and AGENCY will each establish a single point of contact
for their respective teams. All decisions including approvals and
scope changes will be made through these two individuals. The
client point of contact will be its designated Project Acceptor.
41
• If a delay occurs in obtaining a sign-off due to delays caused by the
client team and not due to non-performance by AGENCY, there may
be an increase in costs and/or extension to the timeline, for which
the client is responsible.
• The client’s final written acceptance is due within 3 days of each
deliverable submission; further delays may result in additional
costs and delayed timescales. These terms are applicable for
AGENCY for this project though not stipulated in the overall agency
contract. This will be built into the project plan. The number of
reviews may decrease to keep on schedule but will be collectively
determined between the Project Manager and Client Acceptor.
• Two rounds of revisions for each deliverable have been included
where appropriate and possible as specified within the project
plan. If the client exceeds the defined number of revisions for a
specific deliverable, the project scope will be exceeded and the
project timeline and budget may be affected.
• Any requested changes to the project scope, schedule or budget
must be submitted to the AGENCY Project Manager or Account
Director. Other AGENCY team members are not authorized to
approve changes in project scope, schedule or budget.
42
• The costs included have been based on the information supplied by
the client and the stated deliverables. All outside expenses,
including, but not limited to travel and lodging per day, shipping,
supplies and rental equipment are not included in the Fixed Price
and will be billed to the client in addition to the fixed price on a
monthly basis in arrears.
• If the scope of the project changes from the specifications agreed
or AGENCY is required to provide additional services not described
in the project plan (i.e. additional reviews), such changes will be
documented in a Change Request and may impact timing and
costs. The Change request will require sign-off by the Project
Acceptor before work described therein can commence. AGENCY
will invoice the client for the total change request cost.
• The project depends on the close involvement of the client’s
internal teams to provide input, and to review and approve
deliverables in-progress, and to be available for presentations and
conference calls throughout the engagement. The client will also
be responsible for obtaining the necessary involvement of
additional business stakeholders as appropriate and collating their
feedback.
43
• AGENCY Project Manager will provide a weekly status report to the
Project Acceptor. High priority issues and risks will be identified in
these reports.
• All software, documentation and other materials comprised in the
Deliverables which were in existence prior to the date of this
estimate, together with any device, programming, documentation,
media or other materials used as a programming tool by AGENCY in
the development of the Deliverables, proprietary to AGENCY and
not designed primarily for use or primarily used in conjunction with
the Deliverables together with all intellectual property rights in
such “Pre-Existing Materials”, shall remain the property of
AGENCY.
• AGENCY shall make the client aware of any software,
documentation or other materials, the intellectual property rights
in which are owned by a Third Party (“Third Party Materials”)
together with the terms of use applicable to such Third Party
Materials.
• The client will be responsible for providing AGENCY with pre-
approved electronic files of all logos, product images, written
content, and subject matter experts as required. The client will be
44
responsible for ensuring that they have all necessary rights and
licenses to such assets.
• The client will be responsible for factual accuracy and legal
approval of all content. Textual content will be grammar/spell
checked and approved by the client before being integrated into
any Deliverable.
• The client will be responsible for management and coordination
with AGENCY and all internal client Stakeholders for this project.
• This statement of work is limited to hours available within the total
project estimate; contingency only utilized with prior approval.
• Project scope is based on the described activities – deliverables are
assumed to be a representation of the recommended approach.
Should the approach change, or additional currently non-specified
requirements be added, change requests may be issued.
• Content, imagery and links will be supplied by before AGENCY will
begin work on the task
45
• This estimate is priced in US dollars.
• These costs have been prepared exclusive of tax.
Tailor your statement of work (SoW) with specific

assumptions
While the generic assumptions are easy to produce and can be recycled over and
over again, the specific assumptions are a bit more complex and require some
more thought. Generic assumptions are a great backup but within the statement
of work (SoW), as well as including the stage description and deliverables, you
need to add in specific assumptions – how you’ll limit the activity and
deliverables. For each activity and deliverable, there should be some tailored
assumptions.
At the very least, make sure you’re putting limits to areas of the project which
tend to attract scope creep. This is where some empathy is important – try and
view the project through a client’s eyes. Anything that the client could turn
around and say, ‘I thought you were going to do more than that!’ should have
some limit defined. For example;
• xx timeboxed hours per deliverable
• xx of templates / pages / components
• xx rounds of consolidated client feedback
• xx time boxed hours for amends
46
Negative assumptions – be clear what’s not

included
Finally, consider writing some negative assumptions to further clarify not only the
limits of what you will do, but what you will definitely not be doing. Clients always
think that they’ve paid for more than they actually have. So put yourself in the
mind of the client. Think about what they might could possibly have thought
might be included within the project scope but is not. For example:
• Sourcing image assets for content: “We haven’t got any images, we
thought you could find some on Google!”
• Writing, sourcing or translating content: “I can’t get any content from our
team; are you ok to pull something together?”
• Creating summary decks for management: “This is great but can you
summarise all of this into a deck so I can get buy in from our CEO?”
• Creating other language locales: ‘Sorry, I just remembered we had a
French site we need to include too, that’s fine, right?
• Translating content: “We just need this to work in Mandarin too…”
47
6. Make It Simple
It’s good to be proud of your work, but if you think your scope of work is more
watertight than a submarine and you’re patting yourself on the back because it’s
the longest and most complicated SoW you’ve ever written (or seen) then you’ve
probably got a problem.
You need to keep it simple.
Simply robust
There’s an important flip side to all the detail we’ve covered in this series on
creating statements of work; putting it into context, being specific and making
assumptions are critical to writing a scope of work (SoW). But so is keeping it
simple. It’s a balance of ass-covering so everyone’s crystal clear on the work to
48
be done, with providing detail so that deliverables are explicit, definitive and
precise.
Mind your P’s and Q’s – a guide to simplicity

To help keep it simple, bear the following in mind. Use short, simple sentences.
Watch out for pyramiding or tautological specifications with references to other
references. Don’t use words with multiple interpretations. When describing
deliverables, avoid the danger words. Danger words leave you overcommitted to
delivery. Examples of danger words are:
• All
• Every
• As required
• Adequate
• As many as possible
• Average
• Certified
• Standard
• Subject to approval
• Detailed
• Subject to approval
Leave no stone unturned?

You can start diving so deep into detail that you find yourself digging a hole that
you can never get out of. Writing a statement of work can sometimes feel like
49
reading a good book. After a while you get so attached to the characters, you’re
not sure you want it to end. Remember though, that if you’re spending time
writing a statement of work, it means the work hasn’t started and you’re eating
into your timeline. Provide ‘just enough’ detail to be robust and clear and so you
can begin a discussion with the client about the contents.
No time for smarty pants

When writing a statement of work (SoW) you really should not be trying to show
how smart you are. There can be a temptation to showcase our smarts and make
statements of work super complicated and intricate, but instead, lay hold of the,
‘keep it simple, stupid, mantra – your statement of work should not only be
simple to understand, but simple to write too. Don’t use unnecessary narrative
and avoid redundancy where you’re essentially repeating yourself. Ask yourself,
what can you take out without losing the integrity of the statement of work? Do it.
You’re not a lawyer

There’s no doubt that your inner lawyer can begin to rear its ferocious head when
you start writing statement of work. While it might also serve as a legal
document, in an ideal world it never will. The statement of work shouldn’t be
written in pure legalese, but as a talking tool for aligning perspectives on what’s
actually going to be produced. You should be simply describing the requested
goods and services in clear and understandable terms.
50
7. Share It
After creating your statement of work, and ensuring that it’s crystal clear with
activities and deliverables broken down, put into context with clear language,
assumptions and assumptions and properly checked – it’s time to share it with
your client.
One of the reasons it’s important to talk your client through the scope of work is
so you can establish if there is any ambiguity around any of the deliverables so
that you can align with what’s actually going to be produced, then document it.
But double check it first

In the euphoria of finishing a statement of work (SoW), the temptation can be to
hit save, dump it in an email and send it on its merry way. After all, the process of
pulling one together is usually somewhat painful; you just want to see the back of
it.
51
But without checking your SoW properly, before you send it, you can end up in a
world of pain later. You could spend weeks refining a statement of work and but
the incremental value of doing so will be negligible, so take an hour to do some
double checking, and then get one of our team mates to check it too.
In the same way that you check your pockets or handbag before you leave the
house, make sure that your scope of work has got the essentials covered off. Is
the work breakdown set out in logical and chronological order? Are the activities
and outputs or deliverables clearly stated and described? Have you provided
enough context to ensure so that they’re not misinterpreted? Are your
assumptions, client responsibilities and dependencies as well as rounds of
feedback and acceptance criteria clearly stated? Read the scope of work and
specifically find those SoW loopholes – then fill them.
Are you forgetting something?

Now take a gut check. Does this feel right or not? Make sure your statement of
work (SoW) is framing the business problem and telling a story of how the
problem can be resolved – will the client feel like they’re getting value? The
scope of work needs to show how the solution is actually solving the client’s and
their users’ needs.
Finally, be empathetic, put yourself in your client’s shoes – is this project a bit of
a stretch or is it realistic? Make sure you are not overcommitting yourself or your
team – you need to be able to deliver the project on time and budget with the
scope you’ve defined. If it’s looking dicey before you’ve even started you need to
adjust.
52
Find your legal eagle

Usually the statement of work (SoW) forms part of the legal contract and should
align with the MSA (Master Services Agreement). Make sure you’re reviewing
both to ensure there are no conflicts or inconsistencies especially around rate-
card, expenses, travel time, 3rd party costs or invoicing schedule.
Is it really up to date?
Timelines constantly shift. So by the time that you’ve finished writing your
statement of work (SoW), the original timeline that you were working from has
probably shifted too. Double check to ensure the start date is realistic and that
the milestones and deliverables are still valid too. And whenever you’re updating
your timeline, remember to update your non-working or stat days – if you’re not
careful, if you haven’t updated them properly these could take a week out of your
timeline before you’ve even started.
Proofread
Finally, read it right the way through again. Yes, really, no cheating. Everything
communicates so make sure your grammar and punctuation is all tickety-
boo. And don’t just trust your eyes, again, borrow a pair of eyes and get your
scope of work reviewed by other knowledgeable people and honestly analyse
their comments before hitting the send button.
53
What’s the catch?

Depending on your client’s previous experience they can be understandably
nervous about signing of your statement of work (SoW) because they’re worried
that you’re not actually going to deliver what they need. Their ass is on the line
and ultimately they don’t want to lose their job. Particularly if the clients don’t
fully understand what they’re agreeing to, they can get nervous about signing off
a statement of work and you start a painful back and forth of revisions that takes
weeks to be resolved. We need to help them understand the SoW isn’t a cunning
trap.
Catch them up
Talk it through – as much as possible, don’t just hand it over with no explanation.
Don’t just put it in an email and hope for the best. You don’t want to seem
disingenuous – you’re not going to build trust with the client and nor are you
going to get it signed off quickly if you don’t help explain to them what you’ve
done, and why. The purpose of the SoW isn’t just to cover our back’s, it’s to align
expectations on both sides.
So instead of sending the statement of work over by email, make the SoW
finalization a conversation, rather than a one-sided rant. Start with reviewing the
project goals and the criteria for success and then join the dots by sharing the
context for the approach, the specifics around the deliverables, your assumptions
and why you’ve made them and how this all ultimately leads to project success.
54
Team up
Start the process of working with your client to tweak it together to ensure that
the approach and deliverables are understood and clearly articulated. They need
to be comfortable with what they’re signing off. It should feel like it’s a team
effort – by involving the client there’s a shared ownership which will build trust
and expedite the signoff process.
Ultimately you’re trying to make a conscious shift away from getting a glorified
and horrendously complex estimate approved to a shared understanding of
success and the best way to get there. Don’t forget to be honest about what you
don’t know. Educate the client that you don’t know everything yet – you’re not
going to able to include everything within your statement of work. In many ways,
at this stage, it doesn’t matter, as long as you’re clear about the assumptions
you’re making.
It’s not an all-inclusive deal

In your conversations and detailed in your statement of work (SoW), you need to
be particularly clear about what’s not included – Obviously it’s impossible to
detail everything a project isn’t going to include, but be sure to discuss areas that
are specifically excluded which may include thingslike legal advice for contesting,
content generation, asset sourcing and licensing, video, images and fonts. These
things, can start becoming very expensive, especially if your clients will need to
fork out each year to renew licences so help them understand what they’re
getting themselves into.
55
Additionally, think about expenses, travel, travel time, user testing, incentives,
email broadcasting and any post-launch work or optimisation including bug fixing
which is part of the software development lifecycle. Finally, be clear about
whether or not the development of SoWs for future stages of the project are
included.
Sharing is caring
Teaming together to tweak and get signoff on the statement of work (SoW) will
ultimately make your life easier. Yes, it’s caring for your clients but really you’re
doing yourself a favour too. If the project hits a significant snag, rather than
resorting to pointing to the statement of work, a document, you have a
conversation to refer to; ‘Remember when we discussed…’ is much better than
telling the client; ‘But in the statement of work it says…’. The reference point
shifts from a document to a relationship which has a much better chance of being
successfully resolved.
56
How To Use A Statement Of Work

So you’ve finally got your statement of work (SoW) signed off – now the real fun
of keeping the project on track with the statement of work really begins. If you
don’t stick to the statement of work there’s a high possibility you’re going to end
up not quite delivering on the project goals or what the client needed as well as
late and over budget too. So how do you stick to it and keep your SoW on track?
Know It
Whether you wrote the statement of work or you inherited it from one of your
colleagues, you need to know it well – if you don’t, how can you be sure your
team is doing the right thing? And it’s always embarrassing it the client brings up
something that you’ve written in the statement of work that you’ve totally
forgotten about. Print it out, save copies of it l
Be sure to keep a copy of it on hand. You may even want to print it out and makes
notes on it. Whatever you do, make sure that you can pull it up when you’re on a
call or in a meeting because whenever it’s in question, everyone will look to you
for answers.
Start by taking ownership for it and owning delivery of it. Print it out, have it on
your desk, so you can quickly refer to it. You need to be best buds with your
statement of work. You’re the guardian of the project so if you’re not 100%
confident on what’s being delivered, how is anyone else going to know? Get
familiar enough with it so that you know the details without having to refer to it.
57
That level ownership is going to inspire confidence in the team as well as the
client and enable you to deliver to it.
Spread The Word

It’s not good enough though for just you to know the statement of work (SoW).
As digital project managers we’re rarely the ones actually doing the work so our
team needs to know it too. Even if they were involved in architecting the
Statement of work it’s bound to have changed and evolved so make sure they’re
fully aware of what success looks likes and understand the activities, deliverables
and assumptions. If you fail to communicate the details of the project properly
with your team you can find them semi-innocently wandering off course. So
circulate the SoW, print copies for them, stick it on the walls of your war room,
make it visible and ensure everyone’s familiar with it.
Get Everyone On Board

Don’t be too dogmatic. Chances are, the team that helped you create the SoW
isn’t the team that’s now working on the project. So if your project team thinks
that something doesn’t make sense or isn’t ultimately going to drive the success
of the project, give them the opportunity to work together to refine the statement
of work. If it’s good for the project then you should be able to make a case to the
client. There’s never value in doing work simply because the statement of work
dictates it – it should always create value for the project.
58
Keep Talking
Don’t be afraid of bringing up the statement of work in your client meetings – in
fact make it a conversation topic in your weekly status meeting. Discuss if the
SoW is still valid, and whether things going to plan. If there are things that need
to be adjusted and then adjust them and make sure everyone’s aware of the
changes. Watch out though – remember all of that work you put into your plan?
Don’t let it all go down the drain by succumbing to every new request or pivoting
to every new idea.
Watch For Scope Creep

Firstly, what is scope creep? A simple scope creep definition could be defined as
– when the scope of a project begins to grow, seemingly sneakily. Typically, it’s
when a that feature starts off as one thing but somehow (cue clients
asking/demanding), slowly evolves or morphs into something a much bigger
feature that costs more to deliver than was initially scoped.
Clients are always full of good ideas, and often have no idea of the implications of
what they’re asking. Classic scope creep examples are when a client asks for an
additional round of creative amends that weren’t accounted for, or when a client
asks for a ‘favour’ which wasn’t budgeted for, like an additional format for a
banner campaign.
Watch out too for gold-plating; it’s when scope creep is out fault. Someone on
your team wants to do an awesome job and so starts over delivering and giving
the client more than they paid for, which would be great, if it wasn’t for the fact
59
that similarly to scope creep, it hasn’t been accounted for, so takes the project
over budget.
But back to scope creep, how to avoid it? The first step to avoid scope creep it is
to make sure you’re identifying it – call it out for what it is as quickly as you can.
To identify scope creep you need to know your project scope well enough so you
know what’s in and what’s out of the statement of work.
Be wary when a client starts using phrases like – ‘Can we just..’, ‘One little
thing…’ , ‘Would you mind doing me a favour…’ – if they’re saying things like
that, it means they know it’s not really included in the project scope and you need
to remind them of it. Refer back to the statement of work and help them
understand that what they’re asking for wasn’t included.
After identifying the scope creep, try chatting the situation through with the
client and give them some options. Can you trade their request for a new feature
by taking out something similarly sized? Does extending the timeline create any
efficiencies? Can you include their new feature request in a new project?
Assuming it’s more work, you should issue a change request – basically an
update to the statement of work that details what you’re going to do with a
description of the change, explain how you’re going to do it with the revised
approach (explaining what you’re doing differently from the original project
scope), as well as the budget and timeline implications.
60
Start How You Need To Finish

Finally, remember that projects that go off the rails often do so in the very early
stages of the project when PM’s don’t want to rock the boat by raising issues
when they should. The knock-on impact of being too flexible in the first few weeks
of a project can be huge.
Not only does it leave you with catching up to do but it sets an expectation with
the client that the scope of work is more flexible than it really is. That first version
of your plan is your baseline and it outlines every step you need to take to get
from the beginning to the end of your project. You don’t just make these things
up!
61
Further Reading On Statements Of

Work (SoW)
If you’re looking for even more information on writing statements of work, check
out some of the other great articles we’ve found on creating a scope of work
(SoW).
• Agreements = Expectations:
https://alistapart.com/article/agreements-equal-expectations
• Scope Of Work Example: Guidelines To Prepare An Effective Contract:
https://blog.udemy.com/scope-of-work-example/
• Must-Have Items On A Scope Of Work (SOW):
https://www.thebalance.com/must-have-items-on-a-scope-of-work-
sow-844916
• How To Define An Agency Scope Of Work To Deliver Increased Value:
https://www.trinityp3.com/2017/03/define-an-agency-scope-of-work/
• Tips For Writing A Statement Of Work:
http://pics.olao.od.nih.gov/pics_sowtips.pdf
• Tactical Tips For Creating A Successful Deliverables-Based SOW:
http://www.techrepublic.com/blog/it-consultant/tactical-tips-for-
creating-a-successful-deliverables-based-sow/
• Writing A Statement Of Work: http://www.computerworlduk.com/how-
to/it-business/4/writing-a-statement-of-work/
62
• How To Write A Statement Of Work:
http://www.computerworld.com/article/2555324/it-management/how-
to-write-a-statement-of-work.html
• 50 Tips For Your Statement Of Work (Sow):
http://www.con-tracts.com/id16.html
63

Statement of Work (SoW) - A Guide To How To Write A Scope of Work

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Statement of Work (SoW) - A Guide To How To Write A Scope of Work

Uploaded by

Copyright:

Available Formats

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

What are you going to find here:

• What is a statement of work? A SoW definition

• Do you really need a statement of work?

• What should a statement of work contain?

• Statement of work example

• How detailed should a statement of work be?

• A statement of work checklist

• How to create a statement of work: a step by step guide

• How to use a statement of work

• Further reading on creating a statement of work

What Is A Statement Of Work? A SoW

these different terms – statement of work, scope of work and SoW?

In project management, SoW is an acronym for Statement of Work. Alternatively,

Put simply, a SoW, or statement of work is an agreement between a client and

including detail around deliverables, process, defining what's acceptable, what’s

to keep it as lean as possible.

A Statement Of Work Defines The Work To Be

© 2017 The Digital Project Manager. All Rights Reserved.

information and defines detailed deliverables, standards, criteria and

requirements for each phase.

approach. In creating a statement of work you’ll probably end up adjusting your

but forgot to.

deliver and achieve.

document. If you’ve already created a project plan or timeline and a project

detail, and ties everything together.

© 2017 The Digital Project Manager. All Rights Reserved.

What Is Project Scope And Why Does It

realm, gamut, spectrum or spread of the work that’s to be done.

questions and more so that there’s a shared understanding of a project.

Statement Of Work Or Scope Of Work –

work that the document codifies and defines.

interchangeably; they all describe the agreement of work to be done. Hereafter,

for simplicity, we’re going to use the term statement of work.

© 2017 The Digital Project Manager. All Rights Reserved.

Do You Really Need A Statement Of

paperwork? Particularly if you subscribe to an agile approach to documentation –

days of producing a statement of work are over?

Nice try, but no.

to include a campaign landing page.

reason clients and agencies end up in conflict. When there’s uncertainty or

and how much it’ll cost.

© 2017 The Digital Project Manager. All Rights Reserved.

Producing a statement of work is a lot of work so you don’t want to create it

lots of the detail.

In our previous guide on estimating projects we talked about three phases of

© 2017 The Digital Project Manager. All Rights Reserved.

What Should A Statement Of Work

project so everyone knows the boundaries of the project.

As a minimum, it should clearly detail:

• 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)

© 2017 The Digital Project Manager. All Rights Reserved.

Should You Use A Master Services Agreement

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.

details of the project.

An MSA will typically address high level topics such as: