Back to Top

Defense Acquisitions Made Easy

Blog Archives

JCIDS Process

Joint Operations Concepts (JOpsC)

Joint Operations Concepts (JOpsC) is a family of joint future concepts consisting of a Capstone Concept for Joint Operations (CCJO), Joint Operating Concepts (JOC), Joint Functional Concepts (JFC), and Joint Integrating Concepts (JIC). The objective of JOpsC is to guide the transformation of the joint force so that it is prepared to operate successfully 8 to 20 years in the future.  They are a visualization of future operations and describe how a commander, using military art and science, might employ capabilities necessary to successfully meet challenges in the future.

The JOpsC should produce military capabilities that render previous ways of warfighting obsolete and may significantly change the measures of success in military operations overall. JOpsC presents a detailed description of “how” future operations may be conducted and provides the conceptual basis for joint experimentation and Capabilities-Based Assessments (CBAs). The outcomes of experimentation and CBA will underpin investment decisions leading to the development of new military capabilities beyond the Future Years Defense Program (FDYP). [1]

The JOpsC is a family of joint future concepts consisting of the:

  • Capstone Concept for Joint Operations (CCJO):  Overarching concept that guides the development of future joint force capabilities. It broadly describes how the joint force is expected to operate 8-20 years in the future in all domains across the range of military operations within a multilateral environment and in collaboration with interagency and multilateral partners.
  • Joint Operating Concepts (JOCs): Applies the CCJO solution in greater detail to a specified mission area, and describes how a joint force commander, 8-20 years in the future, is expected to conduct operations within a military campaign.
  • Joint Functional Concepts (JFCs): Applies elements of the Capstone Concept for Joint Operations solution to describe how the joint force, 8-20 years in the future, will perform an enduring military function across the full range of military operations, and identifies the operational-level capabilities required to support the full range of military operations. Also determines any additional military capabilities required to create the effects identified in JOCs.
  • Joint Integrating Concepts (JICs): Operational-level description of how a joint force commander, 8-20 years in the future, will perform a specific operation or function derived from a Joint Operating Concept and/or a Joint Functional Concept. They are narrowly scoped to identify, describe, and apply specific military capabilities, decomposing them into fundamental tasks, conditions, and standards.

Services, combatant commands, and Defense agencies conduct basic research, explore emerging technologies, generate innovative concepts, and conduct experimentation to develop service-unique or joint capabilities. These efforts provide the context for analyzing capabilities for the future joint force beyond the FYDP. The results of this analysis will influence Planning, Programming, Budgeting and Execution (PPBE) decisions as well as identify potential future concepts for the JOpsC family.

AcqTips:

AcqLinks and Resources:

Updated: 7/12/2017

PPBE Process

Guidance of the Development Employment of Force

Update: The GDF and Joint Programming Guidance (JPG) have been combined and been replaced by the Defense Programming and Planning Guidance (DPPG) [2]

Guidance for Development of the Force (GDF)
GDF establishes the DoD’s force development planning and resource priorities needed to meet future contingencies. The GDF is issued early in the planning process to provide overall policy and strategy guidance to be used in developing the defense program. It provides Secretary of Defense’s (SECDEF’s) politico-military guidance to inform development of the Joint Programming Guidance (JPG) and Program Objective Memorandum (POM), and is informed by the National Defense Strategy (NDS) and National Military Strategy (NMS). [1]

Guidance for Employment of the Force (GEF)
GFE provides comprehensive, near-term planning guidance. The GEF and Joint Strategic Capabilities Plan (JSCP) are companion documents. Provides Presidential and Secretary of Defense (SECDEF) politico-military guidance. The President approves the contingency planning guidance contained in the GEF and approves the Secretary’s issuance of the GEF. The GEF is informed by the Unified Command Plan and National Defense Strategy (NDS); and it informs strategic policy guidance, campaign plans, and the JSCP. [1]

Joint Strategic Capabilities Plan (JSCP)
The JSCP provides detailed planning guidance to implement the GEF’s strategic policy guidance and specifically tasks combatant commanders to develop campaign, campaign support, contingency, and posture plans. It fulfills Title 10 requirement for the Chairman to produce strategic plans and provides assistance to President and the Secretary of Defense in military direction to the Armed Forces. The JSCP is informed by the GEF and NMS and directs campaign, campaign support, contingency, and posture planning. [1]

AcqLinks and References: 

Updated: 7/13/2017

Acquisition Process

Selected Acquisition Report (SAR)

A Selected Acquisition Report (SAR) is a comprehensive summary of a Major Defense Acquisition Program (MDAP) Acquisition Category (ACAT) I program that is required for periodic submission to Congress by the Secretary of Defense. It’s mandated by Title 10 USC § 2432 “Selected Acquisition Reports”.


Content

