Proposal Development

Statement of Objectives (SOO)

The Statement of Objectives (SOO) identifies the broad, basic, top-level objectives of an acquisition/procurement and is used as a focusing tool for both the Government and offeror’s.  In a competitive source selection environment an SOO is an integral part of the Request for Proposal (RFP) streamlined development process.  A SOO supplements a requirements document (ICD, CDD, performance-based Government requirements document) and is developed after performing a risk assessment that highlights the high and moderate risks in the areas of business, programmatic, and technical identified on the program against the requirement document. [1]

Guide: Statement of Objectives Information Guide (Old but still useful)

Statement of Objective (SOO) Development

A SOO is developed to be compatible with; Initial Capabilities Document (ICD); programmatic direction from the Acquisition Decision Memorandum (ADM), Acquisition Strategy, and Acquisition Plan; technical requirements from system specifications; and the draft Work Breakdown Structure (WBS) and dictionary.  The SOO is then used, by offeror’s, to develop the Contractor Statement of Work (CSOW), the Contract Work Breakdown Structure (CWBS), the Integrated Master Schedule (IMS), and other documents supporting and defining the contractor proposed effort. [1]

SOO content should be tailored to the type and phase of the program.  The key is to keep the SOO clear, concise, and provide potential offeror’s with enough information and detail to structure a sound program, designed to be executable and satisfy Government objectives.  The SOO as a part of the RFP or solicitation has value to both the industry and the government. [1]

Statement of Objectives (SOO) Development Steps:

The following are steps that are an integral part of developing the SOO: [1]

  • Step 1: Conduct market research to determine whether commercial items or non-developmental items are available to meet program requirements.
  • Step 2: Review the requirements documents that authorize the program, various DoD, services, joint services requirements documents for program management and acquisition management impacts to the program.
  • Step 3: Prepare a bibliography citing the specific portions of all applicable governing instructions, directives, specifications, and standards with which the program must comply.
  • Step 4: Develop the program objectives by completing a risk assessment that highlights the high and moderate risks in the areas of business, programmatic, and technical identified on the program based on the requirements in the requirements document.
  • Step 5: Draft the Statement of Objectives for review

Statement of Objectives (SOO) Notional Format:

  1. Overall Program Objectives
    • Multi-Phased Program
    • One Program, Multi-Contractor
    • One Phase Contract
  2. Contract Objectives
    • Objectives in paragraph 2.0 are traceable to level 0 WBS elements.
    • For multi-phase programs, describe objectives for each phase in a format similar to an indentured list (clearly indicate which phases are part of the anticipated contract and any phases that will involve separate contracts).
  3. Program Management Objectives
    • The management objectives are to allow the offeror the maximum flexibility to innovatively manage the projected schedule, performance, risks, warranties, subcontracts, and data to provide the goods or services that satisfy the government’s performance requirements.  This is tailored to meet the specific program needs.
  4. Engineering Objectives
  5. Logistics Objectives

Examples Statement of Objectives (SOO) Tasks

The following are some examples of software-related SOO that can be used. [1]

  • An efficient development program that balances risk, cost, schedule, and performance.
  • Phased development via incremental software/hardware development approaches.
  • A comprehensive Systems Engineering Process to specify, design, develop, integrate, test, produce, deliver, verify, validate, document, and sustain the system/software that:
    • Satisfies all System Requirements Document (SRD) / Capabilities Development Document (CDD) threshold requirements.
    • Supports rapid, cost-effective development/modification of the operational system, training system, and support components to meet System Requirements Document (SRD) thresholds and as many objectives as are affordable.
    • Includes the ability to easily and inexpensively upgrade existing equipment and/or insert new technologies as they become available.
    • Mitigates the risks associated with technology obsolescence, proprietary technologies, and reliance on a single source of supply over the life of the system.
    • Ensures interoperability with the Global Information Grid (GIG) systems and ground processing infrastructures.
    • Reduces system life cycle cost and logistics footprint by addressing required quality attributes, such as reliability, maintainability, supportability, safety, security, and human factors.
    • Supports rapid, cost effective modification/upgrade/technology insertion.
  • An effective system/software development and integration process that uses a modular open systems architecture approach.
  • Timely deployment of initial training components.
  • Use of contractor management processes, procedures, systems, internal metrics, and performance measures unless their use conflicts with contract requirements or does not allow contract requirements to be completely met.
  • Timely, cost-effective transition to organic support that ensures access to all required technical data and computer software, and associated license rights.

Performance Work Statement (PWS) vs. Statement of Objective (SOO)

The SOO is a Government prepared document that provides the basic, high-level objectives of the acquisition. It is provided in the solicitation in lieu of a government written Performance Work Statement (PWS). In this approach, the contractors’ proposals contain their statements of work and performance metrics and measures (which are based on their proposed solutions).

Statement of Objective (SOO) Misunderstandings

There are a number of misunderstandings associated with SOO that are addressed below:

  • The SOO must be Two Pages in Length: There is no predetermined length for the SOO.  It should be a concise, cogent document of appropriate length.
  • The SOO replaces the Statement of Work (SOW) in solicitations: The SOO is not a replacement for the SOW.  The documents are different in scope and nature.
  • There must be a SOO and SOW in every solicitation: Some have thought that every solicitation must have both a SOO and a government SOW, not so.  There are situations where a SOO should be used such as, on a service contract where a performance work statement is being used.
  • A SOO is not appropriate for a sole source or service contract: The SOO product may not be supplied in every sole source or service contract but the SOO process is always appropriate.

AcqNotes Tutorial

AcqTips:

  • The SOO should not address each WBS element, but each WBS element should be traceable to something in the SOO.
  • Remember a SOO is NOT a Statement of Work (SOW), it results from the identification of risks based on the requirements document.
  • See Examples of Software SOO

AcqLinks and References:

Updated: 5/22/2021

Rank: G2.7

Leave a Reply