APQP – Advanced product quality planning

di Kenneth Crow – DRM Associates

Advanced Product Quality Planning (APQP) is a quality framework used for developing new products in the automotive industry. It can be applied to any industry and is similar in many respects to the concept of design for six sigma (DFSS).

The APQP process is described in AIAG manual 810-358-3003. Its purpose is “to produce a product quality plan which will support development of a product or service that will satisfy the customer.” It does this by focusing on:

• Up-front quality planning
• Evaluating the output to determine if customers are satisfied & support continual improvement

The Advanced Product Quality Planning process consists of four phases and five major activities along with ongoing feedback assessment and corrective action as shown below.

A further indication of the APQP process is to examine the process outputs by phase. This is shown in the table below:

The APQP process involves these major elements:

• Understand customer needs . This is done using voice of the customer techniques to determine customer needs and using quality function deployment to organize those needs and translate them into product characteristics/requirements.

Quality can be defined as meeting customer needs and providing superior value. Meeting customer needs requires that those needs be understood. The “voice of the customer” is the term to describe the stated and unstated customer needs or requirements. The voice of the customer can captured in a variety of ways: direct discussion or interviews, surveys, focus groups, customer specifications, observation, warranty data, field reports, etc.

CAPTURING THE VOICE OF THE CUSTOMER

Once a product plan is established which defines the target market and customers, the next step is to plan how to capture these customer’s needs for each development project. This includes determining how to identify target customers, which customers to contact in order to capture there needs, what mechanisms to use to collect their needs, and a schedule and estimate of resources to capture the voice of the customer (project plan for product definition phase).

As opportunities are identified, appropriate techniques are used to capture the voice of the customer. The techniques used will depend on the nature of the customer relationship as illustrated below.

 

 

 

 

 

There is no one monolithic voice of the customer. Customer voices are diverse. In consumer markets, there are a variety of different needs. Even within one buying unit, there are multiple customer voices (e.g., children versus parents). This applies to industrial and government markets as well. There are even multiple customer voices within a single organization: the voice of the procuring organization, the voice of the user, and the voice of the supporting or maintenance organization. These diverse voices must be considered, reconciled and balanced to develop a truly successful product.

Traditionally, Marketing has had responsibility for defining customer needs and product requirements. This has tended to isolate Engineering and other development personnel from the customer and from gaining a first hand understanding of customer needs. As a result, customer’s real needs can become somewhat abstract to other development personnel.

Product development personnel need to be directly involved in understanding customer needs. This may involve visiting or meeting with customers, observing customers using or maintaining products, participating in focus groups or rotating development personnel through marketing, sales, or customer support functions. This direct involvement provides a better understanding of customer needs, the customer environment, and product use; develops greater empathy on the part of product development personnel, minimizes hidden knowledge, overcomes technical arrogance, and provides a better perspective for development decisions. These practices have resulted in fundamental insights such as engineers of highly technical products recognizing the importance to customers of ease of use and durability rather than the latest technology.

Where a company has a direct relationship with a very small number of customers, it is desirable to have a customer representative(s) on the product development team. Alternately, mechanisms such as focus groups should be used where there are a larger number of customers to insure on-going feedback over the development cycle. Current customers as well as potential customers should be considered and included. This customer involvement is useful for initially defining requirements, answering questions and providing input during development, and critiquing a design or prototype.

How many customers should be talked to? The number depends on complexity of the product, diversity of market, product use, and the sophistication of customers. The goal is to get to the 90-95% level in capturing customer needs. Research for a range of products indicates that, on average, this is 20 customers.

Who do we talk to? Current customers are the first source of information if the product is aimed at current market. In addition, its important to talk with potential customers. Potential customers are the primary source of information if the product is aimed at new market. In addition, talk with competitor’s customers. They provide a good source of information on strengths on competitor’s products and why they don’t buy from us. Lead customers are a special class of coustomers that can provide important insights, particularly with new products. Lead customers are those customers who are the most advanced users of the product, customers who are pushing the product to its limits, or customers who are adapting an existing product(s) to new uses.

During customer discussions, it is essential to identify the basic customer needs. Frequently, customers will try to express their needs in terms of HOW the need can be satisfied and not in terms of WHAT the need is. This limits consideration of development alternatives. Development and marketing personnel should ask WHY until they truly understand what the root need is. Breakdown general requirements into more specific requirements by probing what is needed. Challenge, question and clarify requirements until they make sense. Document situations and circumstances to illustrate a customer need. Address priorities related to each need. Not all customer needs are equally important. Use ranking and paired comparisons to aid to prioritizing customer needs. Fundamentally, the objective is to understand how satisfying a particular need influences the purchase decision.

In addition to obtaining an understanding of customer needs, it is also important to obtain the customer’s perspective on the competition relative to the proposed product. This may require follow-up contact once the concept for the product is determined or even a prototype is developed. The question to resolve is: How do competitive products rank against our current or proposed product or prototype?

