4.2.13. Critical Design Review

DEFENSE ACQUISITION GUIDEBOOK
Chapter 4 -- Systems Engineering

4.2.13. Critical Design Review

4.2.13. Critical Design Review

The Critical Design Review (CDR) confirms the system design is stable and is expected to meet system performance requirements, confirms the system is on track to achieve affordability and should cost goals as evidenced by the detailed design documentation, and establishes the system’s initial product baseline. The system CDR occurs during the EMD phase and typically marks the end of the integrated system design efforts and readiness to continue with system capability and manufacturing process demonstration activities.

The CDR provides the acquisition community with evidence that the system, down to the lowest system element level, has a reasonable expectation of satisfying the requirements of the system performance specification as derived from the Capability Development Document (CDD) within current cost and schedule constraints.

The CDR establishes the initial product baseline for the system and its constituent system elements. It also establishes requirements and system interfaces for enabling system elements such as support equipment, training system, maintenance, and data systems. At this point the system has reached the necessary level of maturity to start fabricating, integrating, and testing pre-production articles with acceptable risk.

The product baseline describes the detailed design for production, fielding/deployment, and operations and support. The product baseline prescribes all necessary physical (form, fit, and function) characteristics and selected functional characteristics designated for production acceptance testing and production test requirements. It is traceable to the system performance requirements contained in the Capability Development Document (CDD). The initial system element product baseline is established and placed under configuration control at the system element CDR and verified later at the Physical Configuration Audit (PCA). In accordance with DoDI 5000.02, the Program Manager assumes control of the initial product baseline for all Class I configuration changes at the completion of the system level CDR to the extent that the competitive environment permits. This does not necessarily mean that the Program Manager takes delivery and acceptance of the Technical Data Package (TDP) (for more information, see DAG section 4.3.7. Configuration Management Process).

Roles and Responsibilities

The Systems Engineer documents the approach for the CDR in the Systems Engineering Plan (SEP). This includes identification of criteria, and artifacts defining the product baseline.

The Program Manager reviews and approves the approach, ensures the required resources are available, and recommends independent review participants.

The Program Manager and Systems Engineer may hold incremental CDRs for lower-level system elements, culminating with a system-level CDR. The system CDR assesses the final design as captured in system performance specifications for the lower-level system elements; it further ensures that documentation for the detailed design correctly and completely captures each such specification. The Program Manager and Systems Engineer evaluate the detailed designs and associated logistics elements to determine whether they correctly and completely implement all allocated system requirements, and whether they have maintained traceability to the CDD.

The Program Manager’s responsibilities include:

• Approve, fund, and staff the system CDR as planned in the SEP developed by the Systems Engineer
• Establish the plan to the System Verification Review (SVR) in applicable contract documents including the SE Management Plan (SEMP), Integrated Master Schedule (IMS), and Integrated Master Plan (IMP)
• Ensure the plan includes independent subject matter experts to participate in each review
• Control the configuration of the Government-controlled subset of the functional, allocated, and product baselines; convene Configuration Steering Boards (CSBs) when changes are warranted

The Systems Engineer’s responsibilities include:

• Develop and execute the system CDR plans with established quantifiable review criteria, carefully tailored to satisfy program objectives
• Ensure that the pre-established review criteria have been met to ensure the design has been captured in the allocated baseline and initial product baseline
• Ensure assessments and risks associated with all design constraints and considerations are conducted, documented, and provided (e.g., reliability and maintainability, corrosion, and Environment, Safety, and Occupational Health (ESOH) considerations)
• Determine the root cause of problems, identify corrective actions, and manage to completion
• Monitor and control the execution of the CDR closure plans
• Document the plan to SVR in the SEP and elsewhere as appropriate

The USD(AT&L) memorandum, “Expected Business Practice: Post-Critical Design Review Reports and Assessments” directs the DASD(SE)) to participate in CDRs for Major Defense Acquisition Programs (MDAPs), and prepare a brief assessment of the program’s design maturity and technical risks that may require Milestone Decision Authority (MDA) attention.

Inputs and Review Criteria

Figure 4.2.13.F1 provides the end-to-end perspective and the integration of SE technical reviews and audits across the acquisition life cycle.

Figure 4.2.13.F1. Weapon System Development Life Cycle

The March 2012 Government Accountability Office (GAO) report, “Assessments of Selected Weapon Programs,” suggests a best practice is to achieve design stability at the system-level CDR. A general rule is that 75 to 90 percent of (manufacturing quality) product drawings, software design specification(s), and associated instructions (100 percent for all Critical Safety Items (CSIs) and Critical Application Items (CAIs)) should be complete in order to provide tangible evidence of a stable product design. A prototype demonstration shows that the design is capable of meeting performance requirements.

The CDR review criteria are developed to best support the program’s technical scope and risk and are documented in the program’s SEP no later than Milestone B. Table 4.2.13.T1 defines the products and associated review criteria. The system-level CDR review should not begin until these criteria are considered met and any prior technical review is complete and its action items closed. A readiness assessment tool for CDR preparation is the DoD CDR Checklist. The CDR is a mandatory technical review.

Table 4.2.13.T1. CDR Products and Criteria

Outputs and Products

The Technical Review Chair determines when the review is complete. Completion of the CDR should provide the following:

• An established system initial product baseline
• Acceptable risks with mitigation plans approved and documented in the IMS
• Updated CARD (or CARD-like document) based on the system Initial product baseline
• Updated program development schedule including fabrication, test and evaluation, software coding, and critical path drivers
• Corrective action plans for issues identified in the PDR
• Updated LCSP, including program sustainment development efforts and schedules based on current budgets, test evaluation results and firm supportability design features

Note that baselines for some supporting items might not be at the detailed level and may lag the system-level CDR. Enabling systems may be on different life-cycle timelines. The CDR agenda should include a review of all this information, but any statement that all detailed design activity on these systems is complete may lead to misunderstandings. As an example, development of simulators and other training systems tends to lag weapon system development.

Top of page