Preliminary Design Review (PDR)

A Preliminary Design Review (PDR) is a formal technical review that evaluates whether a system's preliminary design is sufficiently mature, requirements-compliant, and risk-informed to authorize the transition to detailed design, and formally establishes the Allocated Baseline for the program.

What is a Preliminary Design Review?

The PDR is the second major technical review in the DoD acquisition process, following the System Requirements Review. It occurs at the end of the preliminary design phase, when the contractor has allocated top-level requirements to subsystems, identified the system's physical and functional architecture, established key interfaces, and demonstrated through analysis and preliminary testing that the design approach is technically feasible.

PDR success criteria typically include: all system requirements allocated to one or more subsystems, subsystem interfaces documented in Interface Control Documents (ICDs), Technical Performance Measures tracked against threshold values with no unacceptable risks, technology maturity at TRL 5 or above for key enabling technologies, no open requirements with no identified design solution, and the allocated baseline ready for government approval.

The Allocated Baseline, which flows requirements down from the system level to each subsystem and component, is formally established at or shortly after a successful PDR. This baseline controls the scope of detailed design work leading to the Critical Design Review. Cost and schedule estimates are also updated at PDR, often triggering a formal Defense Acquisition Board review if the PDR reveals cost growth beyond the Acquisition Program Baseline.

Why the PDR matters for government contractors

A successful PDR is a major program milestone that typically triggers significant contract funding releases for the detailed design phase. Contractors who enter the PDR unprepared, with unresolved interface issues, TPMs tracking below threshold, or TRL gaps in key technologies, face delays, additional government scrutiny, and the risk of program restructuring.

Example

A satellite communications contractor's PDR reveals that the antenna subsystem's link budget analysis shows only 0.3 dB of margin against the specified 1.0 dB minimum at the program's key performance parameter. The PDR identifies this as a critical technical risk. Rather than waiting for CDR, the engineering team immediately initiates a trade study between a larger antenna aperture (adding mass and cost) and a higher-power amplifier (adding power consumption). The resolution drives a requirements change that is processed through the formal change control process before detailed design begins.

Frequently Asked Questions

What level of design detail is expected at a PDR?

PDR represents approximately 15-35% design completion. The architecture is established, requirements are allocated, key trades are complete, and major interfaces are identified. Full component drawings and specifications are not required, those are CDR-level products. The PDR should demonstrate that the chosen architecture is feasible and that all requirements can be met.

What is the Allocated Baseline and why is it important?

The Allocated Baseline documents how top-level system requirements are distributed to subsystems and components. Once approved at PDR, changes to the allocated baseline require formal Engineering Change Proposals. It provides the technical contract between the system level and each subsystem design team, preventing scope ambiguity during detailed design.

How does PDR differ from CDR?

PDR evaluates the preliminary design, architecture, approach, and feasibility. CDR evaluates the detailed design, complete drawings, specifications, and analyses demonstrating that the as-designed system will meet all requirements. PDR establishes the Allocated Baseline; CDR establishes the Product Baseline.

What happens if the PDR reveals that a key technology is not mature enough?

If a key enabling technology is below TRL 5 at PDR, the government and contractor must either accept the risk and continue, restructure the design to use a more mature technology, or extend the TMRR phase to mature the technology before entering EMD. Technology maturity gaps discovered at PDR are one of the most common causes of program restructuring and cost growth.