Major Capability Acquisition (MCA)

AAF > MCA > Technical Reviews > Preliminary Design Review

Preliminary Design Review (PDR)

How To Use This Site

Each page in this pathway presents a wealth of curated knowledge from acquisition policies, guides, templates, training, reports, websites, case studies, and other resources. It also provides a framework for functional experts and practitioners across DoD to contribute to the collective knowledge base. This site aggregates official DoD policies, guides, references, and more.

DoD and Service policy is indicated by a BLUE vertical line.

Directly quoted material is preceeded with a link to the Reference Source.

Reference Source: 10 USC 2366b

A major defense acquisition program may not receive Milestone B approval until the milestone decision authority has received a preliminary design review and conducted a formal post-preliminary design review assessment, and certifies on the basis of such assessment that the program demonstrates a high likelihood of accomplishing its intended mission

Reference Source: DAG CH 3-3.3.4 Preliminary Design Review

The Preliminary Design Review (PDR) should provide sufficient confidence to proceed with detailed design. The PDR ensures the preliminary design and basic system architecture are complete, that there is technical confidence the capability need can be satisfied within cost and schedule goals and that risks have been identified and mitigation plans established. It also provides the acquisition community, end user and other stakeholders with an opportunity to understand the trade studies conducted during the preliminary design, and thus confirm that design decisions are consistent with the user’s performance and schedule needs and the validated Capability Development Document (CDD). The PDR also establishes the allocated baseline.

The allocated baseline describes the functional and interface requirements to a level in the system architecture sufficient to define hardware configuration item requirements distinct from software configuration item requirements, together with the verification required to demonstrate achievement of those requirements. The allocated baseline for each lower-level system element (hardware and software) is usually established and put under configuration control at the system element PDR. This process is repeated for each system element and culminates in the Program Manager (PM) establishing the complete allocated baseline at the system-level PDR. The PM then verifies the allocated baseline at the Functional Configuration Audit (FCA) and/or System Verification Review (SVR).

The PDR is mandatory. The timing of the review should consider the following:

PDR is conducted prior to Milestone B and prior to the contract award for Engineering and Manufacturing Development for all programs unless waived. Additionally, 10 U.S.C. 2366b requires the Milestone Decision Authority (MDA) certify all Major Defense Acquisition Programs (MDAPs) at Milestone B. This certification requires the conduct and assessment of a PDR, unless waived for national security reasons.
The timing of PDR relative to the Development Request for Proposal (RFP) Release Decision Point is at the discretion of the DoD Component and should balance the need for more mature design information with the costs of extending the activities of multiple sources or having a gap in development. Regardless of this relationship, the PDR assessment is done after PDR and prior to Milestone B to support the MDA decision to enter detailed design.

For MDAPs programs, a PDR assessment is conducted and provided to the MDA. For ACAT ID programs, DASD(SE) conducts a PDR assessment to inform the MDA of technical risks and the program’s readiness to proceed into detailed design. For ACAT IC programs, the Component Acquisition Executive conducts the PDR assessment.

Any tailoring with respect to establishing an allocated baseline at PDR prior to Milestone B should be consistent with the approved Acquisition Strategy (AS) and documented in the Systems Engineering Plan (SEP). In a competitive environment, each developer should establish an allocated baseline to meet the definition prescribed in the RFP and associated system performance specification, consistent with their individual design approach. Since the functional and allocated baselines are critical to providing the Engineering and Manufacturing Development (EMD) bidders with a complete technical package, best practices dictate that the PDR be completed prior to the Development RFP Release Decision Point. The tailoring strategy may also include conduct of a delta-PDR after Milestone B if the allocated baseline has changed significantly.

A successful PDR confirms that the system’s preliminary design:

Satisfies the operational and suitability requirements of the validated CDD, as documented in the system performance specification.
Is affordable, producible, sustainable and carries an acceptable level of risk.
Is composed of technologies demonstrated in a relevant environment that can be integrated into a system with acceptable levels of risk.
Is complete and ready for detailed design.
Provides the technical basis for the Milestone B investment decision and Acquisition Program Baseline (APB).
Is fully captured and properly allocated in the specifications for each system element and all interface documentation (including system of systems (SoS) interdependencies).