ORGANIZING CUSTOMER NEEDS

Once customer needs are gathered, they then have to be organized. The mass of interview notes, requirements documents, market research, and customer data needs to be distilled into a handful of statements that express key customer needs. Affinity diagramming is a useful tool to assist with this effort. Brief statements which capture key customer needs are transcribed onto cards. A data dictionary which describes these statements of need are prepared to avoid any mis-interpretation. These cards are organized into logical groupings or related needs. This will make it easier to identify any redundancy and serves as a basis for organizing the customer needs.

In addition to “stated” or “spoken” customer needs, “unstated” or “unspoken” needs or opportunities should be identified. Needs that are assumed by customers and, therefore not verbalized, can be identified through preparation of a function tree. Excitement opportunities (new capabilities or unspoken needs that will cause customer excitement) are identified through the voice of the engineer, marketing, or customer support representative. These can also be identified by observing customers use or maintain products and recognizing opportunities for improvement.

• Proactive feedback & corrective action. The advance quality planning process provides feedback from other similar projects with the objective of developing counter-measures on the current project. Other mechanisms with verification and validation, design reviews, analysis of customer feedback and warranty data also satisfy this objective.
• Design within process capabilities. This objective assumes that the company has brought processes under statistical control, has determined its process capability and has communicated it process capability to its development personnel. Once this is done, development personnel need to formally determine that critical or special characteristics are within the enterprise’s process capability or initiate action to improve the process or acquire more capable equipment.

PROCESS CAPABILITY

Being in control of a manufacturing process using statistical process control (SPC) is not enough. An “in-control” process can produce bad or out-of-spec product. Manufacturing processes must meet or be able to achieve product specifications. Further, product specifications must be based on customers requirements.

Process capability is the repeatability and consistency of a manufacturing process relative to the customer requirements in terms of specification limits of a product parameter. This measure is used to objectively measure the degree to which your process is or is not meeting the requirements.

Capability indices have been developed to graphically portray that measure. Capability indices let you place the distribution of your process in relation to the product specification limits. Capability indices should be used to determine whether the process, given its natural variation, is capable of meeting established specifications. It is also a measure of the manufacturability of the product with the given processes.

Capability indices can be used to compare the product/process matches and identify the poorest match (lowest capability). The poorest matches then can be targeted on a priority basis for improvement.

If we sample a group of items periodically from a production run and measure the desired specification parameter, we will get subgroup sample distributions that can be compared to that parameter’s specification limits. Two examples of this are represented below.

 

 

 

 

The diagram on the left shows a series of sample distributions that fall inside of and outside of the specification limit. This is an example of an unstable, not capable process. The right side of the diagram shows all of the distributions falling within the specification limits. This is an example of a capable process.

Process capability can be expressed with an index. Assuming that the mean of the process is centered on the target value, the process capability index Cp can be used. Cp is a simple process capability index that relates the allowable spread of the spec limits (spec range or the difference between the upper spec limit, USL, and the lower specification limit, LSL) to the measure of the actual, or natural, variation of the process, represented by 6 sigma, where sigma is the estimated process standard deviation.

 

 

 

 

 

If the process is in statistical control, via “normal” SPC charts, and the process mean is centered on the target, then Cp can be calculated as follows:

Cp = (USL – LSL) / 6 sigma

Cp<1 means the process variation exceeds specification, and a significant number of defects are being made.

Cp=1 means that the process is just meeting specifications. A minimum of .3% defects will be made and more if the process is not centered.

Cp>1 means that the process variation is less than the specification, however, defects might be made if the process is not centered on the target value.

While Cp relates the spread of the process relative to the specification width, it does not address how well the process average, X, is centered to the target value. Cp is often referred to as process “potential”.

 

 

 

 

 

Cpk measures not only the process variation with respect to allowable specifications, it also considers the location of the process average.

Cpk is taken as the smaller of either Cpl or Cpu

Cpl = (X -LSL) / 3 sigma where X is the process mean

Cpu = (USL – X ) / 3 sigma where X is the process mean

Many companies are establishing specific process capability targets. They may typically start with 1.33 for supplier qualification and have an expected goal of 2.0. If the process is near normal and in statistical control, Cpk can be used to estimate the expected percent of defective material.

Process Capability Studies are designed to see what the process is “capable” of doing under controlled conditions. The studies look at how capable the process is given ideal conditions over a short period of time (such as one hour to twenty-four hours.) The individual who is mainly responsible for a the process capability study is a Process Engineer. The Process Engineer must keep in mind the following two considerations when conducting the study.

• Eliminate or minimize special causes of variation, for example using the same operator, same batch of material, same machine and so on.
• Collect a minimum of 50 consecutive pieces in at least 10 subgroups of 5.

The benefits of conducting a Process Capability Study allows you to determine the “short” term stability and capability of a process.

