The focus should be
on some aspect of your current system-level design and how you arrived at it
1) Start with a
picture/drawing of the most current system-level design to remind the reviewers
of your specific project
2) Pick just a few
critical items or subsystems to discuss based on
a) questions/errors from
previous reports/reviews,
b) current bottlenecks/problems that you need to solve, or
c) issues that you would like input/feedback on
3) Justify key design
decisions (especially those related to the system-level configuration) based on
safety, value, reliability, manufacturability, prototype tests, design
analysis, etc. Strive to demonstrate why
your design is a “good design”, and not just one that "should work".
· Do not spend time on previous design
ideas that have been changed, and do not depend heavily on "relative justification"
(this idea is better than our preliminary design), your job is to convince the
reviewers that on an absolute scale the current design embodiment is
"good"
· Specifics are good, generalities are
bad/useless
· Do not spend time defining the
design refinement tools (i.e. giving background info on FMEA or value
engineering) or talking about the design process for its own sake - the focus
of the design review is on the current embodiment of the product (the design
itself)
o
The
design refinement "tools" are important as justification for design
decisions
o
Pareto
charts and other prioritization tools are useful for justifying how you spent
your time and resources up to this point and how you plan to spend them in the
future
Remember that the
more specific you are in presenting your design in these mini-design reviews the more useful feedback you can get to improve your design,
which should lead to fewer problems and questions during the formal final
design review.