← All posts

Engineering Design Review: What to Check and How to Document It

A practical guide to running engineering design reviews — what to check at each stage, how to structure the review, what documentation to produce, and the common failure modes that make design reviews ineffective.

Engineering Design Review: What to Check and How to Document It

Most engineering teams have a design review process. Few run it well.

The gap between a useful design review and a box-ticking exercise is mostly a matter of structure. When a design review has no defined checklist, no clear pass/fail criteria, and no required outputs, it becomes a room full of engineers looking at CAD and saying things like "looks fine to me" or "we should probably check the tolerances at some point."

When a design review is structured — with a specific agenda, defined criteria for each stage, and required documentation before a design can advance — it catches problems early, creates a record of the decisions made, and prevents the same mistakes from recurring across projects.

This guide covers what an effective engineering design review looks like at each stage of the product development cycle, what to specifically check, and how to document it so the review actually produces usable output.

Why Design Reviews Fail

Before covering what a good design review looks like, it helps to understand why they fail. The common patterns are:

No pre-work required. If the presenting engineer does not need to submit anything before the review — no drawing package, no FMEA, no tolerance analysis — the review defaults to improvised discussion. Reviewers cannot prepare, so they react to whatever is presented rather than checking against defined criteria.

Wrong people in the room. A design review that only includes the design team is missing manufacturing, quality, and service perspective. Problems that are obvious to a manufacturing engineer looking at a drawing are invisible to a product engineer who has been looking at the CAD model for three months.

No authority to halt the design. If the design review is advisory — if the design can advance regardless of what is found — then reviewers have no incentive to dig hard. The review becomes a formality.

Actions not tracked. When a review produces a list of concerns that go into a shared document nobody checks again, the review produced nothing. Action items need owners and due dates.

Too late in the process. Design reviews done after the design is essentially finalised are expensive to act on. The review confirms what is already built rather than shaping what gets built.

The Three Core Design Review Stages

Most product development programmes use three formal design review gates, each serving a different purpose:

1. Concept Design Review (CDR)

Purpose: Confirm that the selected concept meets requirements before significant design investment.

When: After concept selection, before detailed design begins.

What to check:

Required inputs:

Pass criteria:

Documentation output:

2. Preliminary Design Review (PDR)

Purpose: Confirm that the design approach is feasible and that the detailed design phase can proceed with high confidence.

When: When the design is sufficiently mature to evaluate manufacturability and interface compatibility, but before tooling or long-lead procurement.

What to check:

Functional:

Mechanical:

FMEA:

Manufacturing:

Sourcing:

Required inputs:

Pass criteria:

Documentation output:

3. Critical Design Review (CDR)

Purpose: Confirm that the design is complete and correct before release to manufacturing.

When: After detailed design is complete and before design release. This is the final gate — the design should not change after this review without a formal engineering change process.

What to check:

Drawing completeness:

Tolerance analysis:

FMEA:

Test and verification:

Interface compliance:

Required inputs:

Pass criteria:

Documentation output:

What Documentation Should a Design Review Produce?

A design review that produces no documentation might as well not have happened. The minimum required outputs are:

Meeting record. Attendees, date, design revision reviewed, and a brief summary of what was covered. This sounds trivial but creates an auditable record that the review occurred.

Decision log. Any significant design decision made during the review — material selected, tolerance approach agreed, feature changed — should be recorded with the rationale. This prevents the same debate from reopening six months later.

Action item register. Every open item from the review needs: a description, an owner, and a due date. Without these three fields, action items do not get resolved. The register should be tracked to closure before the next gate.

Updated FMEA. The design review should result in an FMEA at the current revision, signed off by the attending team. An FMEA that is not updated at each review is not useful as a risk management tool.

Pass/hold/fail disposition. A design review should result in one of three outcomes: pass (design can advance), pass with conditions (design can advance pending resolution of specified items), or hold (design cannot advance until specified issues are resolved). This outcome should be recorded explicitly — not implied.

Common Design Review Mistakes

Reviewing too much at once. A single design review that covers an entire complex assembly in two hours will miss things. Break reviews into manageable sections — one subsystem at a time, or one discipline per session.

Using the review to present rather than review. If the engineer presenting the design is doing most of the talking, it is a presentation, not a review. Reviewers should be asking questions, not listening to a demo. Distributing the design package in advance and requiring reviewers to come with prepared questions changes the dynamic.

Documenting concerns instead of actions. There is a difference between "concern: tolerance stack-up on the main bearing assembly may be too tight" and "action: complete worst-case stack-up analysis on main bearing by [date]." Concerns do not get resolved. Actions do.

No escalation path for disagreements. When a reviewer raises a concern and the presenting engineer disagrees, there needs to be a defined escalation path — usually to a chief engineer or technical authority — rather than leaving it unresolved.

Design Reviews and Automated Analysis

The most time-consuming part of preparing for a design review is producing the analysis documents: FMEA, tolerance stack-up, and test plan. Engineers who are under schedule pressure tend to shortcut exactly these documents — which means the review happens without the inputs it needs to be useful.

ForgePilot can generate structured FMEA analysis from design inputs and run tolerance stack-up calculations — so the documents are ready for the review rather than being drafted at the review.

Summary

An effective design review requires three things: structured inputs that reviewers can evaluate before the meeting, a defined checklist of what is being assessed at each stage, and documented outputs that create an auditable record and track actions to closure.

The three formal gates — concept design review, preliminary design review, and critical design review — each serve a different purpose and require different inputs. Running all three with the same agenda and the same level of scrutiny is as problematic as skipping one entirely.

The consistent principle: the review should be hard enough that failing it actually prevents the design from advancing. If every design passes every review, the review is not finding problems. It is just confirming what the design team already believed.