The PDR establishes the allocated baseline, which is placed under formal configuration control at this point. The allocated baseline is complete when:

All system-level functional and interface requirements have been decomposed and allocated to the lowest level of the specification tree for all system elements (i.e., configuration item level).
All external interfaces to the system, as addressed at the System Requirements Review, have been documented in interface control documents.
All internal interfaces of the system (system element to system element) have been documented in interface control documents.
Verification requirements to demonstrate achievement of all specified allocated performance characteristics have been documented.
Design constraints have been captured and incorporated into the requirements and design.

Some of the benefits realized from a PDR with the attributes identified above would be to:

Establish the technical basis for the Cost Analysis Requirements Description (CARD), documenting all assumptions and rationale needed to support an accurate cost estimate for the APB; technically informed cost estimates enable better should-cost/will-cost management.
Establish the technical requirements for the detailed design, EMD contract specifications and Statement of Work (SOW).
Establish an accurate basis to quantify risk and identify opportunities.
Provide the technical foundation for 10 USC 2366b certification required for all MDAPs.

Some design decisions leading up to PDR may precipitate discussions with the operational requirements community because they could have an impact on the CDD. Depending upon the nature/urgency of the capability required and the current state of the technology, incremental development might be required. In this case the Sponsor should document these increments in the CDD and the PM and Systems Engineer should update relevant program plans.

Roles and Responsibilities

Reference Source: DAG CH 3-3.3.4 Preliminary Design Review

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

Though many Service systems commands or PEOs define the roles and responsibilities of the PM and Systems Engineer, the following notional duties and responsibilities should be considered:

The PM’s responsibilities include the following:

Approving, funding and staffing the system PDR as planned in the SEP developed by the Systems Engineer.
Establishing the plan to CDR in applicable contract documents including the SE Management Plan (SEMP), Integrated Master Schedule (IMS) and Integrated Master Plan (IMP).
Ensuring the SEP includes subject matter experts to participate in each review.
Controlling the configuration of the Government-controlled subset of the functional and allocated baselines; convene Configuration Steering Boards when changes are warranted.

The Systems Engineer’s responsibilities include the following:

Developing and executing the system PDR plans with established quantifiable review criteria, carefully tailored to satisfy program objectives.
Ensuring the pre-established PDR criteria have been met.
Providing industry with an opportunity to participate in this PDR planning (pre-contract award is a best practice, where applicable).
Ensuring 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).
Updating risk, issue and opportunity plans. Identifying, analyzing, mitigating, and monitoring risks and issues; and identifying, analyzing, managing and monitoring opportunities. (See the DoD Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs.) Monitor and control the execution of the PDR closure plans.
Documenting the plan to CDR in the SEP and elsewhere as appropriate.

Inputs and Outputs

Reference Source: DAG CH 3-3.3.4 Preliminary Design Review

The PDR review criteria are developed to best support the program’s technical scope and risk; they are documented in the program’s SEP no later than Milestone A. Table 31 identifies the products and associated review criteria normally seen as part of the PDR. The Chief Engineer should review this table and tailor the criteria for the program. The system-level PDR review should not begin until the criteria, identified by the Chief Engineer and documented in the SEP, are met and any prior technical reviews are complete and their action items closed. A resource for PDR preparation is IEEE 15288.2 “Standard for Technical Reviews and Audits on Defense Programs”. The PDR is a mandatory technical review.

Table 31: PDR Products and Criteria

