wikiHow is a “wiki,” similar to Wikipedia, which means that many of our articles are co-written by multiple authors. To create this article, 11 people, some anonymous, worked to edit and improve it over time.
This article has been viewed 56,294 times.
Learn more...
A Statement of Work (SOW) is a document (and, usually, a legal contract) that formalizes the understanding between a contractor and a client. For each project, the SOW spells out the specific services to be delivered (usually, broken down into separate tasks to be accomplished), the time in which those tasks and services are to be performed, and the amount and due dates for payment. Its basic purpose is to serve as a roadmap to the project and to document the expectations of the parties. It should be a clear, plain-English description of “Why,” “Who,” “What,” “How,” “When,” “Where,” and “How Much?”
Steps
Following General Guidelines
-
1Write the SOW before beginning work. The SOW is usually created after the core contract negotiations are completed but before any work on a project begins. Sometimes, however (particularly with time-sensitive projects), negotiations may continue after the work has begun and the SOW is not finalized until the project is well underway.[1]
-
2Research the required SOW format. There is not a single standard SOW as different industries and projects have different deliverables and workflow. A good SOW is a customized SOW.Advertisement
-
3Get it right the first time. While the original SOW itself usually is not revised, a separate side agreement called a Change Order typically is used to modify the SOW’s terms. It is a good idea to include a blank Change Order form with the SOW. Keep in mind, Change Orders can increase the project’s cost. A well-written SOW can help to reduce the need for a Change Order. No client wants to be in a position where his or her specific expectations are left undocumented, which can lead to delays, an increase in total cost, or dissatisfaction.
Mastering Style and Specifics in SOWs
-
1Include the Objective. This section answers the question “Why?”[2] It is a high-level overview of the project and its objectives. General descriptions are acceptable when drafting this “bird’s-eye-view” of the project, but avoid language that could be interpreted in more than one way. Be clear; describe measurable and achievable objectives that realistically can be accomplished in the specified time frame.
-
2Include a discussion of the Scope. This section provides a definitive statement (no options or alternatives) of the “What?” and “How?” What is the work? How will it be accomplished? Or, often, what is NOT the work and what will NOT be accomplished. What are the assumptions? What deliverables (items the contractor presents to a client for review and approval) are being produced? What, aside from the deliverables, must happen administratively (project management) in terms of progress reporting, time tracking, and other communications.[3]
-
3Add Location, if possible. This optional section describes where the work will be performed (if relevant).
-
4Include a Time frame. This optional section specifies the total time allowed for project completion, the maximum billable hours per time period, and specific times for formal reviews or other project milestones.
-
5Set down the Schedule. This section states what tasks should be completed by what date/time, and who is responsible for making that happen. Descriptions of tasks and results (primarily deliverables) should be detailed, unambiguous, and straightforward so they are easy to understand. Aside from deliverables, the schedule might contain entries for Quality Assurance Testing, Consumer Testing, and Progress Reports.[4]
- While the schedule should be specific, don't focus on the “How” as that can put too many hurdles in front of successful project completion. A basic description of the required methodology to be used is sufficient.
- The Schedule often incorporates details of acceptance criteria (to measure the quality of the outcome) and payment milestones (usually upon acceptance of key deliverables), though these can be described in a different, separate section.
-
6Include a section on Acceptance. This section describes the mechanism for how the parties will determine whether the product or service is acceptable. The criteria can range from measurable quality standards to a specified number of tests, but in any case, must lend themselves to objective evaluation.
-
7Specify the Standards. This section describes any industry standards that must be met to fulfill the contract. Rather than physically reproducing the industry standards in the SOW, specifically referencing a set of standards is sufficient.[5]
-
8Include any Workforce Requirements. This section specifies any special workforce requirements, e.g., number of employees staffing the project, and education requirements (degrees or certifications).
-
9Note the Price. This section addresses the question of “How Much?” Is the payment a fixed fee? How do expenses/costs factor in? Will the payment be made as a lump sum or in installments? What is the payment schedule? Are there payment milestones?[6]
-
10Include any Assumptions. Most projects are permeated by various unknowns, for which the parties must make a variety of assumptions. In essence, assumptions are the conditions that the contractor expects will exist in order to complete the project in accordance with the terms of the SOW. For example, the contractor might assume that its employees will be granted access to the client’s computer network in order to install the deliverable software. The Assumptions section should identify as many such assumptions as possible and set forth a contingency plan or the consequences in the event that any assumptions fail.[7]
-
11Include parameters for Project Management. This section describes the process for monitoring the project’s progress. Include items such as Weekly Meetings, Regular Status Reports, Regular Progress Reports, and Project Management Team Meetings. This section also is a good place to describe any additional obligations which might flow from the project, such as maintenance and repair after the initial design and/or installation.
References
- ↑ https://thedigitalprojectmanager.com/how-write-statement-of-work-complete-guide/
- ↑ http://peopleprocessandprofit.com/2010/08/25/how-to-write-a-sow/
- ↑ https://thedigitalprojectmanager.com/how-write-statement-of-work-complete-guide/
- ↑ https://www.linkedin.com/pulse/how-write-statement-work-barry-goldberg/
- ↑ https://www.computerworld.com/article/2555324/how-to-write-a-statement-of-work.html
- ↑ https://www.computerworld.com/article/2555324/how-to-write-a-statement-of-work.html
- ↑ https://www.linkedin.com/pulse/how-write-statement-work-barry-goldberg/