The SAR includes the status of the total program cost, schedule, and performance, as well as program unit cost and unit cost breach information. It also includes a full life-cycle cost analysis of the program ad all its increments.

Preparation

The PM will use the Defense Acquisition Management Information Retrieval (DAMIR) application to prepare the SAR.

Submission

The SAR for the quarter ending December 31 is the annual SAR. The Program Manager (PM) will submit the annual SAR within 60 days after the President transmits the following fiscal year’s budget to Congress. Annual SARs will reflect the President’s Budget and supporting documentation. The annual SAR is mandatory for all Acquisition Category (ACAT) I programs.

The PM will submit quarterly exception SARs for the quarters ending March 31, June 30, and September 30 not later than 45 days after the quarter ends. Quarterly SARs are reported on an exception basis, as follows: [1]

  • The current estimate exceeds the Program Acquisition Unit Cost (PAUC) objective or the Average Procurement Unit Cost (APUC) objective of the currently approved Acquisition Program Baseline (APB) in base-year dollars by 15 percent or more;
  • The current estimate includes a 6-month or greater delay, for any schedule parameter, that occurred since the current estimate reported in the previous SAR;
  • Milestone B or Milestone C approval occurs within the reportable quarter.
  • Quarterly exception SARs will report the current estimate of the program for cost, schedule, and performance.

Pre-Milestone B projects may submit Research, Development Test & Evaluation (RDT&E)-only reports, excluding procurement, military construction, and acquisition-related operations and maintenance costs. DoD Components should notify the Under Secretary of Defense (USD) Acquisition Technology & Logistics (AT&L) with names of the projects for which they intend to submit RDT&E-only SARs 30 days before the reporting quarter ends. USD(AT&L) should also notify Congress 15 days before reports are due. [1]

Waivers

The Secretary of Defense may waive the requirement for submission of a SAR for a program for a fiscal year if: [1]

Termination

The Under Secretary of Defense (Acquisition, Technology, and Logistics) will consider terminating reporting of SAR data when 90 percent of expected production deliveries or planned acquisition expenditures have been made, or when the program is no longer considered an ACAT I program in accordance with section 2432 of tile 10, United States Code.

AcqLinks and References:

Updated: 6/19/2018

JCIDS Process

Systems Engineering Plan (SEP)

The Systems Engineering Plan (SEP) is a living document that details the execution, management, and control of the technical aspects of an acquisition program from conception to disposal. The SEP outlines how the systems engineering process is applied and tailored to meet objectives for each acquisition phase. The SEP captures a program’s current and evolving systems engineering strategy and its relationship with the overall program management effort. The SEP should include the process and criteria for updating the document. The SEP is updated as needed to reflect technical progress achieved to date and to reflect changes in the technical approaches stemming from the findings and results of the technical reviews, program reviews, acquisition milestones, or other program decision points. The SEP is updated and submitted for Milestone Decision Authority (MDA) approval at each program milestone. A draft update is due for the Development RFP Release Decision Point and approved at Milestone B.

The purpose of the SEP is to help program technical managers develop their systems engineering approach—providing a firm and well-documented technical foundation for the program. A rigorous technical planning process forces thoughtful consideration and debate, allows for integration and coordination of technical activities across all levels of management, and results in a sound systems engineering strategy commensurate with the program’s technical issues, life cycle phasing, and overall objectives.

Outline: System Engineering Plan (SEP) Outline Version 3.0 – 12 May 2017

The Office of the Secretary of Defense (OSD) suggests that programs organize the SEP according to five critical focus areas: [1]

  1. Program Technical Requirements: The SEP should define how the program will manage all requirements (statutory, regulatory, derived, certification).
  2. Technical Staffing and Organization Planning: The SEP should show how the program will structure and organize the program team to satisfy requirements.
  3. Technical Baseline Management: The SEP should establish a technical baselines approach.
  4. Technical Review Planning: The SEP should show how the program will manage the technical effort, including the technical baselines, through event-based technical reviews.
  5. Integration with Overall Management of the Program: The SEP should link SE to other management efforts, including the Acquisition Strategy, test planning, sustainment planning, Configuration Management, Risk Management, and life-cycle management.

Key documents that refer to the Systems Engineering Plan and should be coordinated with:

REGULATORY:  A draft update is due for the Development RFP Release Decision Point and approved at Milestone B. The Deputy Assistant Secretary of Defense (Systems Engineering) (DASD(SE)) is the approval authority for Major Defense Acquisition Programs (MDAP) and Major Automated Information System (MAIS) programs; the Component head or as delegated will approve the SEP for all other programs. [2]

