DESIGN REVIEW | Six Sigma and Beyond: Design for Six Sigma, Volume VI

A typical design review is a process, and it must be (a) multi-phased and (b) involved in the different design phases. In fact, the reviews should also extend to the operations and support phases. It is of paramount importance in any given design review to consider the feedback of customer information because quite often it reveals factors of concern that may have been forgotten or considered too lightly. If design reviews are not taken seriously in the sequential design phases, warranty costs can well exceed any early budgetary considerations. A very typical sequential design review is given in the SAE R&M Guideline (1999, p. 16) shown in Table 10.1.

Table 10.1: Design Review Objectives
Design Phase	Review Objectives
Concept	Concept review: Focus on feasibility of proposed design approach
Development and design	Preliminary design review: Validate the capability of the evolving design to meet all technical requirements
Build and install	Build: Address issues resulting from machine build and runoff testing In-plant installation: Conduct failure investigation of problem areas for continuous improvement

Even though Table 10.1 identifies the core objectives of design review, there is more to it than just a cursory outline of requirements (Stamatis, 2002). For example:

System Requirements Review ” This is the first review with the customer where the customer specifies the level of cost-effectiveness that the manufacturer is expected to meet. It is at this meeting(s) that customer and manufacturer come to some agreement not only on the reliability and maintainability (R&M) characteristics but also the adjunct attributes of availability, dependability , and capability.
System Initial Design Review ” This meeting(s) provides the final definition of the system functional requirements, firming up what was discussed earlier. The allocation of R&M values accompanied by the attributes that support these is usually accomplished at this review.
Preliminary Design Review ” This is where the configuration items are reviewed and the complexities and technologies are discussed. The objects here are to (1) establish design adequacy and determine risks involved with the proposed design methods and techniques, (2) harmonize the proposed design with the specifications, and (3) ensure the compatibility of the physical and functional characteristics with each other and with the operating and maintenance environments. Resolution of the entire system could be accomplished at this review where there is some finalization on at least "first intentions." This would include initial sketches and drawings, mock-ups, simulation models, and prototypes .
Interim Design Review ” Formality of meetings continue by the manufacturer reviewing progress with the customer. Data feedback on all testing and analysis starts to get more intense at this stage. The customer and supplier review the status of the milestones to ensure being on target.
Critical Design Review ” By this stage the design should be firm enough to lock in the design parameters and make preparations for the qualification testing. The customer by all means should be present at this design review to assure that all particulars of the contract are agreed upon.
Formal Qualification Review ” This is the final review to precede full-scale production. The qualification models were fabricated and assembled with production tooling, but at this stage customer and manufacturer should be ready for the production line. At this meeting the review team confirms that the total package is as agreed upon and that it meets all the terms of the contract.
In-house Reviews ” In the event problems occur after production starts, additional reviews may be necessary. Most R&M texts do not discuss this type of review because theoretically the design is "frozen" and the only problems, if there are problems, are production types. But in the real world anomalies do occur, and they have to be addressed. The design review concept should continue until the customer is totally convinced that that the product is of high quality.

Many questions arise in the course of design review meetings. Some organizations have a checklist they use to ensure that "nothing falls through the cracks" and that they cover all the potential problems that may occur. A generic checklist, which can be used at design review meetings or by the designer to ensure the integrity of the design, is shown as Table 10.2. For obvious reasons, this list is not an exhaustive list to cover all situations. Rather, it is a list that may be modified and act as a catalyst for further discussion.

Table 10.2: Design Review Checklist
Do specified components meet their reliability requirements? Can off-the-shelf items be used for particular functions? Does the design meet functional requirements? Were standard components and assemblies considered and used where possible? Were all environmental impacts considered? Did all components pass the environmental testing? Were corrections made where necessary? Have critical characteristics been considered? Have failure histories been investigated? Did each component and material meet its requirements under environmental extremes of the specification? Were there enough data for reliability calculations? Was the complete unit tested ? Were the weak links in the design corrected? Does demonstrated reliability meet required specification or is redesign indicated? Are predicted and allocated reliabilities compatible? Are trade-offs necessary? Were manufacturing and quality assurance (QA) considered in the design? Is redundancy necessary to meet reliability requirements? Can the environment be changed or be protected? Is heating, cooling, shock mounting, shielding, or better insulation required? Were all failure modes corrected to prevent recurrence ? Has storage capability been studied? Should specifications be written to ensure 100% test and inspection? Are there suitable manufacturing and QA procedures to ensure good quality? Is the item designed as simply as possible? Have all human factors been considered? Have sharp corners been considered? Have all potential stress risers been eliminated? Can other cognizant disciplines help in writing specifications or offer improvements in the design? Can suppliers provide reliability values for their components? If so, are the values compatible with the overall system? Has enough testing been performed to validate the required reliability for designated components? Will early testing or screening help eliminate infant mortality type failures? Have maintainability requirements been considered?

Here, we must give the reader a very strong caution. Concurrent or simultaneous engineering is not a design review function, but it is closely related to it. Concurrent engineering is the process by which all disciplines that design, manufacture, inspect, sell, use, and maintain the product work together to develop and produce it. Milestones are established where the various disciplines accomplish specific tasks simultaneously before proceeding on to the next task. Traditionally, each step in the design process occurred one step at a time and extended over a relatively long duration. In concurrent engineering, several tasks such as manufacturing engineering work with the quality engineer and design to set up their responsibilities while the designer is still working with the design. A comparison between traditional and concurrent engineering is shown in Table 10.3.

Table 10.3: Comparison Between Traditional and Concurrent Engineering
Function	Traditional Engineering	Concurrent Engineering
Organization	Engineering is unique and separate from other departments	Engineering is part of multifunctional team with team objectives
Timing of outputs and inputs	Each department waits for output from previous department	Tasks progress simultaneously working with engineering

FAILURE MODE AND EFFECT ANALYSIS (FMEA)

Even though the FMEA is discussed in Chapter 6, it is important to discuss here the relationship between FMEA and design review. FMEA, as we already have said, is a methodology that helps in identifying potential and known failure modes and then arriving at a probability of occurrence and detection. In addition, a good FMEA should recognize interfacing failures in components, subsystems, and systems themselves . Typical interfacing problems may occur in the form of proximity, information, material, and energy transfer. In all cases, the ultimate goal of any FMEA (Concept/System, Design, Process, or Machinery) is to reduce as many failure modes as possible, or to reduce the probability of the failure modes as much as possible. The process of doing an FMEA is a down-up approach. For a very detailed explanation, see Stamatis (1995).

An FMEA in design review should not be confused with a Fault Tree Analysis (FTA). Whereas the FMEA is a down-up approach, the FTA is a top-down approach to failure analysis starting with the undesirable "top event" and progressively determining all the ways the failure may happen. The analysis starts early in the concept phase and is continually monitored through the subsequent stages. A comparison between FMEA and FTA is given below:

An FMEA starts with the origin of a failure mode and then proceeds to find the causes, probabilities, and corrective actions.	An FTA starts with an accident or undesirable failure event, determines the causes, then the origin of the causes, then what can be accomplished to avoid the failure.
An FMEA considers all potential failure modes that can be produced through mental generation.	An FTA studies only negative outcomes that warrant further analysis.
An FMEA uses an inductive approach.	The FTA uses a deductive approach.
Less engineering is needed for an FMEA.	Skilled personnel are required for an FTA.
There is limited safety assessment in an FMEA.	The FTA manages risk assessment and safety concerns.
The failure paths are not delineated in an FMEA.	The FTA provides a good assessment of the failure paths, and the control points are well enhanced.
An FMEA looks at each failure mode separately.	An FTA demonstrates a more selective method of showing the relationship among events that interact with one another.

The steps of the FMEA are:

Define the team.
Define the system, design, process, or machinery (block diagram, process flow diagram).
Construct the P-diagram.
Define the function.
Identify the failure(s).
Complete the tabular form.
Analyze (evaluate) the completed FMEA.
Recommend any corrections for design changes.
Document the analysis and its results.

To help in the generation of FTA, the Rome Air Development Center (RADC) has formulated a seven-step approach. These steps obviously are very generic, and each organization that is using them must modify them to fit their purpose. The seven steps are:

Define the system, ground rules, and any assumptions to be used in the analysis.
Develop a simple block diagram of the system showing inputs, outputs, and interfaces.
Define the top event (ultimate failure effect or undesirable event) of interest.
Construct the fault tree for the top event using the rules of formal logic.
Analyze the completed fault tree.
Recommend any corrections for design changes.
Document the analysis and its results.

FTA is one of the few tools that can depict the interaction of many factors and manage to consider the event that would trigger the failure or undesirable event. Designers should consider the safety aspects of their designs early in the concept stage so that necessary changes can be accomplished before they have a chance of occurring.