U.S. flag

An official website of the United States government

Dot gov

Official websites use .gov
A .gov website belongs to an official government organization in the United States.


Secure .gov websites use HTTPS
A lock () or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.


  1. Home
  2. Preliminary Design Review (PDR)

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. For MDAPs and MAIS programs, a system-level PDR assessment will be conducted and provided to the MDA. For Acquisition Category (ACAT) ID and ACAT IAM programs, DASD(SE) will conduct the PDR assessment to inform the MDA of technical risks and the program's readiness to proceed into detailed design. The Program Manager will make the program information needed for this assessment available and provide for DASD(SE) participation in the program's PDR process. For ACAT IC and ACAT IAC programs, the Component Acquisition Executive (CAE) will conduct the PDR assessment.

Alternate Definition

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.

General Information

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


Preliminary Design Review (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 Cost Analysis Requirements Description (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 (T&E) defined in the Test and Evaluation Master Plan (TEMP) accounts for risks (e.g., system safety (SS) risks assessments) with a mitigation plan; necessary integration and test resources are documented within the TEMP and current availability align with the program Integrated Master Schedule (IMS) (SE coordinates with the Chief Developmental Tester in this area; refer to T&E Enterprise Guidebook (forthcoming))
  • Human systems integration (HSI) and environment, safety, and occupational health (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
  • Updated Mission-Based Cyber Risk Assessment, and cybersecurity risks are documented
  • Diminishing manufacturing sources and material shortages (DMSMS) risks are being evaluated through health assessments and significant risks are being mitigated
  • Risks associated with intelligence mission data (IMD) dependencies have been identified and addressed; see Section 5.11 Intelligence (Life Cycle Mission Data Plan)
Technical Baseline Documentation/Digital Artifacts (Allocated)
  • Capability Development Document (CDD) is validated per CJCSI 5123.01
  • Analysis of system performance is complete and assessed to meet requirements
  • Preliminary design satisfies design considerations (see DoD SE Guidebook, Section 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 (OT&E) success (operationally effective and operationally suitable)
  • System Safety (SS) Engineering Program has been developed.
  • Hazard Analyses of the Hardware and Software (e.g., System Requirements Hazard Analysis, Preliminary Hazard Analysis, Functional Hazard Analysis, Systems-of-Systems Hazard Analysis, etc.) including analysis of technological advances such as autonomy and artificial intelligence are conducted.
  • Safety risk management and risk assessments are conducted.
  • Document hazards in the Hazard Tracking System (HTS)
  • All Critical Safety Items (CSIs) and Critical Application Items (CAIs) are identified
  • Functional failure mode, effects, and criticality analysis (FMECA) and human reliability analyses are complete
  • 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 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 Computer Software Unit’s 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 (e.g., human-machine interface (HMI)), is complete and satisfies all requirements in the functional baseline
  • Requirements trace between functional and allocated baselines is complete and consistent
  • Parts lists have been evaluated for compliance with the Parts Management plan
Technical Plans
  • All entrance criteria stated in the contract (e.g., Statement of Work (SOW), Systems Engineering Plan (SEP), approved Systems Engineering Plan (SEMP), and system performance specification) have been satisfied
  • Technical plans documented in the SEP and any additional plans for appropriate design considerations (e.g. reliability and maintainability (R&M), cybersecurity, ESOH, manufacturing, HSI)
  • DMSMS Management Plan in place and being applied to mitigate DMSMS risk in preliminary designs
  • 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 Integrated Master Plan (IMP) and Integrated Master Schedule (IMS)
  • Program is properly staffed
  • Stakeholders are able to access needed data within the digital engineering ecosystem to make informed decisions
  • Adequate processes and metrics are in place for the program to succeed
  • Program schedule, as depicted in the updated IMS (See DoD SE Guidebook, Section 4.1.1) 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
  • 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 SDP 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 tracked and assessed, and stakeholders can access the metrics within the digital ecosystem
  • The TEMP is drafted, documenting the overall structure and objectives of the T&E program and articulates the necessary resources to accomplish each phase of test. It provides a framework within which to generate detailed T&E plans (hardware and software) and documents schedule and resource implications associated with the T&E program
  • Update the Program Protection Plan when preliminary design activities result in new program scope, design, threats, vulnerabilities or protection needs
  • Software development estimates (i.e., size, effort (cost), and schedule) are updated

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.