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

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

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

How to write a statement of work (SoW) - complete guide free download

What Is A Statement Of Work? A SoW Definition

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

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

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

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

A Statement Of Work Defines The Work To Be Done

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

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

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

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

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

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

What Is Project Scope And Why Does It Matter?

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

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

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

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

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

Do You Really Need A Statement Of Work?

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

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

Nice try, but no.

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

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

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

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

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

What Should A Statement Of Work Contain?

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

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

As a minimum, it should clearly detail:

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

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

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

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

An MSA will typically address high level topics such as:

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

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

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

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): Checklist infographic

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.

How To Write A Statement Of Work (SoW): A Step-By Step Guide


1. Break It Up

how to write a statement of work guide - break it upNot 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?

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.

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.

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.

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.

2. Make A Plan

how to write a statement of work guide - make a planWhen 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

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?

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

3. Put It Into Context

how to write a statement of work guide - make a planContext 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.

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.

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

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.

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

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:

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

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.

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

5. Make Assumptions

how to write a statement of work guide - make assumptionsA 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.

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

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…”

6. Make It Simple

how to write a statement of work guide - make it simpleIt’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 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 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.

7. Share It

how to write a statement of work guide - share itAfter 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.

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.

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.


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.

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.

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.

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.

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!

Scope of Work Template

There are countless scope of work templates that you’ll find online for projects, but many of them are confusing and more than we’ll ever need for digital projects. They can actually be pretty confusing as you find yourself trying to fill in the blanks of an enormous project scope document that you simply don’t need.

You need to strike a balance of being just detailed enough; developing a scope of work that’s quick to produce, robust yet flexible, without creating something that’s so behemoth that it takes you two weeks to produce.

So if you need a statement of work template, or you’re looking for a scope of work template, we’ve got just the thing! This detailed Statement of Work (SoW) template provides you with an instantly downloadable, fully detailed, statement of work ready to use.

Statement Of Work Template Overview

It comes with two distinct parts; the first section outlines over-arching project information; the second part defines the detail of each phase and can be extended throughout the course of a project as each phase ends.

It’s written so that you can easily write a statement of work for your digital project. It helps answer the questions; ‘what should I include in my statement of work?’, ‘how much detail do I need?’ and ‘where do I put all the project information?’

Statement Of Work Template Detail

Instead of wasting time cobbling together something yourself, we’ve done the hard work for you with a fully-detailed statement of work template that’s around 12 x pages long / 1000 words. Save yourself hours of work and instantly download the template (supplied as a .doc) for you to adapt as you need. The template is unbranded and uses generic MS Word styling to make it easy for you to brand with your own logo and edit content.

Statement of Work (SoW) template

The statement of work template provides the following:

  • Contents
  • Project Information
  • Project Summary
  • Project Process
  • Project Budget
  • Project Milestones
  • Project Governance
  • Terms and Conditions
  • Phase Details
  • Deliverable Descriptions

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

Ben Aston

About Ben Aston

I’m Ben Aston, a digital project manager and VP of Client Services at FCV, a full service digital agency in Vancouver, Canada. I've been in the industry for more than 10 years working in the UK at London’s top digital agencies including Dare, Wunderman, Lowe and DDB. I’ve delivered everything from video virals to CMS’, flash games to banner ads 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:

Leave a Reply

Pin It on Pinterest