4.2.12. Preliminary Design Review

DEFENSE ACQUISITION GUIDEBOOK
Chapter 4 -- Systems Engineering

4.2.12. Preliminary Design Review

4.2.12. Preliminary Design Review

The Preliminary Design Review (PDR) ensures the preliminary design and basic system architecture are complete, and that there is technical confidence the capability need can be satisfied within cost and schedule goals. 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 system’s allocated baseline.

The allocated baseline describes the functional and interface characteristics for all system elements (allocated and derived from the higher-level product structure hierarchy) and the verification required to demonstrate achievement of those specified characteristics. The allocated baseline for each lower-level system element (hardware and software) is usually established and put under configuration control at the system element Preliminary Design Review (PDR). This process is repeated for each system element and culminates in the Program Manager establishing the complete allocated baseline at the system-level PDR. The Program Manager then verifies the allocated baseline at the Functional Configuration Audit (FCA) and/or System Verification Review (SVR) (see DAG section 4.3.7 Configuration Management Process).

The PDR is mandatory. According to DoD policy and guidance, PDR requirements include the following:

• PDR is completed prior to Milestone B for all Major Defense Acquisition Programs (MDAPs) (DTM 09-027)
• Component Acquisition Executive determines the timing of PDR relative to the Pre-Engineering and Manufacturing Development (EMD) review (DTM 09-027 and PDUSD(AT&L) memorandum, “Improving Milestone Process Effectiveness”)
• PDR Report is provided to the Milestone Decision Authority (MDA) prior to the Post-PDR Assessment and should reflect any requirements trades based upon the Program Manager’s assessment of cost, schedule, and performance risk (DoDI 5000.02)
• PDR Report should follow the PDR Report template which prescribes the content and responsibilities associated with all PDR completion memos

Any tailoring with respect to establishing an allocated baseline at PDR prior to Milestone B should be consistent with the approved Technology Development Strategy (TDS) 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 Request for Proposal (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 would dictate that the PDR be completed prior to the pre-EMD Review, although this timing is optional under policy. 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 draft 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 in the specifications for each system element and all interface documentation (including system of systems (SoS) interdependencies)

In addition, the PDR represents agreement that the proposed plan to proceed to the Critical Design Review (CDR) is executable and properly resourced. The PDR establishes the allocated baseline, which is placed under formal configuration control at this point. The maximum benefit of the PDR process is realized when the allocated baseline is complete with the following attributes:

• All system-level functional performance requirements have been decomposed (or directly allocated) to the lowest level of the specification tree for all system elements uniquely identified
• 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; inform the CDD
• Establish an accurate basis to quantify risk and identify opportunities
• Provide core evidence for the PDR Report
• Provide the technical foundation for section 2366b of title 10, United States Code certification required for all MDAPs

Some design decisions made at 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 Program Manager and Systems Engineer should update relevant program plans.

Roles and Responsibilities

The Program Manager 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 Program Manager and Systems Engineer evaluate the 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.

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

The Program Manager’s responsibilities include the following:

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

The Systems Engineer’s responsibilities include the following:

• Develop and execute the system PDR plans with established quantifiable review criteria, carefully tailored to satisfy program objectives
• Ensure that the pre-established PDR criteria have been met
• Provide industry with an opportunity to participate in this PDR planning (pre-contract award is a best practice, where applicable)
• Support development of the PDR Report
• 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 PDR closure plans
• Document the plan to CDR in the SEP and elsewhere as appropriate

Inputs and Review Criteria

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

Figure 4.2.12.F1. Weapon System Development Life Cycle

The PDR 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 A. Table 4.2.12.T1 defines the products and associated review criteria. The system-level PDR 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 PDR preparation is the DoD PDR Checklist. The PDR is a mandatory technical review.

Table 4.2.12.T1. PDR Products and Criteria

Outputs and Products

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

• Technical data for the allocated baseline are complete, satisfy the system specification, and provide a sufficient foundation for detailed design to proceed
• Risks have been balanced 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

Top of page