Design Reviews That Actually Find Problems
Design Reviews That Actually Find Problems
Every engineering department runs design reviews, and most of them are ceremonial. The drawings get flipped through, the schedule gets discussed, and the real problems surface three months later on the assembly floor. This article covers the practical design review process that catches problems while they are still cheap to fix.
The Review Is Not a Presentation
The fatal flaw in most reviews is the format: the designer presents, the reviewers nod, and the meeting ends with action items nobody owns. A design review is an interrogation of the design against the requirements, not a slide show.
The fix is to structure the review around the design intent, the loads, the interfaces, and the failure modes, not around the CAD pretty pictures. The reviewers need the calculation sheets, the load cases, and the interface control documents before the meeting, not as the slide deck.
Send the material 48 hours ahead. A review where the reviewers have read the design is a review; a review where they see it for the first time is a briefing.
The Requirement Traceability Check
The first question in any review is not “does this look good” but “what are we building and how do we know it works.”
Build the requirement list before the design starts, and check each requirement at the review:
| Requirement | Verification method | Status |
|—|—|—|
| Cycle time under 12 s | Motion simulation | Pass |
| Load capacity 500 kg | FEA and test | Review |
| MTBF over 5000 h | Supplier data and experience | Open |
| Interface with existing line | Interface drawing | Pass |
| Cost under budget | Quote comparison | Review |
If the requirement has no verification method, the design team has been guessing. The review should flag every unverified requirement and assign an owner.
The Load Case Table
The most common cause of field failure is a load case nobody considered. The review should force the designer to enumerate the load cases explicitly.
The standard set for machine design:
Static load at the worst position.
Dynamic load at the highest acceleration.
Thermal load at the highest ambient temperature.
Assembly and disassembly loads.
Shipping and handling loads.
Failure mode loads, like a jam or a crash.
For each load case, the review checks: who calculated it, what value was used, what factor of safety, and what would fail first. If the designer says “we used a factor of safety of 2,” the reviewer asks “on what load?”
Interface Control: Where the Problems Hide
Most design problems live at the interfaces: the machine to the floor, the tool to the spindle, the sensor to the controller, the panel to the power. Each interface is a contract, and each contract needs a document.
The interface control document should state:
• Physical dimensions and tolerances of the mating features.
• Forces and moments transmitted across the interface.
• Electrical signals, power, and ground requirements.
• Environmental conditions at the interface.
• The party responsible for each side of the interface.
A review that checks every interface document against the drawings catches the classic mismatches: the bolt circle that does not line up, the sensor range that cannot see the target, the connector that fits but carries the wrong signal.
Failure Mode Review: What Happens When It Breaks
Design reviews should include a structured failure mode discussion, even if it is informal. The question is simple: what is the most likely way this machine fails, and what happens then?
The high-value failure modes for machinery:
• Jams and crashes: does the machine detect them, stop safely, and recover?
• Power loss: does the machine fail safe or fall?
• Sensor failure: does the controller see the wrong signal and do something dangerous?
• Human error: can an operator reach a hazard, defeat a guard, or misload a part?
• Maintenance error: can the maintenance person reassemble it wrong?
The review should decide for each mode: detect, contain, or design out. If the answer is “the operator will notice,” the design needs more work.
The Human Factor Review
Machines are operated, loaded, unloaded, cleaned, and maintained by people. The design review should walk through every human interaction with the machine and check for ergonomics, access, and safety.
The questions:
• Can the operator load and unload without reaching into the hazard zone?
• Is the control panel reachable and readable from the operating position?
• Are the adjustment points accessible with the right tool?
• Is the maintenance access clear of pinch points and sharp edges?
• Are the labels, warnings, and instructions readable and in the right language?
The ergonomic problems found at the review cost an hour to fix on the drawing and a day to fix on the floor. The reviewer who walks the virtual machine like a real operator finds them.
The Documentation and BOM Check
The review should verify that the design is buildable from the documentation alone, without the designer standing over the assembler’s shoulder.
Checklist:
• The BOM matches the drawing callouts, with no missing fasteners or ambiguous part numbers.
• The drawing has the critical dimensions, tolerances, and surface finishes.
• The assembly drawing shows the order and the references.
• The pneumatic, hydraulic, and electrical schematics match the mechanical design.
• The spare parts list identifies the wear items and the replacement procedure.
A surprising number of machines ship with a BOM that does not match the drawings, and the mismatch is found when the spare part does not fit.
Action Items and Ownership
A design review without action items is a meeting. The review should close with a short, owned list.
The rule of three:
• Every action item has one owner, not a committee.
• Every action item has a due date tied to the schedule.
• Every action item has a verification method: how do we know it is done?
The follow-up review should start by checking the action items from the last review, not by re-presenting the design. If the same issue appears twice, the process is broken, not the design.
The Prototype and Test Plan Review
A design review is not complete without a plan for proving the design works. The prototype plan should be on the table at the review, not invented after the drawings are released.
The review questions:
What prototype tests prove the critical functions?
What measurements are taken, and with what instruments?
How many prototypes are needed to establish confidence?
What is the pass/fail criterion for each test?
What happens if the prototype fails?
The common failure is testing the happy path and skipping the edge cases. The review should ensure the test plan includes the worst-case load, the highest speed, the lowest temperature, and the longest duty cycle.
A design that passes a review but has no test plan is a design that will be tested by the first customer.
Cost and Schedule Review
The design review is the right place to check the cost and the schedule, not because the designers own the budget, but because the design decisions drive both.
The review checks:
• Is the design within the target cost, and is the cost breakdown credible?
• Are the long-lead items identified and ordered in time?
• Are the risky processes, like large castings or complex weldments, scheduled with buffer?
• Does the assembly sequence fit the production schedule?
• Are the test and validation steps in the schedule?
A design that is technically excellent and commercially late is a failed design. The review should treat the schedule as a requirement with the same weight as the load capacity.
Lessons from Past Projects
Every department has a history of failures, and the design review should tap it. The simplest tool is a lessons-learned checklist from previous projects.
The questions:
• What failed on the last machine of this type?
• What did the customer complain about most?
• What was the longest service issue?
• What did the maintenance team have to fix repeatedly?
• What did the shop struggle to build?
A review that starts with last year’s failures and checks the new design against each one is worth more than any generic checklist. The institutional memory is the cheapest consultant in the room.
The Checklist as a Starting Point, Not the Whole Review
Many departments reduce the design review to a generic checklist, and the checklist becomes the ceiling of the review, not the floor. The checklist catches the common stuff but misses the design-specific risks.
The better structure is a short core checklist, followed by an open discussion focused on the design’s unique risks. The unique risks are the ones nobody has seen before, and they are exactly the ones the checklist cannot catch.
The reviewer should ask the designer: what worries you most about this design? The honest answer is usually the right place to spend the review time.
The Review Team and the Culture
The design review works only when the team is honest, and the honesty is a culture choice, not a process choice. A review where the junior engineer speaks first and the boss speaks last is a review where the problems stay under the table.
The team rules that work:
Invite the people who will build, run, and service the machine, not just the designers.
Give the junior engineers the floor first, so the senior opinion does not lead the discussion.
Reward the person who finds the problem, instead of punishing the person who made it.
Keep the review focused on the design, not the designer.
Record the disagreements and the resolution, so the decision is traceable.
The review is a failure if the team leaves the room feeling relieved that nothing bad was found. The uncomfortable review is the productive review, and the culture that supports the uncomfortable conversation is the culture that ships the reliable machines.
The design review is also the training ground for the next generation of designers. The junior engineer who sits through a good review learns how the requirements, the loads, and the interfaces are weighed, and that lesson is worth more than a year of tutorials.
The Design Review in the Project Schedule
The design review only works if it is in the schedule with a hard date, and the hard date is what forces the design to be ready. A review that waits until the design is finished is a review that finds the problems when they are expensive.
The schedule rules:
Put the preliminary review early, when the concept and the loads are on the table and the changes are still cheap.
Put the critical review before the drawings are released, not after the prototypes are ordered.
Leave the time for the action items between the reviews, and check the completion at the next gate.
Put the final review before the production release, with the test results and the field feedback included.
The review gate is the project control: the design does not pass to the next stage without the review sign-off, and the sign-off has the owner and the date for every open item.
The gate also protects the team from the sunk-cost trap. A concept that has consumed three weeks of effort is still a wrong concept if it fails the review, and the gate makes the stop decision explicit and early. The sunk cost is gone either way; the gate decides whether the project spends more on it.
The schedule without the review gate is a schedule where the problems are found by the customer. The customer’s review is the most expensive review in the project, and the project schedule should make sure it is not the only one.
Conclusion
Design reviews catch problems when they are cheap to fix, but only if the review is structured around requirements, loads, interfaces, and failure modes, and only if the actions get owned and verified.
Send the material ahead, check the requirement traceability, enumerate the load cases, verify the interfaces, walk the failure modes, review the human interactions, check the documentation, and close with owned actions. That is the difference between a review that finds problems and a review that finds consensus.
