Unite remote teams with VOGSY, the project management tool for G Suite fans.
Try for free on Google Cloud.

Our friend and supporter

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.

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.

powered by Typeform

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 work statement 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, the SoW document 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 project 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.

Statement Of Work Example

Scope Of Work Examples

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

Phase breakdown

  • Phase [n]: [Phase name]
  • Phase description
  • Deliverables and Assumptions
  • Milestones + schedule
  • Budget + payment
  • Approvals
  • Appendix A: Deliverable Descriptions

More Statement Of Work Examples

Because SoW documents are such a massive undertaking, I’ve put together a complete sample Statement of Work that can help anyone who wants to get a jumpstart on their SoW in project management. The example Statement of Work and a SoW template for you to fill out are available in DPM Membership. I’d love to have you in our community of 350+ active and growing digital project managers!

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 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.

How To Write A Statement Of Work (SoW) In 7 Simple Steps

how to write a statement of work - infographic

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

Looking for a rock-solid Statement of Work template?

Would a filled in sample help?

Become a DPM Member to download it (plus get access to 50+ additional templates and samples)!

By joining our community of DPMs you will:
  • Save time with 50+ expert-crafted project templates and samples.
  • Get a leading edge with live and on-demand workshops led by industry experts.
  • Find a tribe of support, mentorship, and networking with mastermind groups.
Want in?
Are you Pro Member? Sign in to unlock the content.

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 meet­ing 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. 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.

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 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.

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!

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


Our friend and supporter:

Unite remote teams with VOGSY,
the project management tool for G Suite fans.

Ben Aston

About Ben Aston

I’m Ben Aston, a digital project manager and founder of thedigitalprojectmanager.com. I've been in the industry for more than 15 years working in the UK at London’s top digital agencies including Dare, Wunderman, Lowe and DDB. I’ve delivered everything from film to CMS', games to advertising and eCRM to eCommerce sites. I’ve been fortunate enough to work across a wide range of great clients; automotive brands including Land Rover, Volkswagen and Honda; Utility brands including BT, British Gas and Exxon, FMCG brands such as Unilever, and consumer electronics brands including Sony.


  • Valerie Lim says:

    Awesome guide here. Love it.
    The question of when is missing here. During quotation, done together with contract BEFORE the project is accepted and signed by client?
    I’ve got a couple of factors and scenarios in mind. Too many to pen down.
    It would be great to hear your point of view!

    • Ben Aston says:

      Hey Valerie, glad you found it helpful! In answer to your question – it depends! I wouldn’t want to create a statement of work before you had a contract in place with a client because it could be that you’re totally wasting your time. However, the contract that you have in place should be more like a Master Services Agreement defining how you’re going to work together. But I’d also refer you to my Project Planning post – here I suggest that you increase the fidelity of your plan (and definition of the scope) as the client demonstrates their willingness to move ahead with the project when they’re aware of the ballpark costs and timeline. Usually with three different stages:
      – Ballpark estimate – When the client is trying to work out if they have the budget to do a project.
      – Budget estimate – When the client thinks they have the budget and needs some more detail.
      – Definitive SoW estimate – When you’ve completed all due diligence and need project budget approval.
      Check it out here: http://thedigitalprojectmanager.com/project-budget-cost-estimation-guide/#5-estimates-methods

  • Maria says:

    Great blog post!

Leave a Reply