Product	PDR Criteria
Cost Estimate	System cost model has been updated, allocated to lower system element levels and tracked against targets; production cost model constructed Updated CARD is consistent with the proposed allocated baseline
Risk Assessment	All risk assessments and risk mitigation plans have been updated, documented, formally addressed and implemented Approach/Strategy for test and evaluation defined in the Test and Evaluation Master Plan (TEMP) accounts for risks with a mitigation plan; necessary integration and test resources are documented within the TEMP and current availability align with the program IMS (SE coordinates with the Chief Developmental Tester in this area; refer to CH 8–4.2.) ESOH risks are known and being mitigated Risks are at an acceptable level to continue with detailed design Unique software risks identified/assessed and mitigation plans developed and implemented Risks associated with intelligence mission data (IMD) dependencies have been identified and addressed; refer to CH 3–4.3.12. Intelligence (Life-Cycle Mission Data Plan)
Technical Baseline Documentation (Allocated)	Capability Development Document (CDD) is validated per CJCSI 3170.01 Analysis of system performance is complete and assessed to meet requirements Preliminary design satisfies design considerations (see CH 3–4.2.2. Requirements Analysis Process) Producibility assessments of key technologies are complete Preliminary system-level design is producible and assessed to be within the production budget Assessment of the technical effort and design indicates potential for operational test and evaluation success (operationally effective and operationally suitable) All Critical Safety Items (CSIs) and Critical Application Items (CAIs) are identified Functional failure mode, effects and criticality analysis (FMECA) is completed Estimate of system reliability and maintainability updated, based on engineering analyses, initial test results, or other sources of demonstrated reliability and maintainability Computer system and software architecture designs have been established; all Computer Software Configuration Items (CSCIs), Computer Software Components (CSCs), and Computer Software Units (CSUs) have been defined Software Requirements Specifications (SRSs) and Interface Requirement Specifications (IRSs), including verification plans, are complete and baselined for all CSCs and satisfy the functional requirements Interface control documents trace all software interface requirements to the CSCIs and CSUs Preliminary software design has been defined and captured All required software-related documents are baselined and delivered Allocated baseline documentation is sufficiently complete and correct to enable detailed design to proceed with proper configuration management Preliminary design (hardware and software), including interface descriptions, is complete and satisfies all requirements in the functional baseline Requirements trace between functional and allocated baselines is complete and consistent
Technical Plans	All entry criteria stated in the contract (e.g., Statement of Work (SOW), SEP, approved SEMP and system performance specification) have been satisfied Integrating activities of any lower-level PDRs have occurred; identified issues are documented in action plans Plan to CDR is accurately documented in the SEP as well as the IMP and IMS Program is properly staffed Adequate processes and metrics are in place for the program to succeed Program schedule, as depicted in the updated IMS (See CH 3–4.1.1.2. Integrated Master Plan and CH 3–4.1.1.3. Integrated Master Schedule) is executable within acceptable technical and cost risks Program is executable with the existing budget and the approved product baseline Trade studies and system producibility assessments are under way Majority of manufacturing processes have been defined, characterized, and documented Logistics (sustainment) and training systems planning and documentation are sufficiently complete to support the review Life Cycle Sustainment Plan (LCSP) is approved, including updates on program sustainment development efforts and schedules based on current budgets and firm supportability design features Information Support Plan (ISP) is drafted and scheduled for formal review prior to Milestone B LCSP includes software support requirements Long-lead and key supply chain elements are identified Computer system and software design/development approach have been confirmed through analyses, demonstrations, and prototyping in a relevant environment Software increments have been defined and capabilities allocated to specific increments Software trade studies addressing commercial-off-the-shelf, reuse, and other software-related issues are completed Software development process is defined in a baselined Software Development Plan and reflected in the IMP and IMS Software development schedules reflect contractor software processes and IMP/IMS software events for current and future development phases Software development environment and test/integration labs have been established with sufficient fidelity and capacity Software metrics have been defined and a reporting process has been implemented; metrics are being actively tracked and assessed The TEMP documents the overall structure and objectives of the Test and Evaluation program and articulates the necessary resources to accomplish each phase of test. It provides a framework within which to generate detailed T&E plans and documents schedule and resource implications associated with the T&E program Software development estimates (i.e., size, effort (cost), and schedule) are updated

Outputs and Products

Reference Source: DAG CH 3-3.3.4 Preliminary Design Review

The Technical Review Chair determines when the review is complete. Completion of the PDR establishes that:

The allocated baseline has been established and placed under configuration control.
Technical data for the preliminary design are complete, satisfy the system performance specification and provide a sufficient foundation for detailed design to proceed.
Risks have been assessed and are acceptable, with any risk mitigation plans approved and documented in the IMS.
Feasibility, cost and schedule are determined to be within acceptable risk margins.
IMS is updated (including systems and software critical path drivers) and includes all activities required to complete CDR (assuming same developer responsible for PDR and CDR).
Corrective action plans for issues identified in the PDR have been completed.
CARD is updated and reflects the design in the allocated baseline.
LCSP is updated to reflect development efforts and schedules.

PDR Assessment

Reference Source: DAG CH 3-3.3.4 Preliminary Design Review

A system-level PDR assessment is required for MDAPs. This assessment informs the MDA of the technical risks and the program’s readiness to proceed into detailed design, supporting the Milestone B decision point and, for MDAPS only, 10 USC 2366b Milestone B certification. The Deputy Assistant Secretary of Defense for Systems Engineering (DASD(SE)) conducts PDR assessments on ACAT ID programs, and the Component Acquisition Executive (CAE) conducts the PDR assessments on ACAT IC programs. In support of this, MDAP PMs are required to invite the DASD(SE) and the CAE to their PDRs and make the PDR artifacts available.

DASD(SE) reviews the conduct of the program’s PDR, to include system element-level reviews as appropriate, and provides the MDA with an assessment of the following:

The conduct and adequacy of the PDR to include the participation of stakeholders, technical authorities and subject matter experts; status of the PDR entrance and exit criteria; open Requests for Action/Information; and closure of the system element and system-level reviews.
The program technical schedule and schedule risk assessments.
The program’s risks, issues and opportunities.
The establishment and configuration control of the allocated baseline as demonstrated by the completion of the development specifications for each Configuration Item (CI); internal and external interface control documents; design constraints incorporated into the requirements and design; and system, system elements and CI verification plans.
The conduct and results of any prototyping and trade studies conducted to reduce technical risk, validate design and assess integration.
The preliminary design’s ability to meet KPP, KSA and TPM thresholds and the proposed corrective actions to address any performance gaps, as appropriate.
Key Systems Engineering design considerations.

T&E Considerations

Reference Source: DAG CH 8-3.8.2 Preliminary Design Review

The PDR should provide sufficient confidence to proceed with detailed design. It ensures the preliminary design and basic system architecture are complete, that there is technical confidence the capability need can be satisfied within cost and schedule goals, and that risks have been identified and mitigation plans established. The PDR provides the acquisition community, end user, and other stakeholders with an opportunity to understand the trade studies conducted during the preliminary design, and thus confirm that design decisions are consistent with the user’s performance and schedule needs prior to formal validation of the Capability Development Document (CDD). The PDR also establishes the allocated baseline.

The PM supports T&E planning by finalizing sustainment requirements to support the PDR. The Chief Developmental Tester and the Lead DT&E Organization participate in the PDR and provide any analysis and assessments to date, as needed. During the TMRR Phase, and unless waived by the MDA, a PDR is conducted so it occurs before Milestone B and prior to contract award for EMD. The results from the PDR are used to help define entrance criteria for Milestone B and support the Development RFP Release Decision.

Sustainment Considerations

Reference Source: DAG CH 4-3.2.2.3 Preliminary Design Review

As part of the Preliminary Design Review (PDR), the PM ensures that all sustainment requirements have been analyzed, decomposed, allocated to Configuration Items, and captured in program documentation. Allocated sustainment requirements should have full traceability back to the system performance specification, the RAM-C Rationale, and the CDD. The PM also ensures that the specified sustainment capabilities and requirements are achievable in the system preliminary design as defined in the Configuration Items specifications. Additionally, the PM assesses the preliminary design from a sustainment perspective and identifies risks that may affect 10 USC 2366b (see US Code) certification, the program/system detail design in EMD, Product Support Package preliminary design, and the Milestone B decision.

The PM needs to ensure the PDR includes all R&M thresholds from the CDD. The design now includes derived requirements that support maintainability (such as Built-in-Test, capability fault detection, and false alarm rate). Throughout TMRR, the PM encourages design trades to support Condition Based Maintenance Plus. These prognostic and fault detection capabilities are justified by their contribution to meeting availability and maintainability. As part of the software development strategy requirements, the PM identifies documentation required for software sustainment (either commercial or organic).