Process Performance Studies are performed to identify how well a process, that is in statistical control, performs long term (for example, one week or longer). Two types of variations within the process are statistically measured: variation within subgroups and variations between subgroups. Variables should include different operators, material, tool changes, adjustments and so on. For the Process Performance Study to be successful the Process Engineer must ensure the following:

• Data is obtained over an extended period of time (a minimum of 5 days of data) under normal conditions
• A minimum of 100 pieces in 20 subgroups of 5 is gathered

The benefit of a Process Performance Study allows you to determine the “long” term stability and capability of a process.

• Analyze & mitigate failure modes. This is done using techniques such as failure modes and effects analysis or anticipatory failure determination.

Customers are placing increased demands on companies for high quality, reliable products. The increasing capabilities and functionality of many products are making it more difficult for manufacturers to maintain the quality and reliability. Traditionally, reliability has been achieved through extensive testing and use of techniques such as probabilistic reliability modeling. These are techniques done in the late stages of development. The challenge is to design in quality and reliability early in the development cycle.

Failure Modes and Effects Analysis (FMEA) is methodology for analyzing potential reliability problems early in the development cycle where it is easier to take actions to overcome these issues, thereby enhancing reliability through design. FMEA is used to identify potential failure modes, determine their effect on the operation of the product, and identify actions to mitigate the failures. A crucial step is anticipating what might go wrong with a product. While anticipating every failure mode is not possible, the development team should formulate as extensive a list of potential failure modes as possible.

The early and consistent use of FMEAs in the design process allows the engineer to design out failures and produce reliable, safe, and customer pleasing products. FMEAs also capture historical information for use in future product improvement.

Types of FMEA’s

There are several types of FMEAs, some are used much more often than others. FMEAs should always be done whenever failures would mean potential harm or injury to the user of the end item being designed. The types of FMEA are:

• System – focuses on global system functions
• Design – focuses on components and subsystems
• Process – focuses on manufacturing and assembly processes
• Service – focuses on service functions
• Software – focuses on software functions

FMEA Usage

Historically, engineers have done a good job of evaluating the functions and the form of products and processes in the design phase. They have not always done so well at designing in reliability and quality. Often the engineer uses safety factors as a way of making sure that the design will work and protected the user against product or process failure. As described in a recent article:

“A large safety factor does not necessarily translate into a reliable product. Instead, it often leads to an overdesigned product with reliability problems.”

Failure Analysis Beats Murphey’s Law
Mechanical Engineering , September 1993

FMEA’s provide the engineer with a tool that can assist in providing reliable, safe, and customer pleasing products and processes. Since FMEA help the engineer identify potential product or process failures, they can use it to:

• Develop product or process requirements that minimize the likelihood of those failures.
• Evaluate the requirements obtained from the customer or other participants in the design process to ensure that those requirements do not introduce potential failures.
• Identify design characteristics that contribute to failures and design them out of the system or at least minimize the resulting effects.
• Develop methods and procedures to develop and test the product/process to ensure that the failures have been successfully eliminated.
• Track and manage potential risks in the design. Tracking the risks contributes to the development of corporate memory and the success of future products as well.
• Ensure that any failures that could occur will not injure or seriously impact the customer of the product/process.

Benefits of FMEA

FMEA is designed to assist the engineer improve the quality and reliability of design. Properly used the FMEA provides the engineer several benefits. Among others, these benefits include:

• Improve product/process reliability and quality
• Increase customer satisfaction
• Early identification and elimination of potential product/process failure modes
• Prioritize product/process deficiencies
• Capture engineering/organization knowledge
• Emphasizes problem prevention
• Documents risk and actions taken to reduce risk
• Provide focus for improved testing and development
• Minimizes late changes and associated cost
• Catalyst for teamwork and idea exchange between functions

FMEA Timing

The FMEA is a living document. Throughout the product development cycle change and updates are made to the product and process. These changes can and often do introduce new failure modes. It is therefore important to review and/or update the FMEA when:

• A new product or process is being initiated (at the beginning of the cycle).
• Changes are made to the operating conditions the product or process is expected to function in.
• A change is made to either the product or process design. The product and process are inter-related. When the product design is changed the process is impacted and vice-versa.
• New regulations are instituted.
• Customer feedback indicates problems in the product or process.

FMEA Procedure

The process for conducting an FMEA is straightforward. The basic steps are outlined below.

1. Describe the product/process and its function. An understanding of the product or process under consideration is important to have clearly articulated. This understanding simplifies the process of analysis by helping the engineer identify those product/process uses that fall within the intended function and which ones fall outside. It is important to consider both intentional and unintentional uses since product failure often ends in litigation, which can be costly and time consuming.
2. Create a Block Diagram of the product or process. A block diagram of the product/process should be developed. This diagram shows major components or process steps as blocks connected together by lines that indicate how the components or steps are related. The diagram shows the logical relationships of components and establishes a structure around which the FMEA can be developed. Establish a Coding System to identify system elements. The block diagram should always be included with the FMEA form.
3. Complete the header on the FMEA Form worksheet: Product/System, Subsys./Assy., Component, Design Lead, Prepared By, Date, Revision (letter or number), and Revision Date. Modify these headings as needed.
4. 

