NCSX Web Pages  

NCSX FTP Sites  

Navigation Trail  

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:

• Specifies requirements clearly to enable offerors to estimate probable cost and determine the levels of expertise, manpower, and resources required to accomplish the task;

• Specifies specific duties in such a way that the contractor knows what is required and can complete all tasks to the project's satisfaction;

• Written so specifically that there is no question whether the contractor is obligated to perform specific tasks;

• References only the minimum applicable specifications and standards needed to satisfy requirements;

• Separates general information from direction so that background information and suggested procedures are clearly distinguishable from contractor responsibilities.

• Avoids directing how tasks are to be performed and states only what results are required.

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:

• Standards for Contractor Quality Assurance program

• Right for inspection, surveillance, and audit by PPPL

• Contractor's responsibility for conformance

• Identification of non-conforming items and responsibility for taking corrective action

• General conduct of inspections and tests (information for each test or inspection is in specification)

• Identification and traceability requirements

• Calibration of test and measuring equipment

• Control of special processes

• Shipping release

• PPPL receiving and inspection

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.

• DO explicitly define the limitations of all specifications and standards cited.

• DO specify only what is required and let the contractor establish the best method to fulfill the requirement.

• DO exclude technical design and performance requirements which should be covered in a specification.

• DON'T specify proposal criteria or evaluation factors.

• DON'T establish a delivery schedule.

• DON'T use the SOW to establish or amend a specification.

Style Instructions.  SOWs should be prepared in the same style as other controlled documents.  

Style instructions for document preparation are provided here. 

A sample SOW is provided here.

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.

• NCSX guidelines provide a clear distinctions between what belongs in a spec and what belongs in a SOW.  There is overlap in the ENG-006 guidelines for specifications and SOWS  For instance,  ENG-006 guidelines for Section 4 - Test and Inspection Requirements are identical for specifications and SOWs.  Non-technical requirements such as QA Program requirements, documentation requirements, and deliverables are strictly in SOWs per the NCSX guidelines whereas they can appear in both documents in ENG-006.

• ENG-006 provides useful content guidance.  NCSX personnel are encouraged refer to ENG-006 in considering what requirements should be applied to the contractor effort.  However, NCSX format guidelines should be followed for determining whether those requirements belong in a specification or SOW.

Privacy and Security Notice

Please forward comments and questions to the Webmaster