Statement of Work Format. (SOW)

Documents are now available in .pdf format: See PDFDOCUMENTS.



Include here a statement about what this SOW covers. If applicable, provide some background information that will be helpful to clarify the needs of the procurement.

1.1 Background Do not discuss any work tasks in section 1


List here all documents invoked in the requirements section of the SOW by document identifier and title. These documents may include Standards, Specifications and other referenced documents needed to identify and clarify the work task or deliverable product.
Any document listed in the section must be invoked and tailored to meet the minimal needs of the planned procurement in the requirements section.


  1. Detail the require tasks.

The following provides an engineering example:


This statement of Work (SOW) defines the effort required for the design, engineering development, fabrication, and test of a prototype of the project name System for the Demonstration and Validation Phase. It includes the associated program management, human engineering, and logistic support planning requirements.


2.1 Specifications.

2.2 Standards.

2.3 Other documents.

2.4 Industry/institutional documents.

2.5 Availability of documents.


The arrangement of technical tasks and subtasks within the requirements section will be dictated by program (project) requirements. If a Work Breakdown Structure (WBS) is being used in the project, tasks must be organized in accordance with the WBS. Ensure that only minimal needs are tasked for the SOW or requirements.

The order of technical tasks and subtasks within this section will be determined by the program requirements. If a WBS is being used in the program, tasks should be arranged in accordance with that WBS.
Ensure that the scope of the program tasks meet only the minimal needs for the phase SOW or requirements.

3.1 General.

The developer shall design and develop a system that shall meet the requirements of the Performance Specification, in accordance with (IAW) the system engineering tasks described in section 3.1. and program management and control tasks described in section 3.3.

The configuration and status of the design and contract shall be presented to the acquirer in two ways:

3.2 Detail tasks.

3.2.1 Systems engineering.

The developer shall implement a systems engineering management process in accordance with a 'Systems Engineering Management Plan' (SEMP) prepared to the instructions as described in MIL-STD-499B or an identified equivalent. The SEMP will define the necessary tasks and activities to be performed and shall include requirements analysis, functional analysis and allocation, and synthesis for the design of the system. The developer's system engineering process shall transform the requirements stipulated in the performance specification into a life cycle balanced set of products and process descriptions addressing the systems design, development, fabrication, test and evaluation, operational deployment, logistical support, personnel training, and final disposal. Where practical, system end-item requirements shall be met through the use of non-development items, when such products meet project needs, meet mission operational and environmental requirements, and are cost effective over the entire cycle of the project. The developer shall generate and maintain a requirements verification and decision matrix to provide an audit trail from requirements of the System Performance Specification to design implementation and verification, including key decisions to meet the requirements.

3.2.2 Systems analysis and control.

The developer shall identify and conduct trade studies, trade-off analyses, and cost-effectiveness analyses to ensure that a thorough and comprehensive set of options and alternatives is considered and analyzed for design, with consideration for all aspects of the system life cycle and all aspects of system life cycle cost. The level of detail of each study or analysis shall be commensurate with the cost, schedule, performance, and risk impacts.

3.2.3 Baseline generation.

The developer shall generate the system functional baseline(s) and each allocated and product baseline for the configuration items. The developer shall identify commercial-off-the-shelf (COTS) and non-developmental items (NDI), critical or long-lead items, and any acquirer provided items that are proposed as part of the design baselines.

3.2.4 Software design.

Software development shall be an integrated part of the system engineering effort. The developer shall conduct software development IAW MIL-STD-498.

All software shall be managed IAW a 'Software Development Plan' prepared IAW the product description (DID).

3.2.5 Concept of operations.

The developer shall develop, update, and maintain a concept of operations for the system that describes how the system would be operated. The developer shall identify effects of the concept of operations on the performance of the system, and the cadre who will operate the system.

3.2.6 Integrated logistics support (ILS).

The developer shall establish and document an ILS program as an integral part of its system engineering efforts. The ILS program shall address the developers proposed approach for providing total life cycle support from initial prototype design through final system disposal. The ILS program shall include the following elements:

A CALS strategy shall be employed to enable the effective generation, exchange, management, and integration of digital technical information.

3.2.7 System safety.

The developer shall establish and maintain a system safety and environmental protection program and shall ensure that safety and environmental protection considerations are integral parts of the systems engineering efforts. The safety program shall address personnel and equipment concerns relative to the design, development, testing, use, maintenance, life cycle support and disposal of the system.

