Preliminary Design Review (PDR)
The PDR assesses the maturity of the preliminary design supported by the results of requirements trades, prototyping, and critical technology demonstrations. The PDR will establish the allocated baseline and confirm that the system under review is ready to proceed into detailed design (development of build-to drawings, software code-to documentation, and other fabrication documentation) with acceptable risk.
The text below is from the 2022 DoD Systems Engineering (SE) Guidebook, Section 3.4 Preliminary Design Review, amended with updated 10 USC code number and acronyms spelled out when first used.
The Preliminary Design Review (PDR) should provide sufficient confidence to proceed with detailed design. The PDR determines whether 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 applicable requirements documents. 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 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) (see DoD SE Guidebook, Section 4.1.6, Configuration Management Process).
The PDR is mandatory per DoDI 5000.88, Section 3.5.a. The timing of the review should consider the following:
- For all AAF pathway programs that are classified as Major Defense Acquisition Programs (MDAPs), 10 U.S.C. 4252 requires the MDA certify all MDAPs at Milestone B. This certification requires the conduct and assessment of a PDR, unless waived for national security reasons.
- The timing of the 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.
Any tailoring with respect to establishing an allocated baseline at PDR 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 system development bidders with a complete technical package, best practices dictate that the PDR be completed before the Development RFP Release Decision Point. The tailoring strategy may also include conduct of a delta-PDR after contract award 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 Capability Development Document (CDD), as documented in the system performance specification.
- Is affordable, testable, 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 investment decisions and establishing the 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:
- 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). External interfaces to the system, as addressed at the System Requirements Review (SRR), have been documented in Interface Control Documents.
- Internal interfaces of the system (system element to system element) have been appropriately documented IAW the program’s Modular Open System Approach (MOSA) strategy. Verification requirements to demonstrate achievement of all specified allocated performance characteristics have been documented.
- Design and Safety 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, contract specifications and Statement of Work (SOW).
- Establish an accurate basis to quantify risk and identify opportunities.
- Provide the technical foundation for 10 USC 4252 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, contributing to trade-off analyses. 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, Systems Engineer, and Lead Software Engineer should update relevant program plans.
Roles and Responsibilities
The PM, Systems Engineer, and Lead Software 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, Systems Engineer, and Lead Software 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 Program Executive Offices (PEOs) define the roles and responsibilities of the PM, Systems Engineer, and Lead Software 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 Critical Design Review (CDR) in applicable contract documents including the Systems Engineering Management Plan (SEMP), Integrated Master Schedule (IMS), and Integrated Master Plan (IMP).
- Ensuring the SEP includes Subject Matter Experts (SMEs) to participate in each review.
- Reviewing and approving trade-off analyses with SMEs to address design decisions or Analyses of Alternatives (AoAs).
- 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 analyses, assessments, and risks associated with all design constraints and considerations are conducted, documented, and provided (e.g., Human System Integration (HSI), reliability and maintainability, corrosion, system safety (SS), survivability, and Environment, Safety, and Occupational Health (ESOH) considerations).
- Updating Risk, Issue, and Opportunity (RIO) 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 Review Criteria
The PDR criteria are developed to best support the program’s technical scope and risk and are documented in the program’s SEP. Table 3-4 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 3-4. PDR Products and Criteria
Product |
Preliminary Design Review (PDR) Criteria |
Cost Estimate |
|
Risk Assessment |
|
Technical Baseline Documentation/Digital Artifacts (Allocated) |
|
Technical Plans |
|
Outputs and Products
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.
- The Independent Cost Estimate (ICE) (includes CARD) is updated and reflects the design in the allocated baseline.
- The LCSP is updated to reflect development efforts and schedules.