Back to Top

Defense Acquisitions Made Easy

Blog Archives

Major Reviews

Preliminary Design Review (PDR)

 

Major Reviews


The Preliminary Design Review (PDR) is a technical assessment that establishes the physically Allocated Baseline of a system to ensure a system in operationally effective.  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.

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 (ICD), 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.
  • 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:

Major Reviews

Critical Design Review (CDR)

A Critical Design Review (CDR) is a multi-disciplined technical review to ensure that a system can proceed into fabrication, demonstration, and test and can meet stated performance requirements within cost, schedule, and risk.  A successful CDR is predicated upon a determination that the detailed design satisfies the Capabilities Development Document (CDD).  Multiple CDRs may be held for key Configuration Items (CI) and/or at each subsystem level, culminating in a system-level CDR. The CDR is conducted during the Engineering, Manufacturing and Development (EMD) phase and when the product baseline has been achieved and the CDR entrance criteria detailed in the Systems Engineering Plan (SEP) have been met, allowing fabrication of hardware and coding of software deliverables to proceed.

Checklist: DoD Critical Design Review (CDR)

Checklist: Critical Design Review Checklist – Jan 2015

A CDR assesses the system final design as captured in product specifications for each Configuration Item in the system’s product baseline and ensures that each configuration item has been captured in the detailed design documentation. The resulting set of detailed drawings and specifications establish an initial product baseline, with a final baseline incorporating any design changes resulting from System Demonstration and Initial Operational Test and Evaluation (IOT&E).  The completion of CDR usually initiates the start of formal Configuration Management (CM) by the Contractor of the Technical Baseline.  Any changes to that baseline can only be accomplished with the approval of the Government.





A CDR should: [1]

  • Determine that detail design of the configuration item under review satisfies cost (for cost type contracts), schedule, and performance requirements.
  • Establish detail design compatibility among the configuration item and other items of equipment, facilities, computer software and personnel.
  • Assess configuration item risk areas (on a technical, cost, and schedule basis).
  • Assess the results of producibility analyses conducted on system hardware.
  • Review preliminary hardware product specifications.
  • Determine the acceptability of the detailed design, performance, and test characteristics, and on the adequacy of the operation and support documents.

Completion of CDR should provide: [1]

  1. An system initial Product Baseline,
  2. An updated risk assessment for Engineering, Manufacturing and Development (EMD),
  3. An updated Cost Analysis Requirements Description (CARD) based on the system product baseline,
  4. An updated program development schedule including fabrication, test and evaluation, and software coding, critical path drivers, and
  5. An approved Life-Cycle Sustainment Plan (LCSP) updating program sustainment development efforts and schedules based on current budgets, test evaluation results and firm supportability design features.

Post-CDR Assessment
For Major Defense Acquisition Programs (MDAP), the Deputy Assistant Secretary of Defense (Systems Engineering) “DASD(SE)” will assess the design maturity and technical risks evident in the CDR. Program Managers (PM) of these programs are required to invite DASD(SE) engineers to their system-level CDRs and make available CDR artifacts. These will include all CDR briefings and those artifacts that constitute the initial product baseline.
[1]


AcqTips:

AcqLinks and References:

Update: 12/26/2017

Major Reviews

Operational Test Readiness Review (OTRR)

 

Major Reviews


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:

Major Reviews

Alternative Systems Review (ASR)

 

Major Reviews


An Alternative Systems Review (ASR) is a technical review that assesses the preliminary materiel solutions that have been developed during the Materiel Solution Analysis (MSA) Phase.  The review ensures that one or more proposed materiel solution(s) have the best potential to be cost effective, affordable, operationally effective and suitable, and can be developed to provide a timely solution to at an acceptable level of risk to satisfy the capabilities listed in an Initial Capabilities Document (ICD).

Checklist: ASR Risk Assessment Checklist

A successful ASR is predicated on the review team’s determination that the operational capabilities, proposed solution(s), available technologies, and program resources (funding, schedule, staffing, infrastructure, and processes) form a satisfactory basis for proceeding into the Technology Development (TD) Phase.  An ASR should provide information to the Milestone A review before proceeding into the TD Phase.

