Implement design reviews the right way

Design reviews are perhaps one of the oldest known techniques for debugging designs to keep errors from getting downstream. At the same time, they are also one of the most misapplied tools commonly utilized by development professionals.

Common stumbling blocks. One major area of misapplication results when users confuse project and/or program reviews with design reviews. Design reviews focus exclusively on the design of the product. The purpose of design reviews is to review the overall design, or a specific aspect of a design, during any point in the development of a new or existing product. Discussions about project schedule, development cost, staffing, and other project-related issues should not be discussed in design review meetings...only design issues.

Design-review techniques are also misapplied when the team members get together without external reviewers to examine the design of the product on which they are currently working. Robust design-review processes will always involve independent teams of reviewers meeting with the members of the team designing the product.

Further, design reviews often occur after the fact. Models, breadboards, and prototypes are built, and the design is then reviewed. Design reviews should be "reviews of design" and not "reviews of as-built." The whole idea is to get the bugs out on paper before building the product.

Finally, the multi-faceted nature of the technique can complicate the review process. Best practices typically involve several flavors of design reviews. The population of formal reviews for a given development effort will contain early requirements, specification, and architecture reviews; focused serviceability, manufacturability, and reliability reviews; and comprehensive feature-function-performance reviews. Numerous informal reviews will take place. Depending on the complexity of the product, these review techniques may be applied at a component, subassembly, subsystem, and/or system level. Many companies often create poorly constructed design review processes that fail to add value.

Benefits. Design reviews are a proven approach that will improve the "product development hygiene" in your company and pay significant benefits. In addition to contributing to higher quality products and improved reliability, design reviews alone have reduced time-to-market by 50%.

Two companies, in quite different industries, provide good examples. Analog Devices applies design-review techniques to ensure that integrated-circuit test requirements have been designed into the design. Adding additional test points at the last minute often increases die size and therefore product cost. Savings are also realized by reducing the complication of probe cards and final test jigs, fixtures, and software. Raytheon, while also applying design- review techniques at the component and/or subassembly level, uses the technique to ensure robustness at the architecture or system engineering level. Early verification of the architecture reduces the risk of identifying a major design change later that will ripple throughout the complicated and highly integrated systems.

Ask the Manager

Q: How many people are involved in a design review?

A: Adapting best practices for design reviews with the team-based product-development ap-proaches of the 1990s yields four groups and/or individuals with specific roles: 1) development team (group), 2) review team (group) 3) moderator (individual), and 4) recorder (individual).

Then one person is appointed from each team or group to lead the effort as development team "presenter" and review team "chairman."

One can intuit that the process is a structured one. To remain focused on the product design review agenda, keep meetings brief, and minimize getting too personal on design critique during the meeting. It is prudent to have referees.

Q: Who drives the design review agenda and runs the meeting?

A: Initially, the development team drives. It must invite someone who is qualified to be the "presenter." This is necessary in order to get a running start on a constructive design review meeting. A development team will resist feedback from a person or group that it does not respect or like. The presenter or team leader for this current design review meets with the chairman to work out the specific meeting agenda.

Then the pendulum of responsibility for driving swings to the chairman. The chairman selects a review team and must lead the flow of the design review.

The moderator runs the actual meeting. Once the presenter has finished with the opening briefing to everyone involved in the room, the chairman takes the lead in the ensuing discussion. The recorder may break in from time to time to clarify points and actions.