1. Use the diagram prepared above to begin listing items or functions. If items are components, list them in a logical manner under their subsystem/assembly based on the block diagram.
2. Identify Failure Modes. A failure mode is defined as the manner in which a component, subsystem, system, process, etc. could potentially fail to meet the design intent. Examples of potential failure modes include:
   • Corrosion
   • Hydrogen embrittlement
   • Electrical Short or Open
   • Torque Fatigue
   • Deformation
   • Cracking

1. A failure mode in one component can serve as the cause of a failure mode in another component. Each failure should be listed in technical terms. Failure modes should be listed for function of each component or process step. At this point the failure mode should be identified whether or not the failure is likely to occur. Looking at similar products or processes and the failures that have been documented for them is an excellent starting point.
2. Describe the effects of those failure modes. For each failure mode identified the engineer should determine what the ultimate effect will be. A failure effect is defined as the result of a failure mode on the function of the product/process as perceived by the customer. They should be described in terms of what the customer might see or experience should the identified failure mode occur. Keep in mind the internal as well as the external customer. Examples of failure effects include:
   • Injury to the user
   • Inoperability of the product or process
   • Improper appearance of the product or process
   • Odors
   • Degraded performance
   • Noise

Establish a numerical ranking for the severity of the effect. A common industry standard scale uses 1 to represent no effect and 10 to indicate very severe with failure affecting system operation and safety without warning. The intent of the ranking is to help the analyst determine whether a failure would be a minor nuisance or a catastrophic occurrence to the customer. This enables the engineer to prioritize the failures and address the real big issues first.

1. Identify the causes for each failure mode. A failure cause is defined as a design weakness that may result in a failure. The potential causes for each failure mode should be identified and documented. The causes should be listed in technical terms and not in terms of symptoms. Examples of potential causes include:
   • Improper torque applied
   • Improper operating conditions
   • Contamination
   • Erroneous algorithms
   • Improper alignment
   • Excessive loading
   • Excessive voltage

1. Enter the Probability factor. A numerical weight should be assigned to each cause that indicates how likely that cause is (probability of the cause occuring). A common industry standard scale uses 1 to represent not likely and 10 to indicate inevitable.
2. Identify Current Controls (design or process). Current Controls (design or process) are the mechanisms that prevent the cause of the failure mode from occurring or which detect the failure before it reaches the Customer. The engineer should now identify testing, analysis, monitoring, and other techniques that can or have been used on the same or similar products/processes to detect failures. Each of these controls should be assessed to determine how well it is expected to identify or detect failure modes. After a new product or process has been in use previously undetected or unidentified failure modes may appear. The FMEA should then be updated and plans made to address those failures to eliminate them from the product/process.
3. Determine the likelihood of Detection. Detection is an assessment of the likelihood that the Current Controls (design and process) will detect the Cause of the Failure Mode or the Failure Mode itself, thus preventing it from reaching the Customer. Based on the Current Controls, consider the likelihood of Detection using the following table for guidance.
4. Review Risk Priority Numbers (RPN). The Risk Priority Number is a mathematical product of the numerical Severity, Probability, and Detection ratings:
   RPN = (Severity) x (Probability) x (Detection)
   The RPN is used to prioritize items than require additional quality planning or action.
5. Determine Recommended Action(s) to address potential failures that have a high RPN. These actions could include specific inspection, testing or quality procedures; selection of different components or materials; de-rating; limiting environmental stresses or operating range; redesign of the item to avoid the failure mode; monitoring mechanisms; performing preventative maintenance; and inclusion of back-up systems or redundancy.
6. Assign Responsibility and a Target Completion Date for these actions. This makes responsibility clear-cut and facilitates tracking.
7. Indicate Actions Taken. After these actions have been taken, re-assess the severity, probability and detection and review the revised RPN’s. Are any further actions required?
8. Update the FMEA as the design or process changes, the assessment changes or new information becomes known.

 

 

Establish a numerical ranking for the severity of the effect. A common industry standard scale uses 1 to represent no effect and 10 to indicate very severe with failure affecting system operation and safety without warning. The intent of the ranking is to help the analyst determine whether a failure would be a minor nuisance or a catastrophic occurrence to the customer. This enables the engineer to prioritize the failures and address the real big issues first.

1. Identify the causes for each failure mode. A failure cause is defined as a design weakness that may result in a failure. The potential causes for each failure mode should be identified and documented. The causes should be listed in technical terms and not in terms of symptoms. Examples of potential causes include:
   • Improper torque applied
   • Improper operating conditions
   • Contamination
   • Erroneous algorithms
   • Improper alignment
   • Excessive loading
   • Excessive voltage