AcqTips:  

  • The Systems Engineering Plan (SEP) is not a Systems Engineering Management Plan (SEMP).  The SEMP is developed to manage the development of a system by a contractor. Its written in response to a government SEP and provides unique insight as to the application of a contractor’s standards, capability models, and toolsets to the development of a system.
  • The SEP should be established early in the program definition stages and updated periodically as the program matures. Only by starting systems engineering processes early and monitoring them through the life cycle can programs effectively manage cost, schedule, and performance.
  • Software planning in the Systems Engineering Plan

AcqLinks and References:

Updated: 5/27/2020

Acquisition Process

Flight Readiness Review (FRR)

A Flight Readiness Review (FRR) is a sub-set of the Test Readiness Review (TRR) and is applicable only to aviation programs. It assesses the readiness to initiate and conduct flight tests or flight operations. Typically, FRR approval requires the aviation system to be under Configuration Management (CM), have a flight clearance issued by the technical authority, approved flight test plan(s), discrepancy tracking and risk assessment processes in place.

The FRR is a technical assessment establishing the configuration to be used in flight testing to ensure that the system has a reasonable expectation of being judged operationally effective and suitable.  This review assesses a system test environment to ensure that the system under review can proceed into flight test with airworthiness standards met, objectives clearly stated, flight test data requirements clearly identified, and an acceptable Risk Management Plan (RMP) defined and approved. [1]

An FRR shall be conducted prior to the first flight of any new air vehicle.  For complex systems, an FRR shall be conducted with an assessment of each subsystem or Configuration Item (CI) prior to flight.  An FRR is also required prior to the first flight of any major changes to hardware, software, envelope, or objectives not covered in a previous FRR. [1]

AcqLinks and References:

Updated: 8/01/2017

Acquisition Process

Integrated Baseline Review (IBR)

An Integrated Baseline Review (IBR) is a joint assessment conducted by the government Program Manager (PM) and the contractor to establish a mutual understanding of the Performance Measurement Baseline (PMB). This understanding provides for an agreement on a plan of action to evaluate the risks inherent in the PMB and the management processes that operate during program execution. PM’s are required to conduct IBRs on all cost or incentive contracts that require the implementation of Earned Value Management (EVM) (contracts valued at or greater than $20 million).  IBRs should be used to understand:

  • The scope of the PMB consistent with authorizing documents;
  • Management control processes;
  • Risks in the PMB associated with cost, schedules, and resources; and
  • Corrective actions where necessary.

IBR FigureCompletion of the review should result in the assessment of risk within the PMB and the degree to which the following have been established:

  1. Technical scope of work is fully included and is consistent with authorizing documents,
  2. Key project schedule milestones are identified and supporting schedules reflect a logical flow to accomplish the work,
  3. Resources (budgets, facilities, infrastructure, personnel, skills, etc.) are available and are adequate for the assigned tasks,
  4. Tasks are planned and can be measured objectively relative to the technical progress,
  5. Rationales underlying the PMB are reasonable, and
  6. Management processes support successful execution of the project.

IBRs should be scheduled as early as practicable and the timing of the IBRs should take into consideration the contract period of performance. The process will be conducted not later than 180 calendar days (6 months) after:

  1. Contract award,
  2. Exercise of significant contract options, and
  3. Incorporation of major modifications.

IBRs are also performed at the discretion of the PM or within a reasonable time after the occurrence of major events in the life of a program. These events may be completion of the Preliminary Design Review (PDR), completion of the Critical Design Review (CDR), a significant shift in the content and/or time phasing of the PMB, or when a major milestone such as the start of the production option of a development contract is reached. Continuous assessment of the PMB will identify when a new IBR should be conducted.

AcqTips:

AcqLinks and References:

Updated: 5/24/2018

Acquisition Process

System Verification Review (SVR)

The System Verification Review (SVR) is a product and process assessment to ensure the system under review can proceed into Low-Rate Initial Production (LRIP) and Full-Rate Production (FRP) within cost, schedule, risk, and other system constraints during the Engineering, Manufacturing and Development (EMD) Phase.  It assesses the system functionality and determines if it meets the functional requirements in the Capability Development Document (CDD) and draft Capability Production Document (CPD) documented in the functional baseline. The SVR establishes and verifies final product performance and provides inputs to the CPD.

Checklist: DoD System Verification Review (SVR)

Typical SVR success criteria include affirmative answers to the following exit questions:

  1. Does the status of the technical effort and system indicate operational test success (operationally effective and suitable)?
  2. Can the system satisfy the Capability Development Document (CDD) and draft Capability Production Document (CPD)?
  3. Are adequate processes and metrics in place for the program to succeed?
  4. Are the risks known and manageable?
  5. Is the program schedule executable within the anticipated cost and technical risks?
  6. Are the system requirements understood to the level appropriate for this review?
  7. Is the program properly staffed?
  8. Is the program’s non-recurring engineering requirement executable with the existing budget?
  9. Is the system producible within the production budget?

