Statement Of Work Ultimate Guide: Simple Definition & Template
Project managers would be lost without the statement of work. It’s the single source of truth that clarifies what you and your team are responsible for when delivering the project.
I’ll explain how to write an effective SoW, and I’ve provided my own simple SoW template and example so you’re set with everything you need to create your own statements of work.
Mục lục bài viết
In this article
What is a Statement of Work?
Let’s start with the basics: what is the definition of a statement of work?
In project management, a statement of work (SoW) is an agreement between a client and an agency, contractor, or service provider that defines what’s included within a project.
A well-written SoW clearly defines what your team will and won’t do on a project—saving you from painful client negotiations and protecting your timeline and the bottom line. It’s crucial to get your SoW right, as even a tiny mistake can have massive repercussions.
Here’s a very un-serious explantion:
What is Project Scope?
Project scope describes what’s being done, and critically, how much of it. Project scope is the extent, range, breadth, reach, confines—you name it—of the work to be performed.
To illustrate why scope is important, take the example of a website build. Suppose you agree with a client that you’ll create a new website for $100k. That’s great, but what exactly will the client get for their $100k? Is it simply 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 scope defines these questions and more to generate a shared understanding of a project.
Statement of Work vs Scope of Work
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 the work that the document codifies and defines.
While these terms are interchangeable, hereafter, for simplicity, we’ll use the term statement of work.
What Does A Statement of Work Document Do?
A SoW provides the extra layer of detail that cost estimates and project plans usually don’t include. It puts the meat on the bones of the project by describing exactly what’s being done and delivered. A well-written SoW may also specify what’s not included to help mitigate the risk of scope creep.
Putting together a SoW may sound like a lot of work. It is, but that’s not necessarily a bad thing. Putting a high level of effort into crafting a detailed SoW helps you refine your project approach.
You’ll probably end up adjusting your estimate and your timeline as you remember things that you should have added but neglected to incorporate.
Creating a detailed SoW also reassures the client about what will be delivered. For both the agency and the client, the SoW becomes the bible in determining what’s “in scope” and what’s “out of scope.” Ultimately, the SOW is the reference point for determining what’s included within the project cost.
In this way, putting in the work upfront to craft and agree upon a detailed SOW reduces your headaches later in the project lifecycle.
What Should a Statement of Work Contain?
The SoW is the project contract that sets and aligns expectations. It summarizes the purpose of the project and defines deliverables, standards, criteria, and requirements for each project phase.
If you’ve already created a project plan or timeline and a project estimate, then the SoW is the icing on the cake—it’s got the juicy details to tie everything together.
Statement of Work Components
So what should a SoW contain? What are the bits of a SoW that are important? What’s redundant?
At a minimum, the SoW should clearly detail:
- Project objectives: purpose statement, ie. why the project is happening and what it will achieve
- Project governance: who has approval to do what
- Work breakdown structure (WBS): how the project will be completed, what approach will be taken, and the specific tasks and phases that will be completed
- Deliverables, including due dates: what will be produced and by when
- Period of performance: when the project will be delivered, along with the amount of time needed, approximate start date and end date, and a list of milestones
- Estimate: project pricing, along with a payment schedule
- Assumptions: what is and isn’t included in the project scope, including acceptance criteria, i.e. what is and isn’t acceptable to deliver
- Work requirements: any other special requirements and specifics about how the project is to be completed, such as specific approaches or project management tools. For software development projects, include functional requirements.
Pitfalls in Creating a Statement of Work
While creating a SoW might sound reasonably simple, you’ll need to watch out for some common pitfalls:
- If the work statement is too vague, too broad, or too generic, it can leave room for multiple interpretations. This can create misunderstandings later in a project.
- If the SoW is too detailed, it can artificially constrain the project. You may end up doing work that’s not truly needed, simply because you said you would.
How to Write a Statement of Work
Keep these tips and tricks in mind when crafting a SoW:
My 7 tips for writing an iron-clad statement of work.
Join our Newsletter
- Your email
*
- By submitting this form you agree to receive regular emails filled with tips, expert insights, and more to build my PM practice. For further details, review our Privacy Policy.
-
- CAPTCHA
Δ
1. Break it Up
Don’t scope what you don’t know. Rather than trying to create a SoW for an entire project, split the project into phases, and develop separate SoWs 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 the project scope.
3. Put it into Context
Explain why you’re doing the project. Even if the specifics of the plan evolve, the SoW should help you to assess whether the project was a success.
4. Be Specific
Set the project’s boundaries. Minimize the risk of misinterpretation from your client by defining the extent of the work to do and quantifying it wherever possible so the client doesn’t expect more than you’ve budgeted.
5. Make Assumptions
Lay the ground rules. Use project scope statements to explain mutual expectations and what has to hold true for your team to properly execute the project.
6. Simplify
Be clear and concise. Strike a balance between making the SoW as lean as possible while also carefully specifying the work to be done. Avoid words with multiple interpretations, and use plain language to ensure the SoW is easy to understand.
7. Share
As the project manager, you should know your SoW inside and out and be able to communicate its contents to your stakeholders. Make sure stakeholders have seen a copy of the SoW, and continue to refer back to the SoW throughout the project lifecycle. More on this later on!
Statement of Work Template, Example, & Sample
Searching for SoW templates online yields countless results. The challenge is that many of these templates are confusing and contain much more than is typically needed for managing digital projects. The goal is to be able to produce a robust and flexible SoW quickly, with the appropriate level of detail.
Fortunately, we’ve got the template for you! Our digital project SoW template is fully detailed and ready to use. It helps answer the questions: “what should I include in my SoW?”, “how much detail do I need?”, and “where do I store project information?”
The DPM statement of work template.
Instead of wasting time cobbling together something yourself, we’ve done the hard work for you. Our detailed SoW template is approximately 12 pages long (1000 words) and is available in a format that’s compatible with Microsoft Word & Google Docs for you to adapt as you need. The template is unbranded and uses generic styling to make it easy for you to edit content and brand with your own logo.
The template includes two parts. The first section outlines overarching project information, while the second section defines the details of each phase. You can add subsequent phases if your project requires them.
The SoW template includes the following sections:
- Contents
- Project Information
- Project Summary
- Project Process
- Project Budget
- Project Milestones
- Project Governance
- Terms and Conditions
- Phase Details
- Deliverable Descriptions
You can find a pre-made statement of work template (plus a filled in example!) in the DPM Membership templates library. I’ve included prompts to help you fill out each section, and because SoW documents are such a massive undertaking, I’ve also put together a complete sample SoW for reference.
How To Use a Statement of Work
So you’ve finally got your SoW approved—now the real fun of keeping the project on track begins. If you don’t stick to the SoW, it’s highly likely you’ll end up not quite delivering on your project goals and also potentially being late and overrunning the budget. So how do you stick to the plan and keep your SoW on track?
Know it
Whether you wrote the SoW 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? Plus, it can be embarrassing if the client brings up something that you’ve written in the SoW that you’ve forgotten about.
Be sure to keep a copy of the SoW on hand. This may mean printing it out and making notes on it or uploading it in your project management software. Whatever you do, have the SoW available when you’re on a call or in a meeting because, whenever it’s in question, everyone will look to you for answers.
Being besties with your SoW means knowing its contents without having to refer to it. That level of ownership is going to inspire confidence in the team and the client and enable you to deliver a successful project.
Spread the Word
It’s not good enough for you alone to know the SoW—you need to evangelize the SoW with your team to guard against the risk of scope creep.
Even if your team was involved in architecting the SoW, it’s bound to have changed and evolved since project inception. Make sure team members understand project activities, deliverables, and assumptions, and that they are aware of what success looks like. Circulate the SoW, print copies for them, stick it on the walls of your war room, make it visible, and ensure everyone’s familiar.
If you fail to communicate the details of the project properly with your team, you might find them semi-innocently wandering off course. The last thing you want is for a team member to agree to an ad hoc client request that isn’t part of the execution plan or to overlook a key contract requirement.
Get Everyone on Board
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 SoW. If it’s good for the project, then you should be able to make a case to the client to change it. There’s never value in doing work simply because the SoW dictates it.
Keep Talking
Don’t be afraid of bringing up the SoW in your client meetings—in fact, review of the SoW should be a standing agenda item. Discuss if the SoW is still valid and whether things are going according to plan.
If there are things that need to be adjusted, then adjust them and make sure everyone is aware of the changes. At the same time, be careful not to succumb to every new request or pivot to every new idea. The SoW is there to set boundaries on your project scope.
Watch out for Scope Creep
Scope creep happens when the project scope begins to grow, seemingly sneakily. Typically, it’s when that feature starts off as one thing but slowly evolves or morphs into a much bigger feature that costs more to deliver than was initially planned.
In my experience, clients are full of good ideas but often don’t understand the schedule or budgetary 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 “favor”, which wasn’t budgeted for, like an additional format for a banner campaign.
(Watch out, too, for gold plating. This is when someone on your team wants to do an awesome job and so starts overdelivering and giving the client more than they paid for. Similarly to scope creep, this level of detail hasn’t been accounted for and thus puts the project over budget.)
How to Avoid Scope Creep
The first step is to name the problem—call out scope creep when you see it, as quickly as you can. To correctly identify scope creep, you must know your project scope well enough to understand what is not part of the SoW.
Be wary when a client uses phrases like these:
- Can we just..
- One little thing…
- Would you mind doing me a favor…
If they’re saying things like that, chances are they suspect it’s not included in the project scope. Refer back to the SoW 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?
If you and the client agree it’s more work, and the client still wants to do the work, you should issue a change request—basically, an update to the SoW. The change request should describe the change from the original SoW, explain how you’re going to execute the request, and highlight 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 early stages of the project, when project managers don’t want to rock the boat by raising issues when they should. The knock-on effects 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 SoW is flexible. They may assume that you’ll honor future requests for scope changes, regardless of their budgetary or timeline impacts. This puts your project at risk.
Other Documents Related to the Statement of Work
There are a few similar and related documents to SoWs that are often mistaken for SoWs, even though they serve different purposes.
Master Services Agreement vs Statement of Work
Whether you use a master services agreement (MSA) or SoW depends on what previous legal contractual agreements you have in place with the client. If this is the first project with a client, it’s likely that there needs to be an accompanying MSA in place that references your project SoW.
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 SoW.
The idea of an MSA is to agree on some basic terms so that any future transactions can be agreed upon 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 typically addresses topics such as:
- General services: the type 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 at which you’ll be paid, 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 reasons, and what the implications or costs are
- Representations: ensures you can do the work and that 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: the roles for project managers for the client and the agency
- Support & deployment: what assistance you’ll provide the client with implementation and what additional support, if any, you’ll provide in the future.
While an MSA is a governing document for the entire relationship, the SoW usually deals with the specifics of a single project. If you don’t have a MSA in place, you’ll want to include the kind of details outlined above in your SoW. If you do have an MSA in place, you can leave these details out of the SoW.
Project Charter vs Statement of Work
A project charter is a document that is closely related to the SoW but focuses on the bigger picture. Instead of going into detail about each task and deliverable, it covers project objectives and expected outcomes.
Use this document for larger projects with more phases, where losing track of the SoW between phases is more likely. The project charter is intended for use at the beginning of projects after both parties have signed off on the SoW.
Request for Proposal vs Statement of Work
Requests for proposals (RFPs) are documents created by companies or organizations when they wish to find an agency, vendor, or contractor for a particular service.
Different industries have slightly different ways of creating RFPs, but most will at minimum outline a scope of work, functional or technical requirements, and project timeline and/or deadlines.
Agencies interested in completing the scope of work set out in the RFP respond to these with a proposal, usually outlining their approach to the work, their methodologies, and some examples of similar projects that they’ve completed. The SoW follows after the agency has been awarded the project and contains more details regarding execution.
Frequently Asked Questions about Statements of Work
In case you still have questions, we’ve compiled responses to some frequently asked questions regarding project SoWs.
Is a Statement of Work Necessary?
Yes. 1000% yes. 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 not to 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 necessary—you may think that the days of producing a SoW are over.
Nice try, but no.
As a project manager, it’s in your best interests to have something that enables you to say, “but this is what we agreed” when you’re debating with a client about whether the estimate for a banner ad campaign also includes a campaign landing page.
The failure to write (or properly write) a statement of work is often the reason clients and agencies end up in conflict. When there’s uncertainty or ambiguity, it creates tension. The idea of a SoW is not to catch a client out, but to state exactly what’s being done, how, when, and the cost to ensure a common understanding of project requirements.
Are Statements of Work Important for Internal Projects?
Don’t discount the value of a statement of work for internal projects to set expectations for your team and outline the tasks and project deliverables they’ll need to complete. The document doesn’t need to be a formal SoW, like the one you might create for a client, but having some type of SoW in place is beneficial.
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. A less detailed SoW may offer flexibility to maneuver and pivot, but it also creates an opportunity for a client to try their luck in getting extra things included within the project scope.
Conversely, if you include too much detail in the SoW, you’re stuck with an inflexible process and deliverables that might not be adding value. We rarely know exactly how a project is going to last at project outset, so overly defining requirements makes it difficult to pivot the project when necessary. It also takes longer to write and approve an overly detailed SoW.
So how detailed do you need to go?
If you think that there could be any doubt or disagreement about anything in your SoW, you probably need to clarify further. When projects go bad, the first place that the client will reference is the SoW, so if it’s not specific enough, add in the details.
When is the Best Time to Create a Statement of Work?
Producing a SoW 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, you also don’t want to start writing a SoW when the client has approved your estimate and is itching for you to get started on the work.
In our guide on estimating projects, we talk about three phases of estimation:
- ballpark
- budget
- SoW estimation
It’s a good idea to start making notes for your SoW in the ballpark estimation phase. Begin documenting your SoW as you’re creating the budget estimate so that, by the time you’re creating the final SoW estimate, you’ve got the information you need to send the SoW to the client for approval.
Who Writes the Statement of Work?
Ultimately, it’s a good idea to have the project manager and the client contribute to the SoW to ensure both parties are aligned on expectations.
Before sending to the client, the project manager should review internally with several key stakeholders, including:
- The project delivery team: they should review what we are proposing to ensure that the scope and timeline is reasonable
- Procurement (if applicable): they should review the language to make sure we are negotiating appropriately with the client
- Legal: the legal team should have eyes on anything that is not part of a standardized company SoW.
What’s Not Included in the Statement of Work?
SoWs are a critical part of project planning. Although they may be updated throughout the project lifecycle to reflect changing requirements, they are not the focus of project execution. As such, project SoWs typically do not contain:
What’s Next?
If you’re looking for even more information on writing statements of work and other documents and processes that project managers use every day, subscribe to The Digital Project Manager newsletter.