1. Enter the Probability factor. A numerical weight should be assigned to each cause that indicates how likely that cause is (probability of the cause occuring). A common industry standard scale uses 1 to represent not likely and 10 to indicate inevitable.
2. Identify Current Controls (design or process). Current Controls (design or process) are the mechanisms that prevent the cause of the failure mode from occurring or which detect the failure before it reaches the Customer. The engineer should now identify testing, analysis, monitoring, and other techniques that can or have been used on the same or similar products/processes to detect failures. Each of these controls should be assessed to determine how well it is expected to identify or detect failure modes. After a new product or process has been in use previously undetected or unidentified failure modes may appear. The FMEA should then be updated and plans made to address those failures to eliminate them from the product/process.
3. Determine the likelihood of Detection. Detection is an assessment of the likelihood that the Current Controls (design and process) will detect the Cause of the Failure Mode or the Failure Mode itself, thus preventing it from reaching the Customer. Based on the Current Controls, consider the likelihood of Detection using the following table for guidance.
4. Review Risk Priority Numbers (RPN). The Risk Priority Number is a mathematical product of the numerical Severity, Probability, and Detection ratings:
   RPN = (Severity) x (Probability) x (Detection)
   The RPN is used to prioritize items than require additional quality planning or action.
5. Determine Recommended Action(s) to address potential failures that have a high RPN. These actions could include specific inspection, testing or quality procedures; selection of different components or materials; de-rating; limiting environmental stresses or operating range; redesign of the item to avoid the failure mode; monitoring mechanisms; performing preventative maintenance; and inclusion of back-up systems or redundancy.
6. Assign Responsibility and a Target Completion Date for these actions. This makes responsibility clear-cut and facilitates tracking.
7. Indicate Actions Taken. After these actions have been taken, re-assess the severity, probability and detection and review the revised RPN’s. Are any further actions required?
8. Update the FMEA as the design or process changes, the assessment changes or new information becomes known.

Anticipatory Failure Determination (AFD) is a failure analysis method. Like FMEA, it has the objective of identifying and mitigating failures. Rather than asking developers to look for a cause of a failure mode, it reverses the problem by asking developers to view the failure of interest as the intended consequence and try to devise ways to assure that the failure always happens reliably.

AFD offers an advantage over FMEA for more complex failure analysis in the following way. FMEA relies on failures and their root causes being identified by the application of personal experience or known (documented or applied) knowledge of others. However, the “denial phenomenon” comes into play with this analysis. When we ask “what can go wrong” with respect to a functioning system, we resist thinking about unpleasant possibilities that might occur unless we have actually experienced them and they become real. Even when problems have been experienced, people are reluctant to identify or document those problems. By reversing the problem, AFD overcomes the “denial phenomenon” and opens up creative insights into analysis of failures.

AFD involves the following steps in its process:

1. Formulate or invert the problem. Rather than guessing at possible causes of the failure (how did it happen?), invert the problem to state how to make it happen. Formulate a problem statement by stating the problem in the following way: It is necessary to always produce the failure mode of interest under the conditions that cause the failure. Begin with identifying the conditions leading to the failure. Identify the scenario or events involved in the failure and localize the failure.
2. Search for solutions or methods to produce the failure. Now that the problem has been changed from possible things that can happen to things that need to be produced or happen consistently, the thought process shifts to a inventive method of finding the mechanisms or means of production. Function analysis can be useful to identify a series of functions or actions involved in the failure scenario. This helps to understand the problem as well as help formulate the failure mechanism. By inverting the problem, it is shifted to an issue of invention – how can something be done or how can something be made to occur. TRIZ is a useful technique to identify inventive approaches to making the failure happen. This step should lead to identifying all of the standard ways of creating the failure.
3. Verify that resources are available to cause the failures. There are seven potential categories of resources: substances, field effects, space available, time, object structure, system functions, and other data on the system. For each of the potential solutions, identify if the required resources are available to support the solution (failure).

• Verification & validation. Design verification is testing to assure that the design outputs meet design input requirements. Design verification may include activities such as: design reviews, performing alternate calculations, understanding tests and demonstrations, and review of design documents before release. Validation is the process of ensuring that the product conforms to defined user needs, requirements, and/or specifications under defined operating conditions. Design validation is performed on the final product design with parts that meet design intent. Production validation is performed on the final product design with parts that meet design intent produced production processes intended for normal production.
• Design reviews . Design reviews are formal reviews conducted during the development of a product to assure that the requirements, concept, product or process satisfies the requirements of that stage of development, the issues are understood, the risks are being managed, and there is a good business case for development. Typical design reviews include: requirements review, concept/preliminary design review, final design review, and a production readiness/launch review.
• Control special/critical characteristics. Special/critical characteristics are identified through quality function deployment or other similar structured method. Once these characteristics are understood, and there is an assessment that the process is capable of meeting these characteristics (and their tolerances), the process must be controlled. A control plan is prepared to indicate how this will be achieved. Control Plans provide a written description of systems used in minimizing product and process variation including equipment, equipment set-up, processing, tooling, fixtures, material, preventative maintenance and methods.

Quality must be designed into the product, not inspected into it. Quality can be defined as meeting customer needs and providing superior value. This focus on satisfying the customer’s needs places an emphasis on techniques such as Quality Function Deployment to help understand those needs and plan a product to provide superior value.

Quality Function Deployment (QFD) is a structured approach to defining customer needs or requirements and translating them into specific plans to produce products to meet those needs. The “voice of the customer” is the term to describe these stated and unstated customer needs or requirements. The voice of the customer is captured in a variety of ways: direct discussion or interviews, surveys, focus groups, customer specifications, observation, warranty data, field reports, etc. This understanding of the customer needs is then summarized in a product planning matrix or “house of quality”. These matrices are used to translate higher level “what’s” or needs into lower level “how’s” – product requirements or technical characteristics to satisfy these needs.

While the Quality Function Deployment matrices are a good communication tool at each step in the process, the matrices are the means and not the end. The real value is in the process of communicating and decision-making with QFD. QFD is oriented toward involving a team of people representing the various functional departments that have involvement in product development: Marketing, Design Engineering, Quality Assurance, Manufacturing/ Manufacturing Engineering, Test Engineering, Finance, Product Support, etc.

The active involvement of these departments can lead to balanced consideration of the requirements or “what’s” at each stage of this translation process and provide a mechanism to communicate hidden knowledge – knowledge that is known by one individual or department but may not otherwise be communicated through the organization. The structure of this methodology helps development personnel understand essential requirements, internal capabilities, and constraints and design the product so that everything is in place to achieve the desired outcome – a satisfied customer. Quality Function Deployment helps development personnel maintain a correct focus on true requirements and minimizes misinterpreting customer needs. As a result, QFD is an effective communications and a quality planning tool.

CAPTURING THE VOICE OF THE CUSTOMER

The process of capturing the voice of the customer is described in the papers on Product Definition and Steps for Performing QFD. It is important to remember that there is no one monolithic voice of the customer. Customer voices are diverse. In consumer markets, there are a variety of different needs. Even within one buying unit, there are multiple customer voices (e.g., children versus parents). This applies to industrial and government markets as well. There are even multiple customer voices within a single organization: the voice of the procuring organization, the voice of the user, and the voice of the supporting or maintenance organization. These diverse voices must be considered, reconciled and balanced to develop a truly successful product. One technique to accomplish this is to use multiple columns for different priority ratings associated with each customer voice in the product planning matrix.

Quality Function Deployment requires that the basic customer needs are identified. Frequently, customers will try to express their needs in terms of “how” the need can be satisfied and not in terms of “what” the need is. This limits consideration of development alternatives. Development and marketing personnel should ask “why” until they truly understand what the root need is. Breakdown general requirements into more specific requirements by probing what is needed.

Once customer needs are gathered, they then have to be organized. The mass of interview notes, requirements documents, market research, and customer data needs to be distilled into a handful of statements that express key customer needs. Affinity diagramming is a useful tool to assist with this effort. Brief statements which capture key customer requirements are transcribed onto cards. A data dictionary which describes these statements of need are prepared to avoid any misinterpretation. These cards are organized into logical groupings or related needs. This will make it easier to identify any redundancy and serves as a basis for organizing the customer needs for the first QFD matrix.

In addition to “stated” or “spoken” customer needs, “unstated” or “unspoken” needs or opportunities should be identified. Needs that are assumed by customers and, therefore not verbalized, can be identified through preparation of a function tree. These needs normally are not included in the QFD matrix, unless it is important to maintain focus on one or more of these needs. Excitement opportunities (new capabilities or unspoken needs that will cause customer excitement) are identified through the voice of the engineer, marketing, or customer support representative. These can also be identified by observing customers use or maintain products and recognizing opportunities for improvement.

QFD METHODOLOGY FLOW

The basic Quality Function Deployment methodology involves four basic phases that occur over the course of the product development process. During each phase one or more matrices are prepared to help plan and communicate critical product and process planning and design information. This QFD methodology flow is represented below.

 

 

 

 

 

 

 

PRODUCT PLANNING USING QFD

Once customer needs are identified, preparation of the product planning matrix or “house of quality” can begin. The sequence of preparing the product planning matrix is as follows:

1. Customer needs or requirements are stated on the left side of the matrix as shown below. These are organized by category based on the affinity diagrams. Insure the customer needs or requirements reflect the desired market segment(s). Address the unspoken needs (assumed and excitement capabilities). If the number of needs or requirements exceeds twenty to thirty items, decompose the matrix into smaller modules or subsystems to reduce the number of requirements in a matrix. For each need or requirement, state the customer priorities using a 1 to 5 rating. Use ranking techniques and paired comparisons to develop priorities.
2. 

1. Evaluate prior generation products against competitive products. Use surveys, customer meetings or focus groups/clinics to obtain feedback. Include competitor’s customers to get a balanced perspective. Identify price points and market segments for products under evaluation. Identify warranty, service, reliability, and customer complaint problems to identify areas of improvement. Based on this, develop a product strategy. Consider the current strengths and weaknesses relative to the competition? How do these strengths and weaknesses compare to the customer priorities? Where does the gap need to be closed and how can this be done – copying the competition or using a new approach or technology? Identify opportunities for breakthrough’s to exceed competitor’s capabilities, areas for improvement to equal competitors capabilities, and areas where no improvement will be made. This strategy is important to focus development efforts where they will have the greatest payoff.

1. Establish product requirements or technical characteristics to respond to customer requirements and organize into related categories. Characteristics should be meaningful, measurable, and global. Characteristics should be stated in a way to avoid implying a particular technical solution so as not to constrain designers.
2. Develop relationships between customer requirements and product requirements or technical characteristics. Use symbols for strong, medium and weak relationships. Be sparing with the strong relationship symbol. Have all customer needs or requirement been addressed? Are there product requirements or technical characteristics stated that don’t relate to customer needs?
3. Develop a technical evaluation of prior generation products and competitive products. Get access to competitive products to perform product or technical benchmarking. Perform this evaluation based on the defined product requirements or technical characteristics. Obtain other relevant data such as warranty or service repair occurrences and costs and consider this data in the technical evaluation.
4. Develop preliminary target values for product requirements or technical characteristics.
5. Determine potential positive and negative interactions between product requirements or technical characteristics using symbols for strong or medium, positive or negative relationships. Too many positive interactions suggest potential redundancy in “the critical few” product requirements or technical characteristics. Focus on negative interactions – consider product concepts or technology to overcome these potential tradeoff’s or consider the tradeoff’s in establishing target values.
6. Calculate importance ratings. Assign a weighting factor to relationship symbols (9-3-1, 4-2-1, or 5-3-1). Multiply the customer importance rating by the weighting factor in each box of the matrix and add the resulting products in each column.
7. Develop a difficulty rating (1 to 5 point scale, five being very difficult and risky) for each product requirement or technical characteristic. Consider technology maturity, personnel technical qualifications, business risk, manufacturing capability, supplier/subcontractor capability, cost, and schedule. Avoid too many difficult/high risk items as this will likely delay development and exceed budgets. Assess whether the difficult items can be accomplished within the project budget and schedule.
8. Analyze the matrix and finalize the product development strategy and product plans. Determine required actions and areas of focus. Finalize target values. Are target values properly set to reflect appropriate tradeoff’s? Do target values need to be adjusted considering the difficulty rating? Are they realistic with respect to the price points, available technology, and the difficulty rating? Are they reasonable with respect to the importance ratings? Determine items for further QFD deployment. To maintain focus on “the critical few”, less significant items may be ignored with the subsequent QFD matrices. Maintain the product planning matrix as customer requirements or conditions change.

One of the guidelines for successful QFD matrices is to keep the amount of information in each matrix at a manageable level. With a more complex product, if one hundred potential needs or requirements were identified, and these were translated into an equal or even greater number of product requirements or technical characteristics, there would be more than 10,000 potential relationships to plan and manage. This becomes an impossible number to comprehend and manage. It is suggested that an individual matrix not address more than twenty or thirty items on each dimension of the matrix. Therefore, a larger, more complex product should have its customers needs decomposed into hierarchical levels.

To summarize the initial process, a product plan is developed based on initial market research or requirements definition. If necessary, feasibility studies or research and development are undertaken to determine the feasibility of the product concept. Product requirements or technical characteristics are defined through the matrix, a business justification is prepared and approved, and product design then commences.

CONCEPT SELECTION AND PRODUCT DESIGN

Once product planning is complete, a more complete specification may be prepared. The product requirements or technical characteristics and the product specification serve as the basis for developing product concepts. Product benchmarking, brainstorming, and research and development are sources for new product concepts. Once concepts are developed, they are analyzed and evaluated. Cost studies and trade studies are performed. The concept selection matrix can be used to help with this evaluation process.

The concept selection matrix shown below lists the product requirements or technical characteristics down the left side of the matrix.

 

 

 

 

 

 

These serve as evaluation criteria. The importance rating and target values (not shown) are also carried forward and normalized from the product planning matrix. Product concepts are listed across the top. The various product concepts are evaluated on how well they satisfy each criteria in the left column using the QFD symbols for strong, moderate or weak. If the product concept does not satisfy the criteria, the column is left blank. The symbol weights (5-3-1) are multiplied by the importance rating for each criteria. These weighted factors are then added for each column. The preferred concept will have the highest total. This concept selection technique is also a design synthesis technique. For each blank or weak symbol in the preferred concept’s column, other concept approaches with strong or moderate symbols for that criteria are reviewed to see if a new approach can be synthesized by borrowing part of another concept approach to improve on the preferred approach.