The SVR is often conducted concurrently with the Production Readiness Review (PRR) and Functional Configuration Audit (FCA). Product support IPT members should participate in the review to:

  • Address system supportability and, based on developmental testing or analysis whether the sustainment features will satisfy the Capability Development Document/draft Capability Production Document and Sustainment Key Performance Parameters (KPP) / Key System Attributes (KSA).
  •  Adequate processes are in place so the sustainment performance metrics can be used to help the program to succeed in meeting user needs.
  • Ascertain if the system is supportable within the procurement, operations, and support budgets.

The SVR risk assessment checklist is designed as a technical review preparation tool and should be used as the primary guide for assessing risk during the review. This checklist is attached below.

AcqTips:

AcqLinks and References:

Updated: 6/01/2018

Acquisition Process

Preliminary Design Review (PDR)

The Preliminary Design Review (PDR) is a technical assessment that establishes the Allocated Baseline of a system to ensure a system is operationally effective.  A PDR is conducted before the start of detailed design work and is the first opportunity for the Government to closely observe the Contractor’s hardware and software design.  This review assesses the allocated design documented in subsystem product specifications for each configuration item in the system and ensures that each function, in the Functional Baseline, has been allocated to one or more system configuration items. The PDR establishes the allocated baseline (hardware, software, human/support systems) and underlying architectures to ensure that the system under review has a reasonable expectation of satisfying the requirements within the currently allocated budget and schedule.

Acquisition System

For complex systems, a PDR may be conducted incrementally for each configuration item. These incremental reviews lead to an overall system-level PDR. System-level performance is supported by compliance with Interface Control Documents, but not assured. Interface requirements make up each configuration item Allocated Specification.





The Weapons System Acquisition Reform Act of 2009 directed the PDR to: 

  • PDRs before Milestone (MS) B are mandatory for all Major Defense Acquisition Programs (MDAP) and will be reflected in the Technology Development Strategy (TDS) to be approved by the MDA at MS A. Post-PDR assessments will be conducted in association with MS B preparations and will be formally considered by the Milestone Decision Authority (MDA) at the MS B certification review.
  • The timing of PDRs for other than MDAPs will be approved by the DoD Component MDA when consistent with TDS or Acquisition Strategy objectives. When the PDR is conducted before MS B, a post-PDR assessment will be conducted in association with the MS B review and formally considered by the MDA at the MS B review. If the PDR is conducted after MS B, the MDA will conduct a post-PDR assessment at a time reflected in the approved acquisition strategy.
  • PDR before MS B is now a statutory requirement for MDAPs. The post-PDR assessment will be conducted during the MS B review, and prior to the section 2366b certification by the MDA per title 10, Unites States Code.

Completion of the PDR should provide the following:

AcqTips:

  • The Program Manager (PM) should conduct the PDR when all major design issues have been resolved and work can begin on detailed design. The PDR should address and resolve critical, system-wide issues.
  • IEEE 5288.2 “Standard for Technical Reviews and Audits on Defense Programs” is the standard for technical reviews and audits to be performed throughout the acquisition life cycle for the US Department of Defense (DoD) and other defense agencies. This standard guides the DoD and contractor on what is required during an SRR
  • The PDR should be conducted when the allocated baseline has been achieved, allowing detailed design of hardware and software configuration items to proceed. A rule of thumb is that 10 percent to 25 percent of product drawings and associated instructions should be complete, and that 100 percent of all safety-critical component (Critical Safety Items and Critical Application Items) drawings are complete.

AcqLinks and References:

Updated: 5/23/2018

Acquisition Process

Operational Test Readiness Review

 

The Operational Test Readiness Review (OTRR) assess if a system should proceed into Initial Operational Test and Evaluation (IOT&E). The review addresses and verifies system reliability, maintainability, and supportability performance and determines if the hazards and Environmental, Safety, Occupational and Health (ESOH) residual risks are manageable within the planned testing operations.  This assessment determines if changes are required in planning, resources, or testing necessary to proceed with IOT&E. Of critical importance to this review is the understanding of available system performance to meet the Capability Production Document (CPD) performance threshold values. The OTRR may be conducted in multiple steps to ensure that the “production configuration” system (usually the Low-Rate Initial Production (LRIP) system) can proceed into Operational Test & Evaluation (OT&E) with a high probability of success.

Checklist: Operational Test Readiness Review (OTRR) Checklist

Programs on the Office of Secretary of Defense (OSD) Test and Evaluation (T&E) oversight list are required by DoD policy to establish a Service process for determining and certifying a program’s readiness for IOT&E by the Service Component Acquisition Executive (CAE).  The OTRR is only complete when the CAE evaluates and determines materiel system readiness for IOT&E. The OTRR may be conducted by the Program Manager (PM) or the Operational Test Agency, depending on Service policy.

DoD specifies that the OTRR review shall include:

AcqLinks and References: