Statement of Work (SOW)

Overview.

Large and complex systems require that detailed work requirements need to be written containing "what is to be done" in definitive and precise language and terminology.
The purpose of a SOW is to detail the work requirements for projects and programs that have deliverables and/or services performed.
There are five types of SOW (one for each phase of the acquisition life cycle) during the system life cycle as identified by the Systems Engineering Management Plan (SEMP).
The SOW covers the work requirements and in conjunction with applicable performance/design requirements contained in specifications is used for contractual agreements.
Any proposed supplier can submit a proposal based on his perception of the needs as defined by the SOW. Thus enabling a fair price for goods and/or services to be provided.

The objective of this page is to provide information and insight for managers and engineers to provide a consistent, orderly, and complete description of work required.

NOTE: Most of this information is based on MIL-STD-245 and if cited shall take precedence, the use of this page is therefore only a guide-line in these cases and highly recommended for use in defining what program plans need to be implemented.

 Additional SOW preparation guidance see WISE

Purpose.

Most contracts for large and complex systems will require a SOW which will form the basis for successful performance by the contractor or developer.
A well-written SOW will allow more opportunity for potential offerers to compete for contracts and serves as the standard for determining if the supplier meets the stated performance requirements.

General description.

A SOW should specify in clear, understandable terms the work to be done in developing or producing the goods to be delivered or services to be performed by a contractor.
A SOW defines (either directly or by reference to other documents) all non-specification requirements for contractor effort.
Qualitative and quantitative design and performance requirements shall be contained in specifications or standards. Such specifications are typically referenced in the SOW but the specific qualitative or quantitative technical requirements shall not be spelled out in the SOW.
For example; a SOW will task a contractor to establish, implement, and control specific speciality programs (via a SEMP), i.e., Maintainability, Reliability, Configuration Management, Software Development, etc.
Management requirements in terms of results needed rather than "how to manage" procedures for achieving those results.

When a SOW becomes contractual it shall be used as a standard for measuring contractor performance.

Format.

The documentation requirements for the SOW will be in accordance with the 'Documentation Standard' as identified in the PMS.
The standard layout for a SOW shall be as follows:

• 1. SCOPE
• 2. APPLICABLE DOCUMENTS
• 3. REQUIREMENTS
• 4. NOTES

Section 1

SCOPE

Briefly states what the SOW does and does not cover. The 'scope' paragraph shall define the breadth and limitations of the work to be done (not how to do it). The use of an introduction, background, or both is preferred.
Background information should be limited to only that information necessary to acquaint the proposer with the basic acquisition requirement.
The following shall not be included in the 'scope' section:

• Directions to the contractor to perform work tasks
• Specifications of data requirements
• Description of deliverable products

Section 2.

APPLICABLE DOCUMENTS

Section 2 shall contain a list of all documents identified in Section 3 and as containing requirements.
This section will be initially left blank and only updated when a document (specification or standard) has been justified for inclusion. Only documents invoked by specific reference in Section 3 must be identified and listed. When invoked the application shall be tailored to meet the minimal needs. Reference to guidance documentation should be avoided.

Improper document referencing has been one of the major factors in costs since total compliance with a document listed in Section 2 is implied unless Section 3 states otherwise.

Section 3.

REQUIREMENTS

The specific work tasks shall be identified in Section 3. These tasks, developed to satisfy program/project needs, are essentially the work requirements for the contractor.
A well-written SOW shall:

1. Specify requirements clearly to permit the acquirer and offerer(s) to estimate the probable cost and the offerer(s) to determine the levels of expertise, manpower, and other resources needed to accomplish the task.
2. States specific duties of the contractor in such a way that the contractor knows what is required and completes all tasks to the satisfaction of the contract.
3. Written so specifically that there is no question of whether the contractor is obligated to perform specific tasks.
4. References only the minimal specifications and standards pertinent to the task. Selectively invokes documents only to the extent required to satisfy the existing requirements.
5. Cites only the minimal applicable specification and standards, in whole or in part, and is tailored or scoped downward to limit costs.
6. Separates general information from direction so that background information and suggested procedures are clearly distinguishable from contractor responsibilities.

A list of do's and don'ts follows:

Do:

• Outline the required work effort using a WBS program;
• Select a competent team, with a team leader who is experienced in systems acquisition and SOW development;
• Explicitly define the tailored limitations of the standards and specifications cited;
• Identify explicitly the data items required on the relevant paragraph of the SOW;
• Exclude design control or hardware performance parameters.
• Specify that a contractor format is acceptable for the data product when it meets the required need;
• Require only minimum essential data and use the least intrusive means to obtain it;
• Educate personnel with respect to documentation preparation and acquisition streamlining;
• Give priority to commercial items when it meets the requirements;
• Give priority to commercial practices as a means of acquisition.
• Take notice of definition of work words.

Don'ts

• Order, describe, or discuss data to be delivered;
• Invoke, cite, or discuss the format or content of deliverable data items. However, they may be cross-referenced in a SOW;
• Specify technical proposal criteria or evaluation factors;
• Establish a delivery schedule;
• Specify design control parameters or performance of hardware or software, except when a system/subsystem specification is not provided;
• Impose on the contractor an acquirer format when a contractor format is acceptable;
• Over specify. Specify what is required and let the contractor find out the best method to fulfil the requirement;
• Invoke in-house management instructions;
• Use the SOW to establish or amend a specification;
• Invoke handbooks, service regulations, technical orders, or any other document that has not been written in accordance with the 'Documentation Standards'.

For example model text see SOW model text

Back to Home page MANAGING STANDARDS Home page

Please send any beneficial comments or identification of errors using the following form to: mailto:%20kenr@wysywig.airtime.co.uk