Based on this and other evaluation steps, a product concept is selected. The product concept is represented with block diagrams or a design layout. Critical subsystems, modules or parts are identified from the layout. Criticality is determined in terms of effect on performance, reliability, and quality. Techniques such as fault tree analysis or failure modes and effects analysis (FMEA) can be used to determine criticality from a reliability or quality perspective.

The subsystem, assembly, or part deployment matrix is then prepared. The process leading up to the preparation of the deployment matrix is depicted below.

 

 

 

 

 

The product requirements or technical characteristics defined in the product planning matrix become the “what’s” that are listed down the left side of the deployment matrix along with priorities (based on the product planning matrix importance ratings) and target values. The deployment matrix is prepared in a manner very similar to the product planning matrix. These product requirements or technical characteristics are translated into critical subsystem, assembly or part characteristics. This translation considers criticality of the subsystem, assembly or parts as well as their characteristics from a performance perspective to complement consideration of criticality from a quality and reliability perspective. Relationships are established between product requirements or technical characteristics and the critical subsystem, assembly or part characteristics. Importance ratings are calculated and target values for each critical subsystem, assembly or part characteristic are established. An example of a part/assembly deployment matrix is shown:

 

 

 

 

 

PROCESS DESIGN

Quality Function Deployment continues this translation and planning into the process design phase. A concept selection matrix can be used to evaluate different manufacturing process approaches and select the preferred approach. Based on this, the process planning matrix shown below is prepared.

 

 

 

 

 

Again, the “how’s” from the higher level matrix (in this case the critical subsystem, assembly or part characteristics) become the “what’s” which are used to plan the process for fabricating and assembling the product. Important processes and tooling requirements can be identified to focus efforts to control, improve and upgrade processes and equipment. At this stage, communication between Engineering and Manufacturing is emphasized and tradeoff’s can be made as appropriate to achieve mutual goals based on the customer needs.

In addition to planning manufacturing processes, more detailed planning related to process control, quality control, set-up, equipment maintenance and testing can be supported by additional matrices. The following provides an example of a process/quality control matrix.

 

 

 

 

The process steps developed in the process planning matrix are used as the basis for planning and defining specific process and quality control steps in this matrix.

The result of this planning and decision-making is that Manufacturing focuses on the critical processes, dimensions and characteristics that will have a significant effect on producing a product that meets customers needs. There is a clear trail from customer needs to the design and manufacturing decisions to satisfy those customer needs. Disagreements over what is important at each stage of the development process should be minimized, and there will be greater focus on “the critical few” items that affect the success of the product.

QFD PROCESS

Quality Function Deployment begins with product planning; continues with product design and process design; and finishes with process control, quality control, testing, equipment maintenance, and training. As a result, this process requires multiple functional disciplines to adequately address this range of activities. QFD is synergistic with multi-function product development teams. It can provide a structured process for these teams to begin communicating, making decisions and planning the product. It is a useful methodology, along with product development teams, to support a concurrent engineering or integrated product development approach .

Quality Function Deployment, by its very structure and planning approach, requires that more time be spent up-front in the development process making sure that the team determines, understands and agrees with what needs to be done before plunging into design activities. As a result, less time will be spent downstream because of differences of opinion over design issues or redesign because the product was not on target. It leads to consensus decisions, greater commitment to the development effort, better coordination, and reduced time over the course of the development effort.

QFD requires discipline. It is not necessarily easy to get started with. The following is a list of recommendations to facilitate initially using QFD.

• Obtain management commitment to use QFD.
• Establish clear objectives and scope of QFD use. Avoid first using it on a large, complex project if possible. Will it be used for the overall product or applied to a subsystem, module, assembly or critical part? Will the complete QFD methodology be used or will only the product planning matrix be completed?
• Establish multi-functional team. Get an adequate time commitment from team members.
• Obtain QFD training with practical hands-on exercises to learn the methodology and use a facilitator to guide the initial efforts.
• Schedule regular meetings to maintain focus and avoid the crush of the development schedule overshadowing effective planning and decision-making.
• Avoid gathering perfect data. Many times significant customer insights and data exist within the organization, but they are in the form of hidden knowledge – not communicated to people with the need for this information. On the other hand, it may be necessary to spend additional time gathering the voice of the customer before beginning QFD. Avoid technical arrogance and the belief that company personnel know more than the customer.

Quality Function Deployment is an extremely useful methodology to facilitate communication, planning, and decision-making within a product development team. It is not a paperwork exercise or additional documentation that must be completed in order to proceed to the next development milestone. It not only brings the new product closer to the intended target, but reduces development cycle time and cost in the process.