International Defense Security & Technology Your trusted Source for News, Research and Analysis
Related Articles
Developing a needs or requirements document can be a very complex and challenging task. Requirements documents include statements of work, standards, specifications, and other documents mandated for use by law.
The primary function of the SOW is to specify the deliverable or deliverables that a vendor or internal department is responsible for. The statement of work (SOW) is a legally binding document that captures and defines all the work management aspects of your project. You’ll note the activities, deliverables and timetable for the project. It’s an extremely detailed work contract that defines the terms and conditions agreed upon between parties and lays the groundwork for the project plan.
The statement of work is a detailed overview of the project scope. It’s also a way to share the project requirements, acceptance criteria, and payment terms with those who are working on the project, whether they are collaborating or are contracted to work on the project. This includes stakeholders like vendors and contractors who are bidding to work on the project.
Types of SOW
Requirements documents can be written in different ways, generally following one of three basic approaches to describe the essential characteristics of the product or service needed. They include:
- Design oriented. Design oriented documents tell the contractor how to do the work. It may include precise measurements, tolerances, materials, in-process and finished product tests, quality control, inspection requirements, and other Government requirements that control the processes of the contractor. The point is that the Government, to a large degree, requires the contractor to follow the Government’s way of performing the task or making a product. This causes the risk of performance to be borne by the Government. For instance, if the contractor builds and/or performs a task and follows the Government’s SOW exactly, and the product or service is faulty, who is to blame? Absent malfeasance or shoddy workmanship it is the Government’s process that the contractor was implementing so the contractor cannot be faulted. Although this type of SOW is primarily used for manufacturing or construction, other work efforts may be described in this rigid format.
Example: If an agency requires a water purification system, a design document would include blueprints for the components of the system and may even include the type of materials to use when building the components.
- Performance-oriented. Performance oriented documents set forth operational characteristics. Design, measurements, and other specific details are not stated or considered important as long as the performance requirement is met. When an item is purchased under a performance requirement, the contractor accepts general responsibility for design, engineering, and achievement of the statement performance requirements.
Example: For a water purification system, a performance document might establish the level of purity, the power consumption, the throughput, etc. that the system must achieve.
- Functional. Functional requirements describe the work to be performed in terms of end purpose or the Government’s ultimate objective, rather than the way in which the work is to be performed. Functional requirements may be thought of as a type of performance-oriented document.
Example: For a water purification system, a functional requirement would only state the need to purify water without establishing a method or other benchmarks.
Performance-based statements of work are the preferred method of stating needs. Keep in mind that few requirements documents are purely performance-oriented or purely design or functional based. A performance based statement of work structures all aspects of an acquisition around the purpose of the work to be performed and does not dictate how the work is to be accomplished. It is written to ensure that contractors are given the freedom to determine how to meet the Government’s performance objectives and provides for payment only when the results meet or exceed these objectives. It maximizes contractor control of work processes and allows for innovation in approaching various work requirements. By focusing on required outcomes or results and not methods of performance or processes, the Government’s risk is reduced.
A well-written SOW enhances the opportunity for all potential offerors to compete equally for Government contracts and serves as the standard for determining if the contractor meets the stated performance requirements. A performance work statement (PWS) is a statement of work for performance-based acquisitions that describes the required results in clear, specific and objective terms with measurable outcomes.
NASA GUIDELINES FOR VARIOUS TYPES OF PERFORMANCE WORK STATEMENTS
- ROUTINE SERVICES AND NON-ROUTINE SERVICES
When contracting for services of a routine or non-routine nature, whether high or low “tech” (e.g., engineering, computer service, guard service or janitorial), it is essential to avoid under-specifying NASA’s requirements. Work inadvertently omitted may later be construed to be outside the requirements of the contract and could require a contract change and increased costs. Even worse, omissions outside the scope of the contract could require a significant effort from NASA such as a new competition or a Justification for Other Than Full and Open Competition (JOFOC).
The SOW for services is usually written to require output to ensure work is completed at an acceptable level. In that event, NASA may be obligated to accept whatever product or services the contractor provides, or make changes in the work requirements and pay more to acquire what is actually needed.
- INDEFINITE DELIVERY INDEFINITE QUANTITY TYPE CONTRACTS
SOWs for Indefinite Delivery Indefinite Quantity (IDIQ) acquisitions are written somewhat differently but still have a performance based flavor about them. Services or products are acquired via individual orders issued by the Contracting Officer. The SOWs are usually very broad and describe the general nature, scope of complexity of the services or products and the individual order will then further define the specific need, still in a performance based manner. It is important that the SOW be broad enough to assure all potential work items that might be issued through a task are sufficiently covered. If the task’s activity is outside of the SOW scope then it cannot be performed under this contract. At the same time, the SOW must be detailed enough that the offeror knows what skill mix to propose along with the magnitude of the labor force and any other direct costs that might be required to support subsequent tasks.
- HARDWARE OR END ITEM DELIVERABLES
The SOW describes, at the highest practicable level, what the end product must do (performance) and any critical constraints (e.g., size, weight). It eliminates process-oriented (how to) requirements and includes only minimally essential reporting requirements. Actual demonstrated performance of the end item is normally one of the measures – in some cases the only measure.
- MAJOR SYSTEMS CONTRACTS
Contracts for definition and development of major systems have short, concise outcome SOWs that do not necessarily go into great detail. There is usually a specification/contract deliverable requirements list associated with these contracts, which may contain specific requirements for the project(s). The SOW must, however, state all requirements necessary to complete each task element of the Work Breakdown Structure and be complete enough to allow the contractor to generate all information necessary to design, prototype, test, and verify.
A good approach for the acquisition of major systems is to acquire the effort in phases, with each phase having a limited but clear objective. This approach also is a safeguard against committing scarce resources to an effort prematurely.
For study and preliminary definition contracts, the SOW must allow the contractor wide latitude for creativity, innovation and research. Describe efforts necessary to supplement existing information and bring present knowledge to a point where further detailed study for the most promising systems can be made.
- RESEARCH & DEVELOPMENT (R&D) CONTRACTS
Most R&D contracts are directed toward specified objectives and knowledge where the work or methods cannot be precisely described in advance. It is difficult to judge the probabilities of ultimate success or required effort for technical approaches. R&D SOWs can be difficult to write if the contract’s objectives are not defined sufficiently, yet they must be flexible enough to allow contractors freedom to exercise innovation and creativity. The most important element is to clearly define the requirements and/or the schedule such that the performance of the contractor is measureable.
- BASIC RESEARCH
In basic research, results cannot be determined in advance and often no deliverable is required except for a final report. In that case, the performance standards may be focused on timeliness, organization and thoroughness of the report, comprehensive bibliography, etc. These performance standards shall be used to “gate” contractor eligibility for fee, if any.
When the principle purpose of the research is for the direct benefit or use of NASA, a contract shall be used. When not a direct benefit or use to NASA, the proper procurement vehicle is usually a grant or cooperative agreement.
NASA PROJECT LIFE CYCLE
NASA’s project life cycle is divided into two phases—Formulation and Implementation—that are further
divided into Phases A through F. The project life cycle also consists of numerous activities, including Key
Decision Points (KDP) determine the readiness of a project to progress to the next phase of the life
cycle.
During the Formulation Phase project personnel conduct a PDR to (1) evaluate the completeness and
consistency of the planning, technical, cost, and schedule baselines developed during Formulation;
(2) assess compliance of the preliminary design with applicable requirements; and (3) determine if the
project is sufficiently mature to begin the Implementation Phase.
The ML-2 project deviated from the traditional project life-cycle process by splitting the PDR into two phases: programmatic and technical. A project is approved for implementation at KDP-C, which occurs between Phases B and C. As part of the KDP-C review process, cost and schedule baselines are established against which the project is
thereafter measured. To establish these baselines, NASA policy requires projects to produce a joint cost
and schedule confidence level (JCL).
This analysis measures the likelihood of completing all remaining work at or below the budgeted levels and on or before the planned completion of Phase D. A new JCL is required during the Implementation Phase if a project is rebaselined or upon request from the Decision Authority.
NASA Statement of Work
The statement of work is structured by the NASA project life-cycle phases as outlined in NHB 7120.5 for NASA Space Flight Programs:
Formulation
Pre-Phase A Concept Studies
Phase A Concept and Technology Development
Phase B Preliminary Design and Technology Completion
Implementation
Phase C Final Design and Fabrication
Phase D System Assembly, Integration & Test, and Launch
Phase E Operations and Sustainment
Phase F Closeout
CONCEPT STUDIES
The Government shall nominally provide initial system level concept(s) for the Mission Concept Review (MCR) to meet the requirements as defined by the researcher and/or technologist (RlT), identify any engineering feasibility issues and perform key tests that demonstrate the proposed engineering/science requirements can be satisfied. The Government will support the RlT’s identification and refinement of the engineering/science requirements by designing and developing bench-top hardware (breadboards) and rigs for laboratory and/or low-gravity ground-based testing
The system design and mission analysis are conducted to produce feasible concept(s) that address the requirements and to evaluate potential mission carrier options. The concepts identify possible subsystems that address the project objectives and the key high-risk development areas. The mission analysis may include: technology alternatives, operations scenarios, risks identification, and infrastructure evaluations.
CONCEPT AND TECHNOLOGY DEVELOPMENT
The contractor shall define the fundamental system requirements based on engineering, science, potential carrier, operations, and safety and quality requirements. The contractor shall determine the overall feasibility of the candidate project concept(s) that consider affordability, technology readiness, operations, infrastructure, content, risk, safety, reliability, and potential procurement strategies. The technology readiness assessment shall evaluate the fundamental technology requirements of the project concept to ensure that specified project objectives will be met, project cost or risk will be minimized and identifies where significant technology gaps exist, such that
it would be difficult for a concept to be realized.
The SRR examines the functional and performance requirements that are defined for the project
and ensures that requirements and the selected concept will meet the project objectives. The System Definition Review examines the proposed project formulation and the flow down of the functional elements of the system.
The contractor shall formulate an overall engineering plan that defines and details the approach, schedule, hardware classification, and resource requirements so that programmatic commitments can be made. The contractor shall also provide a life cycle costing analysis necessary to produce the selected concept. The schedule shall be detailed to the next review milestone and identify the critical path. Also, a requirement compliance matrix shall be required for the established baseline concept.
PRELIMINARY DESlGN & TECHNOLOGY COMPLETION
During this phase, the contractor shall develop a preliminary design and technology development that can demonstrate at the system, subsystem and component level compliance to the system and project requirements with acceptable risk.
The outcome of the Preliminary Design and Technology Completion phase is to establish, through independent engineering-review, that the proposed engineering design solution for the project is expected to meet the performance and functional requirements at the configuration item level, the design is verifiable and does not pose major problems which may cause schedule delays or cost overruns, all interfaces and verification methodologies have been identified, and all system requirements have been allocated to the subsystem and component level and the flow down is adequate to verify system performance.
The key activities during this phase shall consist of establishing the overall system architecture, identifying all the external interfaces, developing an operations concept, developing equipment layouts, developing requirements for flight and ground support hardware and software, producing preliminary drawings, software design, mass properties, interface schematics, and preliminary materials & parts lists.
The contractor shall perform engineering analyses (thermal, dynamic, vibration, optics, etc.) as appropriate in the design of the mechanical, electrical, and system hardware.The contractor shall also develop a software design and initial programming in parallel with the hardware design.
The contractor shall perform reliability and maintainability analysis where appropriate to assure that the project’s preliminary design will meet the mission requirements through reliable subsystems/components and/or through maintenance. Reliability analysis is based on sound methodology and presents realistic predictions for logistics planning and life cycle cost analysis.
Preliminary Design Review (PDR) and the Phase 0/1 Safety Review. The PDR demonstrates that the preliminary design meets all system requirements with acceptable risk and within cost and schedule constraints.
Software Requirements Document (Preliminary), per DID# R-04: Clearly define the hardware/software interfaces and identify software requirements.
Design-to Specifications (Preliminary), per DID# R-Ol: Document that incorporates the project requirements, vehicle and/or carrier requirements, and all interface requirements, including software interfaces.
Interface Control Document (Preliminary), per DID# R-02: Clearly identified interfaces with the vehicle, carrier, or other element based on the appropriate integration template.
Safety Hazard Reports
Software Management and Development Plan (Preliminary) : Provides the overall approach for development of the project software.
Risk Management Plan (DID# PM-02): The key risks shall be identified and approach to manage engineering and project risks.
Failure Modes and Effects Analysis (Preliminary): An analysis of the potential failure modes of the design to assure that the design is robust to meet the mission requirements.
Reliability Analysis (Preliminary), per PA-13: A preliminary analysis of the systems reliability shall be determined to show compliance to the system requirements.
FINAL DESIGN AND FABRICATION
During this phase, the contractor shall develop a final design that can demonstrate at the system, subsystem and component level compliance to the system, vehicle and/or carrier, product assurance, and project requirements, as well as other applicable requirements identified in the Delivery Order.
The contractor shall generate complete system build-to specifications and drawings that include hardware and software. Requirement traceability establishing the linkage of all derived requirements shall also be generated. The contractor shall perform, where required, system level analyses and trade studies to optimize the operating design conditions; support the development of the final design; demonstrate overall compliance with requirements; support the verification activities; establish system performance; evaluate thermal, environmental and structural behavior
(vibration, loads, etc.); determine reliability and maintainability; and support the integration of developed components.
The contractor shall develop a software design and code based on the hardware design and requirements that may also include simulator software, training software and ground support software, based on carrier requirements, hardware requirements, and NASA software development requirements.
The contractor shall develop a comprehensive verification program that includes plans and procedures to assure that the project hardware and associated software will meet all defined requirements. The Verification Plan(s) shall identify clearly where, how, and when each function and performance requirement is verified in the verification program before launch and, if applicable, how these requirements are again going to be verified on-orbit.
The contractor shall assure that all the chosen materials for the hardware design meet safety requirements for corrosion resistance, stress corrosion cracking susceptibility, out-gassing, flammability, fluid compatibility, and off-gassing in habitable areas.
The contractor shall perform an integrated safety analysis of the final design that shows that there are no outstanding hazards, which cannot be controlled or are within an acceptable risk level if waivers are required
The key reviews for the Final Design and Fabrication phase are the Critical Design Review (CDR), Systems Integration Review (SIR) and the Phase 2 Safety Review. The CDR demonstrates that the maturity ofthe design is appropriate to support proceeding with full-scale fabrication, assembly, integration, and test.
The SIR ensures that the system is ready to be integrated. Segments, components, and subsystems are available and ready to be integrated into the system. Integration facilities, support personnel, and integration plans and procedures are ready for integration.
SYSTEM ASSEMBLY, INTEGRATION & TEST, LAUNCH
During this phase, the contractor shall complete the assembly, test, verification, and delivery of the required hardware, software, and associated integration documentation required for launch. The outcome of the System Assembly, Integration & Test, and Launch phase is to provide an operational system that satisfies the ultimate user.
The performance standard for successful completion of this work element occurs upon NASA approval at a Flight Readiness Review (FRR) and a System Acceptance Review (SAR) and/or Pre-Ship Review (PSR) with a Certification for Flight Readiness. Also, an Operational Readiness Review will be held to ensure the system is complete and ready for operations
OPERATIONS & SUSTAINMENT
During this phase, the contractor shall support on-orbit integration activities, hardware and software sustaining engineering, flight and data reduction, equipment real-time operations, and data reduction. The outcome of the Operations and Sustainment phase is to operate the project equipment in accordance with the goals and requirements of the project.
The contractor shall provide mission operations support including coordination of real-time project requirements with the PI, the vehicle and/or carrier, and other appropriate entities; acquire and process real-time data according to pre-determined requirements; support the correlation ofdata with mission events; provide appropriate personnel to support on-console mission operations and data analysis at the carrier’s control center; preparation of data products for data dissemination including general and specific mission summary reports; preparation of unique data analysis reports for the project; maintain engineering/scientific information databases; and participate in working group interchanges as defined in the Delivery Order.
Applicable documents
The nature of flight hardware development is such that conformance to various standards and codes shall (will) be specified if required. Those that are applicable will be specified in each Delivery Order. Typical standards and codes, which may be required of the contractor, are the following:
• American Society for Testing and Materials (ASTM International) Standards
• Military Specifications and Standards
• American National Standards Institute (ANSI) codes as sponsored by American Society Of Mechanical Engineers (ASME)
• Department of transportation Regulations
• NASA Standards and Handbooks
• AS9l00 Quality Management Systems – Aerospace – Requirements
PERFORMANCE WORK STATEMENTS
MANAGEMENT
The contractor shall provide a management function for the monitoring, control, and reporting of the specific Delivery Order effort. The contractor’s management function shall provide to NASA GRC a schedule, with the critical path clearly identified, out to the projected delivery date. The schedule shall be in accordance with the project Work Breakdown Structure (WBS) and reported to the 4th level WBS.
Cost Reporting! Earned Value Management
The contractor shall generate Contractor Financial Management Reports (DID# CD-Ol) for the contract. The contractor shall participate for each Delivery Order in a monthly progress review meeting with the identified NASA Project Manager (Delivery Order technical manager) to review their cost analysis, schedule technical status, issues, and technical interchange to assure understanding of all Delivery Order requirements. The contractor shall work with NASA to develop simplified methods to manage the delivery orders using Earned Value Management principles.
Configuration Management
The contractor shall establish a configuration management process to control critical hardware, software, and documentation. The contractor shall also implement an engineering control system that shall review and approve changes to drawings, documentation, software design, software code, parts lists, assembly/handling procedures, test procedures and quality procedures once a baseline has been established. The contractor shall have in place procedures to provide traceability of engineering models, prototypes, qualification and flight hardware, software and systems.
Property Management
The contractor shall maintain an inventory of all Government Furnished property and of items purchased for Contract Delivery Orders for both GRC on-site and at contractor facilities per the Property Clauses of the contract. During the audits, the contractor shall verify the accuracy of the inventory listing and verify the existence and locations of listed items.
Systems Engineering Management
The contractor shall perform systems engineering processes and procedures in the performance of flight hardware development. The contractor shall develop a Systems Engineering Management Plan that provides the basis for implementing the technical effort and documents the overall technical approach.
Reviews
The contractor shall provide engineering, management, documentation and planning support for NASA design reviews required by NASA Headquarters, other NASA field centers and NASA GRC to certify hardware and software maturity readiness.
PRODUCT ASSURANCE
The contractor shall be required to plan, implement and maintain a product assurance system to support all tasks under the Contract. Product Assurance Plans shall include system safety, risk assessment, materials and processes, quality assurance, problem reporting and corrective action system (PRACA), reliability and maintainability and software product assurance.
Quality Management
The contractor shall be certified to AS 9100 or, as a minimum, have an established proven effective quality program that is in accordance with FAR 42.202-3 Higher-level Contract Quality Requirements. (e.g.MIL-Q-9858)
System Safety
The contractor shall assure the overall system safety ofthe design that eliminates, reduces, or minimizes safety risk to an acceptable level. The contractor shall provide an overall contract Safety and Health Plan based on DID# PA-II. This plan shall address all hazards related to the work to be performed at ORC, other NASA facilities, and the contractor’s facilities, hazardous exposures to workers and ORC personnel, and plans to mitigate these hazards.
Materials and Processes
The contractor shall have a materials assurance process for documenting the Materials and Processes associated with the final design hardware using a Materials Identification and Usage List (MIUL), The materials assurance process must provide for certification of all parts and materials for composition and properties as defined by the design criteria. Materials used in applications that can be classified as limited life items, safety critical, and fracture critical shall be traceable through all critical processing procedures up to end-item application.
Material properties that shall be considered include, but not limited to, mechanical properties, fracture toughness, flammability, off-gas characteristics, corrosion, stress corrosion, thermal and mechanical fatigue properties, thermal vacuum stability, and fluid compatibility.
Reliability and Maintainability
The contractor shall perform all the reliability, availability, and maintainability engineering and assurance processes.
Hardware and Software shall be designed, assembled, tested, and inspected according to the Program requirements in order to meet the requirements stated in the Systems Requirement Document. In addition, the contractor may be required to conduct tests to demonstrate the ability of deliverables to survive mission simulation conditions, be reliable/maintainable in the space environment.
Software Product Assurance
The contractor will be required to assure the management, safety, and control of all flight-related software/firmware (including that used for ground support or mission operations) and the software development process ( e.g. configuration management, risk management, performance, functionality, safety, reliability, verification & validation processes and non-conformance reporting).
Risk Management
The contractor shall have a risk management process to control critical flight hardware, software, and documentation. Specific attention shall be given to the control of physical and functional interfaces. The specific process to be used by the contractor shall be defined in the overall contract Risk Management Plan (DID# PM02), based on the level of hardware complexity and carrier requirements.
References and Resources also include:
