A Statement of Work (SOW) is an important part of both project and contract management that helps guarantee that the work for a project will be done according to certain guidelines and expectations. Contractors or collaborators outside your organization will use the SOW to guide their work during a specific project. An effective SOW will include, among other things, work details, schedules, terms, and expected outcomes, so it’s imperative that it’s done correctly and doesn’t leave anything out. An SOW can be used for a wide variety of projects, ranging from a single visual design made by a graphic artist for a client, to a large-scale government building contract. In this article, you’ll learn how to overcome common challenges and create a solid SOW for any industry. You can also download the right SOW template for your projects in the sections below.
A Statement of Work is a document used in project and contract management. It covers the working agreement between two parties: the client, buyer, or government entity, and the agency, vendor, or contractor. An SOW typically includes:
An SOW is used when contractors or collaborators outside your organization are working on a project with your internal project team. It can also inform vendors or contractors who are bidding on your project. An SOW is often used in conjunction with other related documents, including:
Since a well-written SOW outlines tasks and deliverables of a vendor or contractor, it can provide a good foundation for writing a RFP or MSA down the road. However, the SOW should only be written after terms and guidelines have been decided upon, and should adhere to the correct format and use clear language detailing specific tasks, deliverables, and/or services the contractor is responsible for. This will help avoid conflicts when negotiating the contract.
Statements of Work are typically used when the work can be described according to specific directions or instructions, and when the requirements, tasks, and conditions are easily understood by both parties. An effective SOW should also provide information on performance outcomes as well as standards and metrics. Both parties should understand what a “successful” project looks like and how it will be approved.
There are certain project documents you may encounter that are similar to an SOW, but are distinct in several ways. The document types listed below focus primarily on big-picture issues, such as the project goals and the desired end results. For example, a Project Charter is meant to accompany, rather than replace, a Statement of Work. However, the latter of the two documents may be used in place of an SOW in government contracts.
Related documents include:
In brief, the main difference is that the SOW provides clear, specific direction for how the work should be done on a project, while the SOO and the PWS simply describe the desired outcomes. The Project Charter is also high-level, but incorporates goals and expectations in addition to outcomes. Many government entities prefer using an SOO or a PWS, because these documents allow more flexibility in how contractors approach a project.
An SOW, on the other hand, should be used when the nature of the work is already known and can be described in detail. It may also be used when the government agency or organization procuring the work has specific instructions or guidelines for contractors or suppliers to follow.
So what’s the difference between the statement of work and the scope of work? The scope of work is just one section of the statement of work. While the SOW is a comprehensive document that details the project’s goals, guidelines, deliverables, schedule, costs and more, the scope section focuses on how those goals will be met.
There are clear benefits to outlining the project scope. “Having a solid understanding of the scope of the project helps all parties involved avoid scope creep,” says Lauren Schommer, Program Manager at mobile app platform App Press. Scope creep is when the scope of a project grows or changes in an uncontrolled and undefined way.
The scope section of the SOW describes project outcomes and the type of work that will be done to achieve them. For example, if the project was to build a software system, the scope would describe the hardware and software that will be part of that system. It would also give a high-level overview of the steps involved in building and implementing the system. (More on scope in the Statement of Work Format section below.)
According to project management experts and entities, most SOWs share some basic components, regardless of industry. We’ll discuss what needs to be included in each section in more detail below. Common elements of an SOW include:
There are three different categories of SOWs, some of which may be more popular than others in different industries. The main types are:
Design/Detail Statement of Work
This category of SOW tells the vendor, contractor or supplier exactly how to do the work and what processes to follow. It clearly defines the buyer, client or entity’s requirements, whether they be materials, measurements, quality control requirements, or something else. This type of SOW is often used in government contracts, where contractors are required to follow specific regulations, and is the preferred SOW for manufacturing or construction projects.
In this type of SOW, the buyer, client or entity assumes most of the risk, since the contractor is obligated to follow the standards laid out for them.
Level of Effort/Time and Materials/Unit Rate Statement of Work
This is a flexible SOW that is frequently used for hourly service workers. It is simply based on work hours and the material needed to perform the service. The SOW describes the service being performed over a given period of time in a general way. It is often used for temporary or contract workers, or for delivery order contracts.
Performance-Based Statement of Work
This is the preferred type of SOW by most government entities, and the standard SOW for most American and Canadian government procurements. It covers the purpose of the project, the resources and equipment that will be provided, and the quantifiable end results. However, it does not tell the contractor how to perform the work. This SOW offers the most flexibility in terms of how the contractor works, and focuses on outcomes over processes.
In this model, more accountability is placed on the contractor or supplier, since they are responsible for delivering results using whatever methods they think are most effective.
Regardless of your industry, you’ll want to make sure to include the following sections in your SOW. These sections are important because they capture all the information both parties will need to ensure work is done according to the agreed-upon specifications. The format for most statements of work includes the following components.
Introduction
The introduction is where you identify the type of work to be done, whether it’s performing a service or creating a product. This is also where you identify the two parties involved: the client, vendor, buyer or entity, and the contractor, supplier, provider or agency. The introduction also covers the type of formal agreement that the SOW will be used to create:
Objectives/Purpose
This section describes why the work is being done. It talks about the purpose and objectives of the project and why they are important. It may discuss specific benefits or improvements the project is expected to bring, or may simply be a high-level overview of project goals and objectives.
Scope of Work
The Scope of Work section outlines the work that needs to be done and the processes involved in completing the work. It covers the project outcome in terms of a service, product or time commitment, and clarifies an acceptable outcome. It may include a high-level bulleted list of the steps that need to be taken to complete the work. However, detailed task lists should go in the Requirements and Tasks section (see below).
As an example, the scope section for a software development project might include steps such as “develop application” and “test application,” while the requirements and tasks section would break down the actual tasks involved in these processes, such as “code design for first module of application”.
In some statements of work, hardware and software requirements are listed in the scope section. In others, they may be listed under requirements and tasks. If requirements are technical and specific, it may make more sense to break them off into a separate section.
Requirements and Tasks
The requirements and tasks section breaks down the scope into more granular tasks. This section also lists requirements that contractors or service providers must meet (for example, certain training, certifications or security clearances) or hardware and software that should be used.
For software development projects, include functional specifications, says David Attard, Co-Founder of work management platform BeeWits, “These specifications should line-item absolutely everything that the software will do, right down to what fields are going to be included in the contact form and where the contact form is being sent to,” says Attard.
Make sure to list all the important tasks that need to be done to complete the project in this section. You can break tasks out into lists for different phases. For example, create a list for the kickoff phase, a list for the design phase, and a list for the build phase, if it's a creative or software development project.
Note: Tasks are different than deliverables. A task is an action that must be undertaken, while a deliverable is the end project or final outcome of a task. For example, in a creative services SOW, a task might be “write a creative brief,” while the deliverable would be the creative brief itself. (See the “Deliverables” section below for more information.)
Period of Performance
The period of performance defines the time period during which work will be performed. It’s important to determine this up front, since time can be an important factor in the ultimate cost of a project. The period of performance may be measured in one of the following ways:
If needed, you can also include constraints on the amount of time contractors or vendors can spend on the work, such as a maximum number of billable hours per week or per month. If delays occur during the course of the project that may interfere with completing it on time, you may need to adjust your SOW—and project costs—accordingly.
Note: The period of performance is different than the deliverables schedule. The deliverables schedule lays out, in detail, when specific deliverables are due, whereas the period of performance is high-level, and only describes the duration of the contractor’s work.
Place of Performance
Place of performance describes the location where work on the project will be performed. If applicable, it also lists what facilities will be used. If any regular meetings will be held as part of this project, include where the parties will meet. Locations may include:
Whether work is performed on- or off-site may depend on your industry and the type of job. For example, a creative design project may be performed remotely, at the contractor’s home or office. However, a government building contract would have to be performed on-site, at the location of construction.
Resources and Testing
In the resources and testing section, make a list of the key personnel involved in the project, such as the project manager, team leaders, and any other key players on both the client’s and the contractor’s sides. Also include any equipment or other resources that will be used in the completion of the work, such as hardware and software.
Deliverables and Schedule/Timeline
In this section, list all the deliverables the vendor, supplier or contractor will deliver to the client, buyer or entity. Include specific descriptions of the deliverables, including quantity, size, color, number of pages or designs, and anything else that may apply. Remember, deliverables are not the same as tasks; these are the quantifiable products or services that are being supplied to the client from the contractor.
You should also include a detailed schedule of when each deliverable is to be completed, along with dates for any other significant project milestones, such as:
While deadlines and end dates for deliverables must be included, start dates may be optional, depending on your industry and project. For example, a start date might be important in a construction project, while stakeholders in a creative or software development project may only care about due dates.
Again, this schedule (or “timeline,” as it is often referred to in project management) is different than the period of performance, which only encompasses the time during which the contractor’s work is being performed.
Payment Terms and Schedule
In the payment terms and schedule section, you will outline pricing for the work to be performed, along with the terms and schedule on which payments will be made. Make sure to include the entire cost of the work, including labor and any outside expenses that will accrue during the course of the project.
There are two ways you can set up your payment terms:
For software development projects, there are two other types of payment models:
You may also want to include clauses that cover delays on both the client and the vendor side. This is especially important in SOWs for projects such as software development, where the full scope of the work is not known at the beginning of the project (see the Software Development section below for more details).
Miscellaneous/Special Requirements
In this section, outline anything that hasn’t already been covered in the SOW. Requirements that might be articulated in this section include:
Acceptance Criteria/Signatures
Finally, this section covers how the client, buyer or entity will accept the project deliverables. It might outline which staff members are authorized to accept it, and who will review and sign off on deliverables. You should provide guidance on how the work will be submitted, and include specific criteria for how to determine what is “acceptable” work.
“Agreeing upon the acceptance criteria before the project begins helps to avoid any miscommunication on either side when the project wraps,” says Lauren Schommer, Program Manager at mobile app platform App Press.
We’ll go into detail about how to write an SOW for your particular industry below. Before we do, we wanted to share some general tips and expert insights to follow, as well as challenges to look out for, when creating an SOW for any type of project.
General Guidelines for Writing an SOW
Here are some general guidelines to consider when writing an SOW:
“Brainstorming at a detailed level before writing an SOW allows you to get a better idea of choices you will need to make later on, or additional features that can be added without much extra work,” Papperello explains. “The client may have additional input after an SOW is written, or as a consultant you may want to exercise some creative freedom for things that are not mentioned in the SOW. This flexibility is important to ensure that both parties are happy with the finished product.”
Challenges of Writing a Statement of Work
There are a few common challenges you may face when writing an SOW. These include:
By following the proper guidelines below and downloading and using our industry-specific templates, you can mitigate risks and create a more effective SOW for your organization. In addition to our SOW templates, you’ll also find additional tips for writing an SOW tailored to a particular industry.
Services
Service work typically employs either a level of effort/time and materials/unit rate SOW, or a performance-based SOW. Independent contract workers and hourly workers are more likely to use the former, while an advertising or creative agency is more likely to use the latter. For creative services, such as graphic design or TV commercial production, an SOW typically includes tasks such as developing creative briefs and concepts that must be approved by the client. Statements of work for services often cover performance and design requirements, in addition to the work objectives, requirements, deliverables, schedule, and payment information. The schedule for this type of SOW may be developed as a table that includes regular review sessions and points of contact with clients.
Project Management
There are many similarities between SOWs for project management and those for software development. The main difference is the inclusion of more technical information in the software development space. Writing an SOW for project management can be quite different than an SOW for other work, where the details are fixed and well-known. Unlike an SOW for a government contract, where rules and guidelines must be followed to the letter, project management may have more leeway in terms of how the work gets done, so SOWs in this industry must allow for more flexibility.
“Writing an SOW for project management and/or software development requires you to think beyond fixed scope and fixed pricing,” says Jason Brewer, CEO of digital agency Brolik. “You must embrace the nature of the work, which is agile and always evolving. A successful SOW provides just the right amount of structure, while establishing clear mechanisms for handling the inevitable pivots that happen as a product or software is in development.”
Duncan adds that the SOW should also name the people who will be responsible for approving deliverables, scope changes, and corresponding schedule and budget adjustments, as well as who will handle support and maintenance.
Due to the flexible nature of project management, an SOW for this industry may include fewer sections and/or use broader language than an SOW for other industries.
IT and Software Development
IT and software development often have more complex needs when it comes to writing an SOW. The criteria for acceptance may involve specific, technical details, such as a quantifiable speed, response time, and/or ease of use, based on the client’s needs. The requirements for this type of work fall into two categories:
While an SOW for an enterprise IT system may involve more specific details, an SOW for software development more closely resembles one for project management. Here are some software development SOW guidelines worth following:
Allow for flexibility. Software development also operates under Agile. Work is done in iterations, or stages, that involve testing and review to see what works and what doesn’t. Unlike a building or a manufactured product, software can be easily changed - even after the final product is completed.
“Code is easy to change, so keeping details to a minimum in an SOW can be beneficial, since this encourages experimentation,” says BugReplay’s Papperello. “Finding the right balance of detail to include in a SOW is essential."
When companies are using an Agile approach for development, the scope of the work to be performed is not always known initially. The SOW must account for the fact that the software architecture will need to accommodate changes and additions in feature content down the road, advises Jon Quigley, Founder of product development consultancy Value Transformation LLC. What’s more, in projects where the scope changes throughout the lifecycle, the SOW may not always be updated accordingly.
Divide the work into iterative phases. A good approach to writing an SOW for an Agile project is to divide the tasks and deliverables into phases, where some phases are more clearly defined than others.
“If you expect the final product to be able to be predicted in its entirety in the SOW, then you are going to have some difficulty,” says Quigley. “Deliver the product iteratively, steadily increasing the total capabilities defined and test each instantiation of the software. Update the requirements and SOW as you go through these iterations.”
Similarly, Brewer recommends dividing the SOW into phases that start with clear, specific requirements, and become more flexible as the project progresses. “The first phase begins with a very defined list of assumptions and inclusions. The second phase is 100% Agile retainer, and is presented as an estimate (to be confirmed later). Then a third phase, if necessary, to help your client ballpark a monthly budget one to two years down the road,” Brewer says.
Duncan also recommends a phased approach. “Project phases should be short (to maintain interest), limited in scope (to facilitate focus), involve all participants (to build and sustain commitment), and have clear transition criteria and visible checkpoints (so everyone knows where they stand and the end remains in sight),” she says.
Hire a technical writer. While it may be easier for project managers in other industries to write an SOW without specific training, technical writing skills are vital when creating an SOW for software development, says App Press’ Schommer. Without this background, information about the software, the client’s functional and nonfunctional requirements, and the infrastructure may be expressed incorrectly.
“The best way to avoid any misunderstanding of technical requirements or acceptance criteria is to review any SOW with an engineer prior to submitting to the client for acceptance,” Schommer adds.
Assign work to the proper team members. According to Attard, it’s important to clearly define certain roles in an SOW for software development. For example, who is responsible for designs, who will provide content, and who will upload it to the app or website. It’s also important to establish a project owner on both the client and the vendor side, Attard says, since “having a single person to refer to will simplify matters greatly.”
Taking this a step further, Alan Robbins of Moose WorldWide Digital suggests creating a Responsibility Assignment Matrix (RAM). This is a table that maps out “all the stakeholder’s names, titles, phone numbers, and email addresses plus a description of what they are responsible for.” The RAM should clearly identify who is responsible for financial acceptance, change orders and technical services, he adds.
Here is a sample of the RAM Robbins uses, which you can fill in with your project information:
Government
Statements of work for government are possibly the most complex to write. There are often stringent rules and regulations that must be followed and acknowledged, with exact language that must be used. They are often accompanied by several other supporting documents.
Where the SOW is found in a government contract
SOWs in this industry are usually part of the RFP or request for quotation (RFQ - a document that invites contractors to bid on a project), and are included as part of the final contract. In federal contracts, they’re typically included in the “Descriptions/Specifications” section (Section C) of the Uniform Contract Format. In task orders, the SOW may be included as part of the order’s terms and conditions. (Task orders are contracts where the buyer doesn’t know exactly what quantity of goods or services they’ll need to order, and/or doesn’t know exactly when they’ll need them.)
While your government SOW should be as detailed as possible, make sure it doesn’t repeat any terms and conditions listed in other parts of the contract. If you need to include more detail than your SOW will allow, you can attach supplemental documents and reference materials.
SOW and Work Breakdown Structure (WBS)
A WBS breaks down the scope of work for a project into sections that are more manageable, to help the team stay on track and better achieve their goals. While the WBS outlines the hierarchy of work items, the SOW describes how that work should be done. If you have a WBS, use this as the outline for your SOW. Make sure to copy each element of the WBS into your SOW. This will make writing, tracking, and billing easier.
SOW and contract data requirements list (CDRL)
The CDRL is a list of data product deliverables that a contractor must deliver for a government procurement. It also outlines the requirements, such as what format the data products should be in and how they should be delivered. The CDRL entries must reference the parts of the SOW that use these deliverables. In turn, the SOW should reference the titles and item numbers of corresponding CDRL entries.
Here are some guidelines to follow when writing an SOW for a government contract:
Extra SOW sections. Government SOWs may have additional sections that aren’t found in SOWs for other industries. Some of these sections may include:
As we’ve learned, writing an SOW can be a complicated process. However, if you follow the guidelines and use the templates listed in this article, you can create an effictive, high-quality SOW.
Empower your people to go above and beyond with a flexible platform designed to match the needs of your team — and adapt as those needs change.
The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed.
When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.
