In contracting and procurement, a statement of work (often called an SOW or SoW) is a document that fully outlines a work agreement between two or more parties.
Typically, the statement of work serves as the heart of a contract, including all of the work requirements, acceptance criteria, payment terms, and metrics or milestones used to measure success.
In this article, we’ll cover all the basics of an SOW, where it should fit inside your contracting process, and what you need to know before you write one.
Let’s jump in.
Elements of a statement of work
While no statement of work document is exactly the same, most SOWs will cover similar content.
That’s because a statement of work is often the centerpiece of any contract. A standard SOW covers all of the basic elements of a valid contract in clear and certain terms.
Additionally, the statement of work outlines the goals, timelines, and criteria for the acceptance and closure of the project.
Here’s a closer look at what any basic standard of work should contain.
Project description and goals
Often (but not always!), an SOW will start with a description of the project and why an organization wants to commission the work.
This section may also include essential and high-level details about the project to ensure that stakeholders, team members, and contractors are on the same page regarding project objectives and goals.
However, you won’t typically see a list of detailed tasks or deliverables in this section.
Remember: The project description provides context and helps non-technical users better understand the purpose of the project and its intended outcomes.
Like an executive summary or a purpose statement, this section is strictly a high-level overview designed to illustrate the purpose of the project and expected outcomes.
This section should answer the following questions:
- What will this project achieve?
- Why is this project needed?
- Who is involved in the project?
- What relationship does this project have to company goals?
- What services are covered by this statement of work?
While you can sum this up inside a single heading, there are no hard and fast rules beyond keeping this section to a high level.
Especially for complex and highly detailed projects, you may want to break this section into multiple, smaller sections.
Regardless of how you choose to format this section, remember: The ultimate goal in this section is to avoid misinterpretations and ensure that everyone is aligned on objectives and project goals.
Acceptable standards and basic requirements
Depending on the nature of your business, you may need to include language regarding certain industry standards and regulations.
Note: In many SOWs, this language is optional. These specifications might also be covered in a master service agreement (MSA) or a similar governing contract.
If specific permits, licenses, or certifications are required, this section can include language that mandates compliance from service providers.
You might also include behavioral standards or set protocols in place if your contractors are working in your place of business or will be engaged in face-to-face conversations with potential customers.
Project deliverables are the end product that you expect the contractor or agency to complete and submit for acceptance or review.
Outlining these items in detail creates a clear end goal for your contractors. This section should specify in plain language exactly what you expect the contractor to deliver and should describe any requirements associated with it.
At the same time, deliverables should communicate acceptance criteria for project completion.
That might include due dates, baseline requirements, or even checklists of project minimums.
While deliverables should fit into the project scope, they are often broad out of necessity.
For example, if you were working with a software developer, the final deliverable might be an app or a piece of software with a specific set of functionality.
However, you probably wouldn’t specify that the final deliverable must contain a minimum of 20,000 lines of code.
When crafting your deliverable, keep in mind that the deliverable typically stands apart from any other work product created.
While you might require something like progress reports (proof of work) or some kind of work product that was generated over the course of executing the contract.
This type of documentation is typically delivered over the duration of the project and isn’t considered a part of the final deliverable.
Project tasks will address any special requirements or specific processes that must be completed as part of the scope of work.
Tasks might designate responsibility to specific teams, requiring that work be completed in a set amount of time, by a specific due date, or in a specific order.
If you’re working with an agency rather than a single contractor or service provider, you may withhold task assignments and allow teams to project manage themselves and handle their own work breakdown structure (sometimes referred to as WBS).
Often, if you’re working in tandem with contractors to complete a designated scope of work, it’s best to include agency tasks in your PM schedule and leave it to the agency to commit to the appropriate level of effort and expertise.
Phases, milestones and timelines
Depending on the scope and complexity of the project, you might consider breaking your SOW into project phases or milestones, each with its own unique timelines.
Larger projects can benefit from this level of management, and particularly complex projects may require that milestones be delivered in a certain order for the overall project to come together.
When writing SOW contracts, it’s important to remember that contractors often won’t have the full picture.
SOW documents might deliver the broad scope around a single project and assign specific tasks that are pertinent to the deliverable, but this still only provides a limited view into your organizational strategy.
Set your milestones and check-ins in a way that makes sense to both the project and the bigger strategy that you’re trying to execute. Both are important and, as the issuer, it will be up to you to see the full picture.
Costs and payouts
This section sets out the contract statement of work in plain terms.
Often, the costs and payouts schedule is set up as a table that clearly defines a list of pre-approved labor and expenses, often with language describing what actions need to be taken in the event that the project requires additional funding.
If you plan to fund projects on a milestone basis and continue to issue funds as the project progresses, it’s a good idea to define the circumstances in which budget overages are acceptable.
Why? Because only about 43% of companies mostly or always complete projects on budget.
More often than not, projects will run over budget either due to labor, cost of materials, or circumstances that were impossible to spot before the operation began.
Even with proper goal setting and task management, it’s best to go into a project with a plan to cover unanticipated overages.
Other things to include
Depending on your industry and the complexity of the role, there are several other things you may need to include in your statement of work.
Especially if you plan to issue a large number of tasks, taking the time to number those tasks in a clearly defined manner can help keep everyone on the same page.
It’s much easier to refer to a number than to search through a document for a specific task, which might have a name similar to an entirely separate task.
Definitions and acronyms
Every company uses acronyms differently. Getting this bit of company knowledge out of the way up front can avoid confusion somewhere down the line.
This is a good piece of information to put into an SOW template so that you know it’s always there.
Usage clauses for company assets
If your company needs to supply a workspace or any internal assets, like data or information, you may need to restrict that usage through your SOW.
If you plan to withhold those assets until the project reaches a certain stage, setting those guidelines will help to eliminate confusion.
Procedures for delayed decision-making
Some decisions can’t be made upfront. You may not know precisely how many times a task needs to be performed or how much of a product you need.
In situations where the operational landscape is changing, you’ll need to set up a procedure to clarify how and when that decision should be made.
Proof of acceptance
Anytime you’re planning to issue and agree upon a scope of work, it’s always best to capture proof that the work was agreed upon by both parties.
It’s easiest to do this using electronic signature tools that can verify signature authenticity and ensure that all documentation is legally binding.
Depending on your place in the organizational hierarchy, you might also need to include language regarding contract management, points of contact, and more.
Because an SOW can be part of a contract or set up as a standalone document, your exact setup will vary somewhat based on the situation.
Types of statements of work
So far, we’ve covered all of the basic details that are common in statements of work. Everything listed in the previous section is commonly included in every contract SOW.
But how you write your document comes down to which type of SOW you use. There are three basic types. We’ll cover each one in detail below.
1. Design/detail SOW
This type of SOW provides a detailed description of project goals, along with any tasks, to-dos, and requirements.
The defined work is clear and precise and is aimed at producing a very specific final product.
Statements of work that fall into this category are often the most specific.
Contractors are provided with a set of instructions, including what software to use, exact dimensions and final specifications, and clear start dates and end dates.
This leaves very little room for autonomy on the part of the contractor.
While it’s not precisely a “paint by numbers” contract, this type of SOW leaves most of the control in the hands of the issuing organization. All the contractor must do is follow the provided instructions.
2. Level of effort SOW
Also known as a time and materials or unit-based SOW, this SOW can come with variable costs based on effort or units required to complete a task.
Contractors typically work on an hourly basis and conform to a set of guidelines are expectations around a service performed.
If you require more of a particular service, the contractor simply works longer to fill that need. Additional units of effort (labor hours) generate additional costs.
In this scenario, the company still maintains a thorough level of control.
The statement of work is clearly outlined, and the contractor only needs to follow issued guidelines to perform the task as described.
3. Performance-based SOW
This type of SOW offers the greatest amount of flexibility for the contractor because it’s based on performance and output that is largely supplied by the contractor.
A performance-based SOW lays out (often in broad detail) what is required for the project to be completed.
The documentation might include details about a period of performance and the metrics that the company intends to use as part of its acceptance criteria.
However, most of the details regarding how to achieve that result are left to the contractor.
While the company still receives a high-quality product in the end, how the contractor chooses to accomplish that goal is out of the company’s hands beyond the initial guidelines that are set up in the SOW.
Writing a statement of work
Now that you understand what a statement of work document is supposed to do, let’s talk about what it takes to actually write one.
In this section, we’ll talk you through the basic steps to create a strong SOW using all the information we’ve covered so far.
While writing, be sure to take advantage of our downloadable statement of work example and use it to guide you through the process.
You can even customize it to suit your needs with the PandaDoc editor.
Define deliverables and success
Before you write anything, take a moment to define what success will look like for this project.
You can do that by answering some (or all) of the following questions:
- What deliverables should I expect from this SOW?
- What defines a successful deliverable?
- What are my deadlines for starting and ending this project?
- What is the ultimate goal of this project?
It’s easiest to write a statement of work if you work backward from the deliverable and fill in the gaps as you go along.
Before you start creating the details, get a clear understanding of how the deliverable will help your organization and where it fits into the scheme of things.
Once you have clarity around those details, creating the rest of the SOW will be much easier to handle.
Determine SOW type
We covered the three common types of SOWs in an earlier section.
Take some time to consider how much control you need to have over the project and which SOW configuration would be of the greatest benefit to you.
Ultimately, the SOW that you choose will determine the level of task and project management that you will be required to perform for the duration of the contract.
Once you have a good understanding of project deliverables and the type of SOW you want to create, it’s time to add specificity to the documentation.
Fill in all the essential elements and information, and clearly define the project vision. After that, you can start to drill down into key details.
Once you reach this stage of your statement of work documentation, you have enough to hand over the big ideas to contractors and let them figure out the smaller details and tasks.
Especially for a performance-based SOW, sending out a request for proposal (RFP) can allow contractors to explain how they would meet the requirements that you set in front of them.
Keep in mind that this strategy won’t be as useful if you have the in-house expertise to properly define your project or if you’re planning to provide exact specifications for contractors to follow.
Once you have all of the tasks and deliverables are written down, it’s time to clarify the cost of labor.
If you have a sole-source provider that you intend to use for this project, providing the SOW at this stage will give them the opportunity to negotiate costs and clarify additional details.
If you don’t have a contractor on standby, it’s probably time to open your SOW up to a bid.
This will give contractors a chance to review your documentation and provide estimated costs to complete the project.
Rework and revise
Use any feedback you get to review and update your SOW to better clarify your needs. If you have the opportunity to do so, seek an opinion from subject matter experts and revise your documentation based on that guidance.
Once you have all of the essential information finalized, your statement of work is essentially complete!
Create better statements of work with PandaDoc!
An SOW is an essential part of many business and government processes, but creating one can be a difficult and tedious process.
Many companies rely on a statement of work template and pre-written content to cover legal bases and expedite this process.
PandaDoc is an excellent solution if you’re looking to get the most out of your document workflow.
Our platform makes it easy to create, send, and sign documents in a way that keeps processes streamlined and parties engaged.
Sign up for a free 14-day trial and see how PandaDoc can level up your contracts, proposals, statements of work, and more.
Frequently asked questions
SOW is typically used as an abbreviation for statement of work, a contract document that defines the work requirements of a specific project. This term is widely understood in the fields of project management and contracting/procurement.
Yes! In many ways, a statement of work makes up the most essential part of the contract.
The SOW usually contains all the project details, clearly defines the work to be done, and covers payment and timelines associated with it.
Because these details often overlap with the requirements to create a legal and valid contract, the SOW is often included with any additional terms necessary for companies to work together.
Yes! Just like we mentioned above, many of the basic elements of a contract are included in a well-defined SOW. Along with a proof of acceptance, a SOW could be considered a standalone contract.
However, in practice, this isn’t usually the case. Most circumstances where a SOW is separate from a contract occur when the relationship between businesses is governed by a master service agreement (MSA).
With an MSA to govern the relationship, the SOW can be issued as a standalone document since the rest of the legal documentation is covered elsewhere.
A master service agreement (MSA) is a governing document that oversees the relationship between two or more organizations.
This document sets up the basic framework for the relationship and provides a set of rules and guidelines that govern any interaction between those organizations. This can govern anything from project timelines to dispute resolution.
A statement of work is project-specific, not relationship-specific. The terms and requirements of the SOW are directly related to a project and its associated deliverables.
If the company relationship is governed by an MSA, the requirements of the SOW would need to adhere to the rules of the MSA and the entire document would be considered subordinate to the MSA.
Generally speaking, the scope of work is outlined by and included within the statement of work documentation.
The scope of work covers the project description, along with its purpose and intended deliverables.
By contrast, the statement of work refers to the legal documentation itself, along with the detailed tasks that must be performed to fulfill the scope of the project.
During a proposal or bidding process, a statement of work can help contractors, vendors, and company partners better understand the requested work and project requirements.
These details will assist vendors in submitting quotes that are realistic and competitive so that your team can get an accurate assessment of labor and material costs.
Keep in mind that the specificity in your SOW will impact the quotes you receive. If you’re using a SOW with broadly defined goals and minimal essential tasks, contractors are likely to fill in the blanks with their own means and methods when responding with a solution.