3.2.8 Design reviews.

The developer shall conduct design reviews, as defined in MIL-STD-1521B suitably modified to incorporate the requirements and products of MIL-STD-498, MIL-STD-499B, DEF STAN 05-57, etc. The developer shall commend specific streamlining of these design reviews to the acquirer.

See semp39.htm for more details System requirements review.

The purpose of the SRR is to ensure that the system requirements have been completely and properly identified, to ensure that there is a mutual understanding between the developer and the acquirer regarding these requirements, and to review the system engineering process defined in the 'Systems Engineering Management Plan' that the developer shall use to develop the functional, allocated, and product baselines. At the SRR, the developer shall also describe how its technical concept is expected to meet these requirements, and shall identify the risks involved and how they will be managed. System design review

The purpose of the SDR System design review. Software specification review. Preliminary design review. Critical design review. Test readiness review. Functional configuration audit Physical configuration audit Formal qualification review Production readiness review

3.3 Program management.

The developer shall establish and maintain management operations IAW the following paragraphs. The use of Integrated Product and Process Development (IPPD) management approaches and the use of Integrated Product and Process Teams (IPPTs) is highly recommended.

The contractor shall establish and maintain a 'Project Management System' that shall include the following areas:

Program planning and control;

Supplier control;

Configuration Management

Financial management;

Data management;

Risk management;

And other management area(s).

3.3.1 3 monthly meetings.

The developer shall conduct 3 monthly meetings with the acquirer. These meetings shall be approximately to 5 working days after the acquirer recieves the developers update to the Program Electronic Database described in section 3.2.

The meeting will provide the developer and acquirer an oppertunity to discuss any questions or issues identified in the electronic database or any recent changes to the program or configuration. These should be held using video conferencing as often as possible.

3.3.2 Risk Assessment, mitigation, and management program.

The developer shall establish and implement a risk management program that identifies, evaluates, and mitigates program risks from a technical, cost, and schedule perspective

3.3.3 Life cycle cost (LCC) analysis, and control.

The developer shall establish and maintain current a system life cycle cost estimate. A baseline LCC estimate shall be developed by the developer in conjunction with the system's functional baseline at SDR.

Schedule development and control.

The developer shall establish and maintain current a Program Master Schedule and a detailed schedule for development of the system up to the establishment of the production baseline.

Performance management baseline management.

The developer shall implement cost/schedule control procedures IAW the cost/schedule status report.

3.4 Program electronic database.

The developer shall establish and maintain current electronic database that will document all aspects of the program, including the system design, the developers system engineering efforts, and the developers program management effort. The developer shall maintain this electronic database in an accurate and timely fashion, updating it with all pertinent changes on at least a monthly basis, preferably more frequently when warranted by significant changes and additions. Ideally, the electronic database would be accessible by the acquirer in real-time. The purpose of this database is to facilitate and streamline the transfer of information between the developer and acquirer, and is intended to replace extensive generation and delivery of costly and time consuming reports and other paper products for the acquirer. It is the acquirer intent that the databases used to satisfy this statement of work requirement be the same databases that are used by the developer as part of his normal internal, corporate way of doing business. For example, if the developer provides its engineers with particular computer-aided design tools to generate and document the system design (specifications, drawings, etc.), then it is the acquirers desire that the acquirer be given access to the same tool(s) to review and assess the design, as opposed to having the developer generate additional documentation or additional electronic tools to accomplish the same purpose.

TB Continued.

The contractor shall develop and implement a 'Project Management System' that clearly defines how the XYZ system is to be managed and controlled.
Add the relevant programs here.

NOTES: Tasks required depend on the phase, for example, the Engineering and Manufacturing phase will require the development of contract specifications, finalization of system specifications, implementation of Configuration Management and project (program plans), and the performance of cost, schedule, & performance trade-offs.

Specify explicit needs, leave nothing to the imagination.

For example SOW terminology


See Documents are now available in .pdf format: See PDFDOCUMENTS. For SOW/CDRL Preparation Procedures.

LE FastCounter

Back to Home page MANAGING STANDARDS Home page

Please send any beneficial comments or identification of errors using the following form to:

Copyright by Ken Rigby 1996, 1997, 1998 ---- 2004