Preliminary Design Review: PDR Entrance Criteria Guide

Hardware programs routinely confuse a preliminary design review with an informal CAD show-and-tell. Engineering teams assemble slide decks full of rendered solid models, preliminary finite element plots, and rough wiring schematics, then wonder why the review turns into an open-ended debate about bracket geometry or connector placement. A real preliminary design review doesn't exist to show off work from early concept sprints.

A preliminary design review gates a specific contractual and architectural boundary: the move from top-level system requirements to an allocated preliminary design baseline. Before you open the meeting or send packages to independent board members, set clear entrance criteria. You need a stable functional architecture, documented flowdown of requirements to subsystem owners, verified engineering margins, and an agreed verification approach for every specification.

This guide covers the entrance criteria, board management practices, and baseline controls hardware teams need to run a defensible preliminary design review. Treat the milestone as a strict baseline audit, not a presentation, and you'll clear the gate with manageable action items and keep momentum into detailed design.

Step 1: Define what the PDR gates: the allocated baseline and the preliminary design

A preliminary design review gates the allocated baseline. The NASA systems engineering handbook (NASA SP-2016-6105, 2016) defines this milestone as demonstrating that the preliminary design meets all system requirements with acceptable risk and within cost and schedule constraints, with the allocated baseline typically established upon its successful completion. It asks whether the design approach is mature enough to proceed into detailed design, long-lead procurement, and production planning.

The review does not gate finished engineering drawings or fully toleranced manufacturing prints. That's the job of the Critical Design Review. The preliminary design review establishes that the system architecture is partitioned correctly, every parent requirement has a technical home, and the chosen mechanical, electrical, and thermal concepts can physically meet their operational targets.

To set this gate, define the exact artifacts that form the allocated baseline. These include subsystem requirement specifications, preliminary layout assemblies in your primary CAD environment, functional schematics, initial software architectures, and early interface definitions. If the team can't produce an itemized list of these configuration items before the meeting, the program hasn't reached the threshold for a preliminary design review.

Treat the review as an architectural gate and the team focuses on closure, not aesthetics. Reviewers shouldn't debate cosmetic fillet radii or bolt sizes. The board must decide whether the proposed architecture satisfies system functions without violating thermal envelopes, power reserves, mass budgets, or development schedules.

Step 2: Confirm requirements are flowed down to subsystems and traceable

You can't pass a preliminary design review if subsystem requirements exist in isolation. The second entrance criterion is complete, bi-directional traceability from the system requirements baseline down to individual assemblies and parts. Every subsystem parameter must cite a parent requirement, and every parent specification must be covered by child requirements.

Orphaned requirements cost money. When a team designs a complex enclosure feature or writes a firmware routine with no parent requirement, they spend program capital on unverified features. Parent requirements with no downstream children leave system functionality unaddressed until physical integration. Formal requirements flowdown prevents both failure modes.

Hardware teams using Tandem build this linkage through visual subsystem architectures and structured requirement tables where parent-child relationships, technical owners, and approval statuses stay visible across disciplines. When mechanical engineers modify an assembly in SolidWorks or NX, the underlying systems engineering relationships show which functional specifications the change touches.

Traceability must also capture design rationale. If a structural requirement mandates an anodized exterior finish, the allocated specification must say whether that finish serves corrosion resistance, emissivity targets for radiative cooling, or electrical grounding standards. Reviewers need to see the justification for derived values before they can endorse the baseline.

Step 3: Show the preliminary design meets allocated requirements, with margins and risks assessed

A preliminary design package must show, through analysis, modeling, or physical breadboard testing, that the hardware architecture actually meets its allocated limits. Subjective claims of confidence carry no weight at the review board. The package must present quantitative engineering margins alongside an updated risk register.

Technical resource budgets are the core evidence here. Your package must track mass, peak and average power consumption, thermal dissipation, memory footprint, data bus bandwidth, and structural margins of safety. Aerospace and defense programs often apply margin standards (AIAA S-120A, 2015), which determine mass growth allowances based on hardware category and design maturity rather than a blanket percentage. If your battery capacity or thermal radiator size is already at ninety-five percent utilization before detailed design begins, the architecture has failed its preliminary design review entrance criteria.

Pair these budgets with a preliminary failure mode analysis and an active risk register. The design team must present initial failure mode mitigations that point to specific architectural decisions isolating single-point failures. If a high-voltage battery pack relies on liquid cooling, the package must document leak containment, venting pathways, and thermal runaway isolation.

For each technical risk, define the planned burn-down trajectory. A risk item with no prototype test date or simulation schedule is an unmanaged liability. Board members will reject packages that list critical thermal or structural risks without showing how the team plans to retire them before the critical design milestone.

Step 4: Identify interfaces and state the verification approach for each requirement

Subsystems fail at their boundaries. Mechanical mountings misalign, electrical pinouts flip, and communication protocols drop packets when interfaces get treated as secondary concerns. Every preliminary design review needs all internal and external boundaries documented through a formal interface control document before it starts.

The preliminary design package must describe mechanical physical envelopes, bolt patterns, connector part numbers, pin assignments, operating voltages, signal baud rates, and fluid flow rates. Each interface parameter needs a named engineer on both sides of the boundary who has signed off on the agreed definition. Review boards must refuse to approve baselines with undefined or unowned connections.

The team must also present an initial verification matrix. It isn't enough to state what the preliminary design must achieve. You have to define how the team will prove compliance during qualification. Each requirement in the allocated baseline gets a primary verification method: analysis, inspection, demonstration, or physical testing.

