The Preliminary Design Review (PDR) is a technical assessment that establishes the Allocated Baseline of a system to ensure a system is operationally effective. A PDR is conducted before the start of detailed design work and is the first opportunity for the Government to closely observe the Contractor’s hardware and software design. 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.
Definition: The Preliminary Design Review (PDR) is a review conducted to evaluate the progress, technical adequacy, and risk resolution of the selected design approach for one or more configuration items; to determine each design’s compatibility with the requirements for the configuration item; to evaluate the degree of definition and assess the technical risk associated with the selected manufacturing methods and processes; to establish the existence and compatibility of the physical and functional interfaces among the configuration items and other items of equipment, facilities, software and personnel; and, as applicable, to evaluate the preliminary operational and support documents. – ISO/IEC/IEEE. 2009. Systems and Software Engineering – System and Software Engineering Vocabulary (SEVocab).
Purpose of the Preliminary Design Review (PDR)
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.
Fact Sheet: Preliminary Design Review (PDR) Fact Sheet
When to conduct a Preliminary Design Review (PDR) [1]
The PDR should be conducted when the allocated baseline has been achieved, allowing the detailed design of hardware and software CIs to proceed. A rule of thumb is that 10 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.
The PDR should be conducted 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 before detailed design begins. [1]
A PDR may be conducted incrementally for complex systems 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 but not assured. Interface requirements make up each configuration item Allocated Specification.
Successful completion of the PDR should provide the following:
- An established system allocated baseline,
- An updated risk assessment for the Engineering, Manufacturing, and Development (EMD) Phase,
- An updated Cost Analysis Requirements Description (CARD) or CARD-like document based on the system-allocated baseline,
- An updated program schedule, including system and software critical path drivers, and
- An approved Life-Cycle Sustainment Plan (LCSP) updating program sustainment development efforts and schedules.
A successful PDR is predicated on the determination that the subsystem requirements, preliminary subsystem design, results of peer reviews, and plans for development, testing, and evaluation form a satisfactory basis for proceeding into detailed design and test procedure development. [1]
Preliminary Design Review (PDR) Roles and Responsibilities
When thinking about the roles and responsibilities of the Program Manager (PM) and Systems Engineer, the following tasks and roles should be taken into account when conducting a PDR:
The following are some of the Program Manager’s duties:
- Approve, pay, and hire people for the system PDR as planned in the Systems Engineer’s SEP.
- Setting up the plan to CDR in the SE Management Plan (SEMP), Integrated Master Schedule (IMS), and Integrated Master Plan (IMP), which are all part of the deal.
- Making sure that the SEP includes experts in the field in each study.
- Control the configuration of the subset of the functional and assigned baselines the government controls. Hold Configuration Steering Board meetings when changes are needed.
The following are some of the things the Systems Engineer is responsible for:
- Creating and carrying out system PDR plans with clear, measurable review criteria carefully designed to meet program goals.
- Making sure that the PDR standards that have already been set have been met.
- Giving the industry a chance to participate in this PDR planning (where possible, pre-contract award is a best practice).
- Making sure that assessments and risks related to all design constraints and considerations (like reliability and maintainability, corrosion, and Environment, Safety, and Occupational Health (ESOH) factors) are done, written down, and given.
- Plans for risk, issue, and chance are being updated. Identifying, mitigating, and monitoring risks and problems; and identifying, analyzing, managing and tracking opportunities.
The Weapons System Acquisition Reform Act of 2009 directed the PDR to:
- PDRs before Milestone (MS) B is 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.
Difference Between Preliminary Design Review (PDR) and Critical Design (CDR) Review
A Preliminary Design Review (PDR) is conducted to ensure new technologies are mature enough to be integrated into a product subsystem to form its allocated baseline. A Critical Design Review (CDR) is focused on determining if a system can meet its stated performance requirements within cost, schedule, and risk.
AcqNotes Tutorial
AcqTips:
- The Program Manager (PM) should conduct the PDR when all major design issues have been resolved and work can begin on the detailed design. The PDR should address and resolve critical, system-wide issues.
- IEEE 5288.2 “Standard for Technical Reviews and Audits on Defense Programs” is the standard for technical reviews and audits to be performed throughout the acquisition life cycle for the US Department of Defense (DoD) and other defense agencies. This standard guides the DoD and contractor on what is required during an SRR
- The PDR should be conducted when the allocated baseline has been achieved, allowing the 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:
- Defense Acquisition Guidebook
- [1] Preliminary Design Review (PDR) Fact Sheet
- Preliminary Design Review Checklist – Jan 2015
- PDR Risk Assessment Checklist – 18 April 2013
- NAVAIR Instruction 4355.19D – Systems Engineering Technical Review
- OSD Guide to Best Practices Using Engineering Standards – April 2017
Updated: 6/9/2023
Rank: G2.9
