By following the proper guidelines below and downloading andusing 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 bedeveloped as a table that includes regular review sessions and points of contact with clients.
Download Services Statement of WorkTemplate
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.
DownloadProject Management Statement of WorkTemplate
IT and Software Development
IT and software development often have more complex needs when it comes to writing anSOW. 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:
- Functional requirements: Technical details that dictate how the software, hardware, network, and/or system should function.
- Non-functional requirements: These focus on aspects such as security, maintenance, performance, and configuration.
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:
Download Software Development/IT Statement of WorkTemplate
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:
- Be detailed... Government SOWs must contain detailed selection criteria so that they can be used to compare different contractors who are bidding on the proposal. Make sure the criteria you use to compare them is relevant to the work itself.
- ...but not too detailed. However, don’t be unnecessarily descriptive, to the point where contractors have no ability to innovate and no flexibility in how they will go about the work.
- Think ahead to the contract stage. By clearly defining all requirements and expectations for contractors in the SOW—and making sure all parties understand them—you can help avoid future conflicts when it comes time to write the contact.
- Use generic language. Make sure you use non-proprietary, general language when writing your requirements. Your SOW needs to be understood by a wide variety of contractors who may choose to participate in the bidding process. This will also help you avoid claims of bias toward particular contractors.
- Speak in the present tense. Use thepresent tense when writing to help contractors more easily interpret the terminology and instructions in your SOW throughout the RFP and contract process.
- Use “shall” and “will” carefully. These words carry legal weight in the context of your SOW. “Shall” refers to a binding provision (e.g., “the Contractor shall build…”), while “will” refers to an action the client or buyer will have to take in the future (“the Buyer will pay the Contractor…”).
- Don’t take shortcuts. Public-sector employees may not have the proper training to write an SOW. Public-sector procurements may also occur on short notice and in high-pressure situations. If you’re struggling to write your SOW, or if you don’t feel you have time to do it accurately, find someone who has the proper training to help, or outsource the writing to a professional. If the Statement of Work isn’t completed accurately, or if important steps in the process are skipped, it may not be in compliance with government regulations. In turn, this can cause security risks, or expose one or both parties to potential legal issues.
Extra SOW sections. Government SOWs may have additional sections that aren’t found in SOWs for other industries. Some of these sections may include:
- Quality assurance and monitoring of work deliverables
- Government-furnished equipment and information, and applicable documents
- Estimated level of effort
- Non-personal services
- Access to government electronic mail
- Post-award administration
- Contracting officer's technical representative (COTR)
- Security considerations
- Transfer of hardware/software maintenance agreements to follow-on contractors
- Privacy act
- Task order closeout
- Past performance information
- Contractor's purchasing systems
- Federal Acquisition Regulation (FAR) solicitation provisions and contractclauses
Download Government Statement of Work Template
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.