For requirements verified by testing, the package must describe the test environment, required test equipment, and special support facilities. If a structural requirement demands shake testing at extreme temperatures, the verification matrix must confirm that an environmental chamber of adequate size and thermal ramp rate is scheduled and budgeted. Naming test methods early prevents budget shocks when qualification begins.

Step 5: Agree the review plan, success criteria and board instructions before the meeting

A productive preliminary design review needs governance set weeks before the opening slide. Engineering leadership must publish the review plan, set clear pass or fail criteria, and give board members explicit terms of reference.

The review board must include independent technical experts who don't report to the program manager or lead subsystem engineers. You need an objective perspective. Manufacturing engineers must assess whether the preliminary geometry can be fabricated and assembled with standard tooling. Quality engineers must check inspection accessibility, and reliability engineers must review component derating and wearout mechanisms. Systems engineering leads check coherence across mechanical, electrical, and software disciplines.

Distribute the review package at least one to two weeks in advance. Reviewers who have to digest stress hand calculations, circuit diagrams, and requirements matrices in real time give superficial feedback. Instruct board members to submit written comments and discrepancy reports before the formal meeting opens.

Set binary success criteria for the gate. The board assesses three conditions: the design satisfies allocated requirements with acceptable margin, risks are identified with credible retirement paths, and interfaces are defined and mutually agreed. If the package misses any of the three, the board must not grant an unconditional pass.

Step 6: Set exit criteria and close action items against the baseline

The review meeting doesn't conclude the milestone. The process only finishes when the board dispositions all submitted Requests for Action (RFAs) and Discrepancy Reports (DRs), which sets the official exit criteria for the gate.

Sort action items into distinct severity classes. Category one items are architectural blockers: negative structural margins, unallocated power draws, missing interface definitions, or inadequate thermal rejection capacity. Category two items are localized adjustments: drawing cleanup, minor tolerance refinements, or updated component obsolescence reviews. The program can't exit the preliminary design review gate until every category one action item is closed or converted into an engineering change order with an approved, funded closure plan.

Close action items against configuration items within the baseline, not in email threads or chat rooms. If a reviewer flags an overstressed structural bracket, the resolution can't just say the stress came up in a hallway meeting. The closure must link directly to an updated finite element run, a revision to the CAD part, and a verified update to the system mass budget.

Tandem helps engineering leads here by anchoring review discussions, comments, and action items directly to the relevant requirement, architecture node, or CAD revision. It keeps that context across tools like Onshape, Fusion, and SolidWorks, so teams can track why a revision was made and prove closure to the board without piecing together fragmented notes.

Step 7: Keep the PDR record usable as the design changes toward CDR

Passing the preliminary design review creates the allocated configuration baseline. Hardware programs most often fail in the weeks after the review, when detail design speeds up and changes start eroding baseline decisions. As the team moves toward the critical design review package, design changes made in CAD must stay tied to the approved review record.

Mechanical engineers modify wall thicknesses, reroute wire harnesses, or swap fasteners to cut unit cost, and each adjustment alters the technical budgets set at PDR. A two-millimeter shift in a structural rib might fix a local stiffness problem while intruding on an electronics clearance envelope or adding unexpected mass.

Keep configuration management over the baseline with formal change evaluations. Check every proposed modification against child requirements, parent allocations, interface control documents, and verification plans. If an engineering change affects an approved interface or alters a technical resource reserve, the systems engineer and affected subsystem leads must review the impact before anyone updates the CAD model.

Preserving design intent takes persistent links between geometry and requirements. Tandem monitors linked CAD changes across platforms like NX and SolidWorks and alerts teams when geometric updates hit allocated requirements or technical budgets. That continuous context layer prevents the quiet drift that sends teams into weeks of documentation archaeology before their next major milestone.

What to do next: hand the PDR baseline to CDR, plus troubleshooting a PDR that stalls

Once the board approves baseline closure, publish the allocated baseline formally. Archive the review minutes, signed action item dispositions, interface control documents, and technical budget snapshots. Hand these records to subsystem leads as the authoritative design constraints for the detailed design phase leading to CDR.

If your preliminary design review stalls, the diagnosis is usually simple. Reviews stall for three predictable reasons:

1. Incomplete requirements flowdown: When subsystem leads disagree on ownership during the meeting, pause the review. Don't negotiate system architecture in front of an external board. Adjourn the session, convene subsystem leads, reallocate requirements, and reconvene within two weeks.

2. Negative resource margins: If structural, power, or thermal margins are negative, the baseline is unviable. Don't award a conditional pass. Have the engineering team run targeted trade studies or de-scope secondary requirements to restore positive margins before re-auditing the gate.

3. Missing interface agreements: If two mating assemblies belong to teams with conflicting interface definitions, assign a dedicated systems engineer to reconcile the boundary. Require signed interface agreements before the board reconvenes.

Treat the preliminary design review as a strict baseline audit and your team advances into detailed design on solid technical ground, with the schedule and engineering budget intact.

Conclusion

A preliminary design review is an architectural commitment, not an informal engineering presentation. Enforce rigorous entrance criteria, build bi-directional requirements flowdown, and verify positive technical margins, and the gate speeds the program up instead of slowing it down.

The connection between requirements, CAD changes, and verification evidence is where traditional hardware workflows break down between PDR and CDR. Tandem provides the systems engineering context layer that links your CAD models in SolidWorks, Onshape, Fusion, and NX directly to allocated requirements and technical budgets. See how Tandem keeps your design intent intact and audit-ready from early architecture through detailed release.