NCSX Web Pages
|Project | Management | Physics | Procurement | Manufacturing|
NCSX FTP Sites
|Project FTP Server | Supplier FTP Server|
|Engineering > SOW Guidelines|
Statements of Work (SOWs)
That portion of a contract which establishes and defines all non-specification requirements for contractor efforts either directly or with the use of specific cited documents.
Systems Engineering Guidebook, James N. Martin, CRC Press, pg. 211
In the DoD world, MIL-HKBK-245D is (or was) the handbook for preparation of statements of work. NCSX guidelines are borrowed from MIL-HDNK-245D with tailoring to our specific project needs.
Purpose. The SOW should define 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. Preparation of an effective SOW requires both an understanding of the goods or services that are needed to satisfy a particular requirement and an ability to define what is required in specific, performance-based, quantitative terms. A SOW prepared in explicit terms will enable offerors to clearly understand the project's needs. This facilitates the preparation of responsive proposals and delivery of goods or services.
Relationship between SOW and Specifications. The SOW defines (either directly or by reference to other documents) all work (non-specification) performance requirements for contractor effort. Technical design and performance requirements are contained in specifications. Such specifications are typically referenced in the SOW, but specific technical requirements should not be spelled out in the SOW. Together, the specification and SOW provide what a contractor needs to know in order to prepare a proposal or bid in response to a Request for Proposals (RFP). The contract references and supplements the specification and statement of work.
SOW and Contractor Performance. After contractor selection and contract award, the contract SOW becomes a standard for measuring contractor performance. Consequently, the SOW writer must consider the contractual and legal implications of the SOW during its preparation. The SOW must clearly define the work to be performed, since the language detailing the contractor's effort may be pertinent to legal questions concerning the scope of work. Clearly defined requirements will enhance the enforceability of a SOW as well as guard against misinterpretation.
Standard Format. The standard format for the SOW is as follows:
1 - Scope
2 - Applicable Documents
3 - Requirements
4 - Quality Assurance
5 - Deliverables
The first three sections follow the format prescribed in MIL-HDBK-245D. The fourth section on Quality Assurance was added to establish quality assurance (QA) program requirements that offerors need to know to prepare a proposal. These QA program requirements would be inappropriate for a technical specification and so, are included in the SOW. The fifth section on deliverables was added so that a complete and unambiguous list of deliverables would be identified to the offerors. Delivery dates should be defined in the contract, not the SOW.
Section 1 - Scope. This section includes a brief statement of what the SOW should cover. The scope paragraph defines the breadth and limitations of the work to be performed. Background information should be covered in an introduction and should be limited only that information needed to acquaint the proposer with the basic acquisition requirement. The following should NOT be included in the Scope section: [a] directions to the contractor to perform work tasks; [b] specification of data requirements; and [c] description of deliverable products.
Section 2 - Applicable Documents. Sections 2 and 3 are reciprocal. All and only the documents invoked by reference in Section 3 should be listed in Section 2. When invoked in Section 3, the application should be tailored to invoke only the minimum requirements from the document which are needed by the project. The applicability of each document listed in Section 2 should be specified in Section 3 and identify only that portion needed to perform the work. Improper document referencing (e.g., blanket imposition) has often been a major cost driver since total compliance with a document listed in Section 2 is implied unless Section 3 specifies otherwise.
Section 3 - Requirements. Specific work tasks are called for in Section 3. A well-written SOW has the following attributes:
Section 4 - Quality Assurance. This section establishes quality assurance program requirements. Quality assurance requirements for products are not specified in Section 4 but rather in specifications and implementing manufacturing plans and procedures. Quality assurance program requirements might include the following:
Section 5 - Deliverables. This section was added so that a complete and unambiguous list of deliverables would be identified to the offerors. Delivery dates should be defined in the contract, not the SOW. It is imperative that the list of deliverables identified in Section 5 be complete and consistent with the work requirements identified in Section 3. Deliverables might include documentation and progress reports in addition to goods and services.
SOW Do's and Dont's.
Style Instructions. SOWs should be prepared in the same style as other controlled documents.
NCSX v. PPPL SOW Guidelines. PPPL has a procedure for preparation, review, and approval of specifications and statements of work (ENG-006). Differences are summarized below.
Please forward comments and questions to the Webmaster