In praise of the Design Review Process

Design Review ProcessI 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 on other occasions, 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 process. We used it during complete product developments – it was an integral part of our approach to ISO 9001 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.

11 myths about ISO 9001 - busted!

Towards an Effective Design Review 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 select group of 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 need 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.

Some key Design Review Process Steps

To help guide the review, give it structure, and avoid omitting key questions, I have always found it beneficial to use a detailed checklist. Added to over time it can become 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. And 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 8.3.4.

A closer look at Document Control for ISO9001

They don’t like it…

Instinctively, some design engineers don’t like this process. If it’s not done well they can feel like they are under unfair pressure or criticism. After one such review an engineer said to me “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.

A comprehensive guide to GxP compliance

Tags: ISO 9001:2015

Tom Gaskell

Written by Tom Gaskell

Tom Gaskell is the founder and director of Primilis Ltd, a UK quality and business consultancy. He has a degree in electronic engineering and a background in radio broadcasting, in front of and behind the microphone (creating the first audio system for the Houses of Parliament, a data comms system for Independent Local Radio, and the first assignable analogue mixing desk). He was a senior consultant with PA Technology for 14 years, developing electronic and electromechanical products and advising clients around the world, before helping to establish its spin-off, UbiNetics, where he was responsible for product quality and manufacturing. He is known for introducing – and has presented papers on – agile manufacturing, and for working with manufacturers in Europe, the USA and the Far East. Tom has been involved with business quality management for more than 18 years and has worked with Cognidox since 2009; he was the original creator of what is now the Cognidox gBMS platform. He specialises in simple, effective graphical quality management systems to ISO 9001 and other standards, and has trained more than 80 customers in the use of the gBMS.

Related Posts

8 tips for documenting your SOPs (Standard Operating Procedures)

There are many reasons why organisations need to document their SOPs. From ensuring uniformity in ...

Should you use Microsoft software to build your own digital QMS?

SMEs creating a digital Quality Management System (QMS) will often reach for the most familiar ...

Document Control requirements in ISO 9001:2015; what you need to know

Document control is a key part of any Quality Management System (QMS) and, therefore, a requirement ...