Completion of the ASR should provide the following: [1]

  1. An agreement on the proposed materiel solution(s) (including the corresponding product support concept) to take forward into the milestone decision and subsequent Technology Development phase.
  2. Hardware and software architectural constraints/drivers to address all Key Performance Parameters (KPPs)
  3. An assessment of the full system software concept to include conceptual definition of the complete deliverable/non-deliverable software, scope, and risk.
  4. A comprehensive rationale for the proposed materiel solution(s), based upon the Analysis of Alternatives (AoA) that evaluated relative cost, schedule, performance (hardware, human, software), and technology risks.
  5. A comprehensive assessment of the relative risks associated with including Commercial off-the-Shelf (COTS)  items in the program, with emphasis on host platform environmental design, diagnostic information integration, and maintenance concept compatibility.
  6. A comprehensive risk assessment for the Technology Development (TD) phase.
  7. Results of Trade Studies/technical demonstrations for concept risk reduction.
  8. Joint requirements for the purposes of commonality, compatibility, interoperability, and integration.
  9. Refined thresholds and objectives initially stated as broad measures of effectiveness and suitability (e.g., Key Performance Parameters (KPP) / Key System Attributes (KSA)).
  10. Completed, comprehensive planning for the Technology Development phase (hardware, software and human systems), including critical components to be developed, prototyped, and demonstrated, their cost, and critical path drivers. This planning could include an Integrated Master Plan (IMP) and Integrated Master Schedule (IMS).
  11. Initial planning for the Engineering and Manufacturing Development (EMD) phase.
  12. A draft System Requirements Document (SRD)  if one does not already exist. (This is a high-level engineering document that represents the customer/user capability needs as system requirements.) This systems requirement document should include a system level description of all software elements required by the preferred system concept.

AcqTips:

  • The ASR 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.

AcqLinks and References:

Major Reviews

Production Readiness Review (PRR)

 

Major Reviews


The Production Readiness Review (PRR) assesses a program to determine if the design is ready for production. It assesses if the prime contractor and major subcontractors have accomplished adequate production planning without incurring unacceptable risks that will breach thresholds of schedule, performance, cost, or other established criteria. PRRs are normally performed as a series of reviews toward the end of Engineering, Manufacturing and Development (EMD) Phase and should be conducted during System Capability and Manufacturing Process Demonstration to identify and mitigate risks as the design progresses.

The PRR evaluates the full, production-configured system to determine if it correctly and completely implements all system requirements. The review determines whether the traceability of final system requirements to the final production system is maintained. A successful review is predicated on the determination that the system requirements are fully met in the final production configuration and that production capability forms a satisfactory basis for proceeding into Low-Rate Initial Production (LRIP) and Full-Rate Production (FRP).

The PRR should review:

  • The manufacturing readiness process
  • Quality management system
  • Production planning
  • System requirements compliance
  • Inventory management
  • Supplier management

AcqLinks and References:

Major Reviews

Major Reviews Overview

Major Reviews


A Major Program Review is a time based event where all key stakeholders on an acquisition program gather to discuss the progress of their program. Usually the review decides if there is sufficient data to suggest that a program can proceed to the next phase of the program. There are two main categories of reviews that take place during the life-cycle of an acquisition program.  These are:

  1. Program
  2. Technical

Program Reviews
Program Reviews are a fundamental part of an acquisition program that focus on cost, schedule and performance. They’re an important oversight tool that the Program Manager (PM) and key Stakeholders can use to review and evaluate the state of the program, re-directing activity if necessary. The majority of program reviews focus on determining if a program has achieved it objectives to-date and will be allowed to proceed into the next acquisition phase.

The main program reviews during an acquisition program are:

Technical Reviews
Technical Reviews are a fundamental part of the Systems Engineering Technical Assessment Process for the PM. They’re an important oversight tool that the PM can use to review and evaluate the state of the system and the program, re-directing activity if necessary. They examine if a program is achieving its technical objectives as detailed in the acquisition strategy. Technical reviews can include an assessment of systems engineering, software, risk management, requirements, technology readiness & development, and the technical baseline.

The most commonly used technical reviews during most acquisition programs are:

AcqLinks and References:

Updated: 1/27/2018