Welcome


Welcome to my blog for all things related to business quality (processes, systems and ways of working), products and product quality, manufacturing and operations management.

This blog is a mixture of real-world experience, ideas, comments and observations that I hope you'll find interesting.

Pages

May 2010
M T W T F S S
« Apr   Jun »
 12
3456789
10111213141516
17181920212223
24252627282930
31  

In praise of Design Reviews

I worked in one of the large Cambridge-based technology consultancies for many years and was privileged to have clients from small, inexperienced start-ups to large, established mature enterprises. Sometimes we developed products from scratch but sometimes we were brought in late in the day to sort out a client’s project that had gone wrong.

One of the key tools that we used was the formal design review. We used it during complete product developments – it was an integral part of our ISO 9001 processes and we were trained how to do it – but it was of even greater benefit when we were parachuted in to rescue a project.

I have used the same technique with clients ever since.

However clever the designers, however sophisticated the design, this approach finds bugs. Peer-reviewing new designs before you commit a lot of time and money can be hugely beneficial in preventing problems further downstream… if done properly.

Process

Your people will naturally be capable of finding design weaknesses if given the opportunity, environment and culture that encourages them to do so, even if – especially if – they aren’t personally involved in that part of the design.

The review is done by a selected group by peers (colleagues) from different disciplines; electronic engineers, mechanical engineers, system architects, manufacturing people, software experts, etc, under the chairmanship of an experienced reviewer not the designer/s themselves. The timing of the review is usually set by project management but is typically at a point in the project where a significant commitment of time, money or risk is about to be made e.g. release of design details into prototype manufacturing.

For a complex design the requirements specification, functional specification and the design documentation should be circulated in advance so the attendees can spend time understanding it and assessing it for themselves. The design review meeting then reviews and challenges these findings.

For a simple design, or an iteration, the findings can usually be derived on-the-fly during the meeting itself.

In both instances the meeting decides on the relative importance of the findings and identifies the actions that needs to be taken. These are documented in a meeting note or minutes, and the actions are progressed to a conclusion through project or line management.

Check List

To help guide the review, give it structure, and avoid omitting key questions, I have always found it beneficial to use a detailed checklist. This is added to over time so that it becomes a ‘superset’ of all possible questions. Many will be not applicable for any given circumstance so can be omitted, but it’s a way to avoid leaving anything out; it captures best practice for your products and industry.

There isn’t room here to reproduce a generic checklist – in any case it should be bespoke to you and your business – but, for illustration, I would expect an electronic or electro-mechanical checklist to cover:

Specifications, risks, safety-critical areas, design fail-safes, use of unproven technologies or new design techniques.

Schematic design: Gate and bus loading, I/O loading and protection, devices within Safe Operating Areas, production tolerancing, PSU monitoring / watchdogs, high current or voltage designs, spare IC pins (especially inputs), timing and synchronisation.
Thermal effects, heat generated and heat dissipation, power distribution. Design for Manufacture / Test / Environment / EMC. FMEA. Product costing. Production test design and coverage. PCB layout rules, RF design constraints, lay-ups, design for EMC, test points, mechanical interfaces, component sourcing.

Software / firmware design and prototyping, BITE, software to test hardware at different stages, GUI design, interoperability and standards compliance. ASIC design, timing analysis, hardware and/or software simulation. Industrial Design, mechanical design, tolerancing, tooling, robustness or life testing, mechanism optimisation, stress testing, HALT / HASS, pressure relief, fluid handling…
…and so on (the full checklist asks much more detailed questions, of course).

I suggest that you draw up a checklist specific to your own products and technologies, then evolve the list over time on the basis of experience and as a Corrective Action if you find that design shortcomings have slipped through its safety net.

In any case, it isn’t the list itself that’s important, it’s the things that going through the list – and asking questions of each other in a constructive way – brings up.

And, as a bonus, it’s a very effective way of addressing ISO 9001 Section 7.3.4.

They don’t like it…

Instinctively, some design engineers don’t like this process. If not done well they can feel like they are under unfair pressure or criticism. I had one engineer say to me recently “it was a waste of time, most questions were irrelevant, it took too long”. “Sorry to hear that”, I replied, “so you didn’t find anything that could be improved?” “Oh yes, we spotted some things we definitely needed to change…”

QED!

The fix for their reluctance? Make it constructive not critical, make it relevant, show how effective it can be as a design safety-net, and make them part of developing the process so they are passing on their experience and knowledge to others.

By finding and fixing the design shortcomings and risks at this stage you can prevent hugely expensive field failures or product recalls; I suspect that, given their recent experience, Toyota wish they had done better design reviews…

Share

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>