Copyright1988-2008QFDcapture Website

QFD Basics

What is QFD?

Quality Function Deployment (QFD) is a systematic process for motivating a business to focus on its customers. It is used by cross-functional teams to identify and resolve issues involved in providing products, processes, services and strategies which will more than satisfy their customers. A prerequisite to QFD is Market Research. This is the process of understanding what the customer wants, how important these benefits are, and how well different providers of products that address these benefits are perceived to perform. This is a prerequisite to QFD because it is impossible to consistently provide products which will attract customers unless you have a very good understanding of what they want.

Why use QFD?

Once a team has identified the customers' wants, QFD is used for two fundamental reasons:

  • To improve the communication of customer wants throughout the organization.
  • To improve the completeness of specifications and to make them traceable directly to customer wants and needs, QFD requires that representatives of the different organizations involved in producing the product be involved in its definition. Consequently, these representatives discuss the meaning of the customer wants and work together to ensure that they come to a common understanding. Communications throughout the organization is greatly improved. This process will also uncover many issues whose resolution will lead to a more complete specification.

    What are some approaches to QFD?

    There are many different approaches to QFD:

  • The Four-Phase approach uses a QFD Matrix to translate Customer Wants into Product Characteristics. The Product Characteristics are then translated through another QFD Matrix into Part Characteristics. Part Characteristics are translated into Process Characteristics. Finally, Process Characteristics are translated into Production Controls.
  • The Matrix of Matrices approach was developed by GOAL/QPC and is used to address a wide variety of development issues. It identifies specific matrices which should be used to address specific development issues. This approach is best described in a book titled "Better Designs in Half the Time"; available from GOAL/QPC.
  • The International TechneGroup, Inc. (ITI) QFD approach for Concurrent Product/Manufacturing Process Development was developed to support ITI's work in helping corporations to implement Concurrent Engineering practices. It involves evaluating the wants and needs from all different types of customers. It also integrates the principles of concept selection to help development teams to objectively evaluate alternatives.
  • There are many other approaches. In fact, the flavor of QFD is often what differentiates one consultant from another. However, almost everyone agrees that for QFD to be successfully implemented within an organization, it must be adapted to the particular situation surrounding its use. QFD/CAPTURE was designed to support all of these approaches and more.

    What are the basic tools of QFD?

    The basic tools of QFD are Project Roadmaps, Documents, Lists and Matrices. A Project Roadmap defines the flow of data through a QFD project. Documents record background information for a project. A Matrix is simply a format for showing the relationships between two or more Lists. Lists form the input rows and output columns of the Matrices. Examples of Lists include: User Benefits, Measures, Basic Expectations, Functions, and Alternative Concepts. Lists generally have other Related Data associated with them. For example, the priorities and perceived performance ratings resulting from Market Research would be associated with the List of Benefits. Importance values would also be associated with Measures and Functions. Matrices are used to relate two or more Lists to each other, thus deploying or transferring the importance from the input lists to the output lists. For example, a common Matrix relates Measures to User Benefits. Another Matrix could be used to relate Measures to both User Benefits and Basic Expectations. Matrices are a flexible tool which can be configured to the particular needs of each project.




    Capturing Market Data

    How do we define Customers?

    There are many different ways to identify the Customers of a product or service. A commonly used approach is to ask the team "Who must be satisfied with the product in order for the product to be considered successful?" Typically, a team will identify the following customer groups:

  • Users who are mainly concerned with functionality.
  • Management who is mainly concerned with financial and strategic issues.
  • Distribution and Purchasing Agents who are concerned with purchase transaction and availability issues.
  • Internal workers who are concerned with how the product will affect the quality of their work life. Each of these customer groups will tend to have different and , at times, conflicting requirements. Therefore, it is recommended that each customer group be assigned a priority by the team. Then, if a compromise is required between the different customer groups' requirements, it can be agreed upon somewhat objectively. QFD/CAPTURE supports the definition of different customer groups in the following ways:
  • The team may capture its customer list and the rationale for selecting the different customer groups as a document.
  • The team may capture a different set of requirements for each customer group.
  • The team can define a separate Matrix for each customer group. It is recommended that each Matrix compare the complete set of Measures against the list of requirements which are unique to each customer group.
  • The different customer groups can be weighted relative to each other so that requirements from an important customer group are given more weight than requirements from a less important customer group.

  • How do we capture our Customers' Requirements?

    A fundamental principle of QFD is to determine directly from the customer what they would like a particular product or service to do. There are many different approaches to achieve this goal. They include:

  • One on one customer interviews
  • Focus groups
  • In-context customer visits
  • Interviews are useful because they allow you to effectively probe for detail. Focus groups are productive because they allow you to develop a lot of creative ideas by having the participants build upon one another's comments. In-context customer visits allow team members to actually observe how customers use existing products or perform existing functions and can lead to a dramatically improved understanding of what the customer really needs. All of these approaches will yield the basis for a list of what the customer is seeking. This list can then be entered into QFD/CAPTURE in the form of a Requirements List.

    How do we capture Importance to the Customers?

    QFD, as a process, yields the most effective results when the team focuses on the requirements which are most critical to the success of the product they are developing. Customers can help this process by telling the team which requirements are the most important to them when they are considering the purchase of a product in which several competing products exist. Importance to the Customer is often gathered through "forced choice" surveys, which requires the person being surveyed to identify the relative importance of each of the requirements. There are many different methods which yield varied quality of results. Teams are encouraged to investigate Conjoint Analysis, The Analytical Hierarchy Process, and Forced Choice Prioritization methods. It is recommended that a reputable Market Research firm with experience in doing quantitative research for QFD be consulted. Importance values are captured within QFD/CAPTURE by defining a column of Related Data in the List Window.

    How do we capture the Customers' Perceptions of Performance?

    A QFD team can learn a lot by asking customers, "How well do existing products satisfy these requirements?" Ideally, a customer would be familiar with multiple providers of competitive products. The team could then look at these Perceived Performance Ratings and try to determine why certain products were perceived to do well while other products were perceived to perform poorly. This information leads to an increased understanding of what would attract customers to the product currently being designed. Teams are encouraged to consult with a reputable Market Research firm which is familiar with the unique needs of the QFD process in order to gather this information. Perceived Performance values are captured within QFD/CAPTURE by defining a column of Related Data to contain the performance ratings for each product being examined. This is done within the appropriate List Window.

    How do we capture Customer Satisfaction Data?

    Customer Satisfaction Data is often used in place of Perceived Performance Data and is captured within QFD/CAPTURE in the same way. You should be aware of a common trap. If you are using existing customer satisfaction data, be sure that the requirements used to generate the Customer Satisfaction Data are good requirements from the QFD perspective and that the ratings indicate buying preference. Otherwise, the data may not produce useful results for the QFD project.




    Prioritizing Requirements

    What should we use to prioritize Requirements?

    Requirements are not always prioritized strictly based upon the importance which the Customers attach to each requirement. Often, the team wants to adjust the priorities of the requirements to account for the amount of work required to improve the customers' perceptions. Other teams will incorporate a factor to indicate where the company thinks the market is headed. Still other teams want to perform Gap Analysis and add additional importance to those requirements where there is a large gap between the importance that a customer attaches to a requirement and the level of satisfaction which most customers experience relative to that requirement. All of these different methods of Prioritization involve defining calculations in the Related Data associated with a List of Requirements. The following examples will illustrate these prioritization methods. If the team wants to incorporate an indication of the amount of effort required to improve a product's performance in the eyes of the customer, they might set up Related Data columns as follows:

  • Importance to the Customer
  • Our Current Product
  • Competitor One
  • Competitor Two
  • Our Future Product
  • Improvement Factor
  • Overall Importance
  • Percent Importance
  • The Importance to the Customer column would contain the importance ratings as given by the customers. The data in the Our Current Product, Competitor One, and Competitor Two columns would contain Perceived Performance Ratings given by the customers which indicate how well they think the named products perform against the listed requirements. The data in the Our Future Product column is set by the team to indicate their positioning strategy. The change from Our Current Product to Our Future Product is an indication of the amount of work required to change the level of Perceived Performance and is generally calculated and stored as the Improvement Factor. Two approaches to this calculation are supported in QFD/CAPTURE.

  • The traditional calculation is the ratio of Our Future Product ratings to the Our Current Product ratings.
  • Another calculation which is starting to be more widely used is a simple indication of how much of the rating scale must be climbed to go from Our Current Product ratings to Our Future Product ratings.
  • The Overall Importance column contains the product of the Importance to the Customer and the Improvement Factor. Its values indicate where the team should focus attention in order to address what is important to the customer and where they have to do a lot of work. The Percent Importance column simply contains the Overall Importance values translated into percentage values.

    If the team wanted to include its guess as to what would be more important in the future, it could incorporate an Importance Growth Factor into the Related Data described above. The values in the Importance Growth Factor would be the percent change in the importance which is anticipated in the time frame of the project. For example, an Importance Growth Factor of 1.3 would indicate that the team expects the importance of that requirement to increase 30 percent in the time frame of the project. The Overall Importance column would now be set up to be the product of Importance to the Customer, Improvement Factor, and the Importance Growth Factor.
    If the team wanted to use Gap Analysis as a means of prioritizing the requirements, they might set up the Related Data columns as follows:

  • Importance to the Customer
  • Level of Customer Satisfaction
  • Gap Importance
  • Percent Importance The Importance to the Customer is the same as described above. The Level of Customer Satisfaction column contains ratings from the customer which indicate how satisfied they are with the current approach to fulfilling the requirements. The Gap Importance is a calculation of the form:
  • Gap Importance =

  • Importance to the Customer +
    (Importance to the Customer - Level of Customer Satisfaction)
    This calculation applies additional importance to those requirements where the customer is less satisfied than they ought to be. It is not a particularly rigorous calculation mathematically. However, it makes sense subjectively. The Percent Importance is a conversion of the Gap Importance into percentages.
  • How should we define our Strategy?

    Product Positioning Strategy is generally defined after considering the importance of each requirement relative to the others on the list. It also accounts for the perceived performance ratings given by the customer. The strategy ratings are generally captured in a Related Data column called Future Product. The rationale for setting strategy generally follows these guidelines:

  • If the requirement is important and your product is perceived to perform worse than the other products on the market, set a stretch goal to get at least to the level of perceived performance experienced by the market leaders.
  • If the requirement is important and your product is leading the marketplace in perceived performance, at least maintain that level of performance. Also, consider what could be done to "blow the top off the scale" as a way of clearly differentiating your product from any competition.
  • If the requirement is not very important, consider maintaining or even reducing perceived performance in the product since the customers do not make their decisions with much consideration relative to this requirement.
  • How should we include our Sales Factors?

    When prioritizing the requirements, some teams want to include a factor to indicate that additional importance should be given to particular requirements. In a way, the importance of these requirements is underestimated by Customers because they do not understand the benefit which would be provided if the requirement were satisfied. The factor used to indicate this additional importance is known as the Sales Factor. Sales Factors or Sales Points are defined in a column of Related Data associated with a list and act as multipliers in calculating the overall importance of each requirement. The traditional ratings are:

  • 1.0 We will not be emphasizing this requirement in our Marketing efforts
  • 1.2 We will mention this in our Marketing Literature
  • 1.5 We will emphasize satisfaction of this requirement in our Marketing efforts. It should be cautioned that there is tremendous potential for abusing this rating and it should therefore be used very carefully.
  • What does this information tell us?

    The information used to prioritize the Requirements is some of the most interesting and important information collected during the QFD process. The results of the QFD project start to become apparent once the team begins sorting the data to look at it from many different perspectives. The following are just some of the issues which can be answered by closely examining the prioritization data:

  • What does the customer think is most important?
  • Answer this question by sorting the List of Requirements by the data in the Importance to the Customer column.
  • What are our strengths and weaknesses in the Marketplace?
  • Answer this question by defining two calculations in the Related Data. First of all, define a Related Data column called Maximum Perceived Performance Rating. Set it up to calculate the Maximum Rating for each requirement found in the Perceived Performance ratings columns. Secondly, create a Related Data column called Performance Gap. Set this up to subtract the ratings of your product from the Maximum Perceived Performance Rating values. Sort the List based upon the values in this column in descending order. The Requirements where you are perceived to be weakest will be at the top of the list.
  • Where are we positioning ourselves?
  • Answer this question by sorting the List of Requirements by the data in the Our Future Product column. The Requirements at the top of the list will be those where we want to achieve the best performance.
  • Where do we have to do the most work?
  • Answer this question by sorting the List of Requirements by the data in the Improvement Factor column. The Requirements at the top of the list will be those for which the customer's perception needs to change the most.
  • Where should we focus our attention?
  • Answer this question by sorting the List of Requirements by the data in the Percent Importance column. The Requirements at the top of the list will be those on which we should focus in order to provide what the customers most want and to implement our product strategy.



    Measuring the Design

    Why define Design Measures?

    Often, Customer Requirements are very subjective statements of the benefits which a Customer is seeking from a product. Though the team members may think they are in near total agreement about the meaning of a particular statement, the individuals on a team are often interpreting the statements in very different ways. This difference of interpretation often does not become evident until the team attempts to define ways to satisfy the Requirements. The process of translating Customer Requirements into Design Measures is a way to force the team to define, using measurable and actionable statements, exactly what each Requirement means in the language of the organization. For example, let's say that a Customer Requirement for a software package is "Is easy to use". The programmers would be left to their own interpretation as to whether their software would really satisfy their Customers. On the other hand, through the QFD process, a team might define the following Measures for "Is easy to use":

  • User rating of screen layout concepts
  • Number of user operations required to perform the desired functions
  • Number of different input devices required to perform the desired functions These Measures reflect the team's interpretation of what makes software easy to use. They believe that the screens have to be well laid out. They also believe that Customers should not have to perform a lot of operations to get useful work accomplished and those operations should not require that Customers move their hands between input devices (i.e.: mouse and keyboard). Unfortunately, there are no standards relative to what comprises a good Measure. Some guidelines that have proved useful include:
  • Be Measurable on the Design - If it can only be measured after the product is on the market, it won't help the team design a better product.
  • Be Controllable - If the team cannot adjust the value of a Measure through design decisions, they will not be able to improve the design.
  • Be Implementation Independent - If a Measure is only applicable for a particular design approach, it may tend to force the team away from other, more satisfactory approaches.
  • Have a Preferred Direction of Improvement - The team should be able to determine if the product will better satisfy the Customer if the Measure is increased or decreased. There are also many different types of Measures. They include:
  • Objective Measurements - These are unambiguous measurements like Length, Volume, Number of Steps, and Times.
  • Indices - These are combinations of two or more Objective Measurements. For example, the Heat Index is an empirical rating which factors together temperature and humidity.
  • Jury Evaluations - These are ratings by an unbiased group of representative customers concerning how well something works aesthetically. These deal mainly with subjective aesthetic issues such as taste or appearance.
  • Percent of Desired List - These are used to document a subset of capabilities out of the entire "Desired List" that are to be included in the design. QFD/CAPTURE allows you to capture the Measures and the data related to the Measures within List Windows.
  • How should we define our Design Measures?

    There are two main approaches to defining Measures. The most common approach is to brainstorm all of the possible Measures while reviewing the list of Requirements. This comprehensive list is then captured in a QFD/CAPTURE List Window. Relationships between the Measures and the Requirements are then defined using a Spreadsheet view in the Matrix Window Another approach, which is starting to be widely used, is to make use of a Tree analogy. A Requirement is treated as the trunk of a tree. The team then Brainstorms the Measures needed to address that particular Requirement. The Measures are recorded as Branches of the tree. For easier reading, the Tree is generally drawn sideways. QFD/CAPTURE supports this method of definition via the Tree view in the Matrix Window.

    What other information can we relate to Customer Requirements?

    It should be noted that Measures are only one type of information which can be related to Customer Requirements. Other types of information can also be recorded within Lists and be effectively related to Requirements. Some examples include:

  • Customer Characteristics could be defined and related to Requirements to indicate which Customer Characteristic would tend to lead a Customer to have a particular Requirement. This could lead into Market Segmentation.
  • Design Alternatives could be directly related to Customer Requirements in order to understand which Design Alternative would best satisfy the raw Customer Requirements. More commonly, Design Alternatives are directly related to Measures rather then to Customer Requirements.
  • Product Functions could be defined and related to Customer Requirements in order to determine the Relative Value of a Function towards satisfying the Customer Requirements.
  • Product Parts or Assemblies could be defined and related to Customer Requirements in order to determine the value of Parts relative to supplying Customer Satisfaction. If a Part provides less value, in the eyes of the Customer, than it costs to produce, then it is a good candidate for Cost Reduction efforts.
  • Product or Process Failure Modes could be related to Customer Requirements in order to better understand which Failure Modes are most critical relative to meeting Customer Requirements.
  • In general, a Matrix can be thought of as the set of relationships between an Input List and an Output List. Customer Requirements are just one of many types of Input Lists. Any set of data for which the team would like to understand the relationship with Customer Requirements would be a valid Output List.




    Defining Relationships

    Why define Relationships between Lists?

    Relationships between Lists indicate how the two lists are related to each other. They are generally used to prioritize one List based upon the priorities of another list. Relationships can be defined by answering a particular question for each cell in a Matrix. For example, the Relationships between Customer Requirements and Design Measures might be defined by asking "To what degree does this Measure predict the Customer's Satisfaction with this Requirement?" By asking this same question consistently for each Measure and Requirement combination, a set of Relationships will be defined in the Matrix which will help to determine which Measures are most important to control in order to achieve a desired level of Customer Satisfaction. Another question which can be asked in order to define Relationships is "What percent of this Requirement is handled by this Design Measure? The Relationships defined using this question would result in the highest priority being assigned to the Measures which control most of the functionality. These may not be the same as the Measures defined in order to predict Customer Satisfaction. Given these examples, you can see that it is critical that a team understand what question they are trying to answer before they start defining Relationships. It is also critical that they use the same question consistently. By doing so, the team will be able to prioritize the Output List accurately.

    How can Relationships be defined?

    Relationships are defined within the Matrix Window of QFD/CAPTURE. There are two different methods of defining the Relationships. The Spreadsheet View provides a familiar format for entering the relationship values. The Tree View provides a snapshot of the Relationship values for each Input row, and makes it easier to assess each Relationship's value relative to the other Relationships. The Spreadsheet View presents the Lists being related in a Spreadsheet format. The entries in the Input Lists form the row headings and the entries in the Output Lists form the column headings. The cells within the spreadsheet contain the relationships between the Input and Output entries. The Tree View presents all of the Output List Entries which are related to the currently selected Input List Entry using a Tree structure. This allows the team to consider the relative strength of the Relationships. It is equivalent to defining an entire row of relationships across a Matrix.

    What scales should we use?

    The scales used to define the relationships can have a significant impact on the Prioritization of the Output List Entries. The main consideration is the tradeoff between the number of levels in a scale, the speed of relationship definition, and the relative accuracy of the resulting Prioritization. In general, the more levels in the scale, the more accurate the relative prioritization. The different values of the scale allow the team to indicate the levels of relationships that the Output List Entries have with the Input List Entries. For example, the team may choose to use relationships with values of 1 through 10. Using this scale a value of 6 would indicate that one Output List Entry is twice as important to the satisfaction of an Input List Entry as an Output List Entry with a value of 3. Relationship definition usually goes much faster if the team limits their choices of Relationship values to just a few. Standard QFD practice usually supports the values 1, 3, and 9. This Standard QFD Scale accentuates the Strong Relationships (value of 9). Output List Entries with several Strong Relationships to Input List Entries will tend to be given a higher level of priority than Output List Entries related to many Input List Entries with either moderate or weak values. Other common scales include 1, 2, 3 and 1, 3, 5. With greater frequency, teams are defining relationships using advanced methods such as the Analytic Hierarchy Process to establish scales with an infinite number of levels. The resulting relationship values usually represent the percent contribution of each Output List Entry to the selected Input List Entry. QFD/CAPTURE supports all of these different scales. Each time a new matrix is created, the user is given the opportunity to specify which of the standard scales will be used for the relationships. You may define your own unique scales as well. The software will also allow the team to define relationship values as real numbers that represent percentages.





    Identifying Tradeoffs

    Why evaluate Tradeoffs?

    The tradeoffs, located in the "Roof" of the House of Quality, indicate the synergistic or detrimental impacts of changes in the Design Measures. They are used to identify critical compromises in the design. Since these compromises are likely to be encountered sooner or later, they may as well be examined as part of the QFD effort so that any required design changes are as inexpensive as possible.

    How should we evaluate Tradeoffs?

    As with other matrices, the team should agree upon the question that they will ask in order to define the Relationships of this Matrix. A common question used is "If we improve our performance against this Measure, what is the impact on this other Measure? The team will determine if improving performance of one Measure helps or hurts the product's performance against another Measure. Generally, positive and negative values are used to indicate the positive or negative impact. The Tradeoffs Scale provided by QFD/CAPTURE can be used as a scale for Relationships defined within this Matrix. QFD/CAPTURE allows a team to capture the tradeoffs it identifies. A matrix is created to capture the tradeoff information. One list forms both the input and the output of the matrix.

    How should we document Actions?

    If a tradeoff is identified, there is usually some Action which is required in order to reduce the impact or work around the potential compromise. These Actions can be documented in several ways. One approach is to create a document within QFD/CAPTURE and record each action as a paragraph within the document. Another approach would be to define a List of Actions. This would give the team the opportunity to relate Actions with the Customer Requirements, Design Measures, or any other List defined in the project. This approach would support prioritization of the Actions based upon their affect on the satisfaction of the related Input List.





    Why Benchmark?

    One of the prime reasons for using QFD is to develop a product or service which will excite the customer and get him/her to purchase your product. When a team captures the customer's perceptions of how well different products perform in the marketplace, the team can better understand what is driving the purchase decision. They are able to determine what the market likes and dislikes. However, they are really still dealing with Customer Perceptions and not actual performance. They have not necessarily learned what they, as a team, have to do to create the desired level of Perceived Performance. Benchmarking your own, and others', products against the Design Measures which the team has established helps to define the level of Real Performance required to produce the desired level of Perceived Performance. It also helps you to answer the following questions:

  • Has the team defined the right Measures to predict Customer Satisfaction?
  • Does the product have perception, as opposed to, technical problems?
  • Benchmarking is a relatively expensiveand time consuming process in most industries. Therefore, it is recommended practice to Benchmark only against the critical Design Measures. Criticality is defined by how important a particular Measure is to the success of the product and whether there are special circumstances impacting a particular Measure. A special circumstance might include whether a particular Measure is new or complex. Typically, a team might only Benchmark 50 percent of the Design Measures. Sorting the List of Design Measures based upon their importance values is a good way to identify which Measures to Benchmark.

    Who should we Benchmark?

    Generally, teams Benchmark the same products or services for which they captured performance perceptions. In this way, they can try to correlate Actual Performance with the Perceived Performance. A good policy is to Benchmark products across the whole spectrum of performance. In this way, it becomes much clearer what level of performance is perceived to be inadequate, what level is acceptable, and what level of performance currently gets customers excited about a product. Benchmarking all of the competitive products is not required; just check representative products.

    How do we capture the results of Benchmarking?

    There are two schools of thought relative to capturing Benchmark Results. The first suggests that the team capture the raw Benchmark data directly and associate that data with the appropriate Measure. The other suggests that the team translate the raw Benchmark data into the same scale as was used to capture the perceived performance ratings. Capturing the raw data and using it directly through the process tends to make it easier to understand exactly how well a product has to perform in order to achieve a desired level of customer satisfaction. However, the raw data sometimes implies too much precision for the process. For example, if the team were Benchmarking "Number of Commands Required to Perform the Desired Functions" as a way of predicting whether a software package would be perceived to be "Is easy to use", they could easily get caught up in counting precise numbers when, in reality, "Less than 10", "10 to 20", and "More than 20" might be sufficiently accurate for the purposes of the team. On the other hand, translating the raw Benchmark data into the same rating scale as was used to capture perceived performances forces the team to repeatedly translate those ratings back into their original values. This tends to make nuances in the data disappear and be lost from consideration. However, since only numeric rating data is captured with this approach, QFD/CAPTURE could graph this data. QFD/CAPTURE supports both of these approaches. The general process is to define Related Data columns for the list whose entries are to be Benchmarked. Each column would represent a particular product. If the raw data is to be captured, the team would configure the Related Data columns to contain text so that they could enter any type of data and units which are appropriate. If they instead want to capture the ratings, they would configure the columns to contain numbers only.




    Setting Target Values

    How should we set our Target Values?

    The final goal of many QFD projects is to set the Target Values for the Design Measures. This step occurs when the data gathered throughout the process is brought together and final decisions are made to answer the question "What are we really going to do (with respect to this product or service)?" Setting Target Values should be relatively easy because:

  • The team has already defined where they want their product to be positioned for the Customer.
  • The team has Benchmarked the existing products to gain a good understanding of what level of actual performance is required in order to produce the desired level of perceived performance.
  • The team has evaluated the Tradeoffs between Design Measures in order to determine what compromises may be required and how those compromises would be made.
  • Taking into account all of this information, the team decides upon the Targets which they will shoot for. Normally at this point, the team would not decide how they are going to achieve the Target Values. They are just stating, "we know that we have to achieve this level of performance if we are going to be perceived the way in which we want to be perceived." Deciding on the implementation approach will generally occur during the Conceptualization process. QFD/CAPTURE supports setting Targets for a List through the Related Data columns associated with that List. Generally, a separate column is defined for each release which is being planned. For example, if a new product were going to be released in 1996 and followed up with enhancements in 1997 and 1998, the team would create a separate Related Data column for each year. This would allow the team to show the progression of product performance over the life of the Product. This implies a long term planning perspective rather than just a short term, get-it-out-the-door, perspective. Since Target data is generally textual, these columns would be configured to display Text (as opposed to just numeric data).




    Design Concepts

    Why evaluate Alternative Concepts?

    When a team is assigned to develop a product or service, there is a strong inclination to quickly lock onto a particular approach and not seriously consider any others. These approaches, or Design Concepts, define the ways the team could implement the product or service. As the team develops the detailed design of the product, much of the time is spent modifying and refining the concept. Not all concepts are equally good. Some concepts are extremely sensitive to the environment in which they have to operate and will only demonstrate the ability to perform as required when very specific conditions prevail. Other concepts exhibit a robustness that allows them to operate under a wide variety of conditions. A team should seek robust concepts as a way of ensuring adequate performance of the product under all conditions in which it will operate. If a product is implemented using a concept that is not robust, it is vulnerable to attack, in the marketing sense, from a product which is more robust and efficient. The key to eliminating this vulnerability is to evaluate alternative concepts against good, comprehensive Measures in order to determine which concept will be able to provide the desired Benefits with the minimum effort.

    How do we develop Alternative Concepts?

    There are several different approaches to identifying and defining Alternative Concepts. Each approach should be considered to ensure that you have examined a wide enough set of Alternatives. Competitors are a great source of ideas for Alternative Concepts. Most products, which currently address the same set of benefits as your product, have probably taken slightly different design approaches. The team should examine each approach to determine whether the approach merits emulation or can be improved upon. When the team asks its customers what they want in a product or service, the customers often respond in terms of solutions. While most of these solutions will be fairly obvious, there will probably be a few that you never considered. These few acorns can spawn some very good ideas. After all, the customers are working with the product on a frequent basis in the environment where the product really has to perform. Management's ideas also need honest consideration. If management's ideas are not considered, in good faith, the team is setting itself up for a difficult time in getting their chosen concept approved. The team itself should also spend some time dedicated to brainstorming some creative alternative approaches to providing the Benefits. One proven method is to assign each team member to identify one approach which they will champion during team discussions. In this way, the team is motivated to understand the ideas which they have brainstormed to a level of detail which makes it feasible to compare the alternatives. The last approach to identifying and developing Alternative Concepts is the detailed analysis of the Design Measures to be used as selection criteria. The team evaluates how it could achieve the required Target Value for each Measure. A table is created with different design Concepts forming the columns and the approaches for each Measure forming the rows. For example, if we were identifying Alternative Concepts for a new watch, we might generate the following table:

    Selection Criterion Target Value Concept 1 Concept 2  Concept 3
    Number and Type of desired Alarms Beep, Vibrate, Display Flash Beep, Display Flash, Chime  Chime, Vibrate, Voice
    Duration of Illumination During all operations with two second decay  Slow decay LED Light Backlight with wait circuit  Florescent watch face
    Time to complete Standard Operations Suite Maximum of 4 seconds Single button menu  Dual button menu Three button menu 

  • The columns of this table would then be examined and rearranged by the team to identify a series of viable Alternative Concepts. Remember, only those alternatives able to achieve all of the target values are considered viable.
  • How should we choose the best Concept?

    The Concept that provides the required level of performance, most reliably and at the lowest cost is, by definition, the Best Concept. The Best Concept is identified by evaluating the Alternative Concepts against the objective Measures. A widely accepted process for selecting the Best Concept, is a modification of the Selection Process developed by Stuart Pugh. This matrix oriented process uses the Measures as Selection Criteria against which the Alternative Concepts are evaluated. The team selects a Baseline Concept. A relative comparison is made between the Baseline and the other Concepts for each of the Selection Criteria. If the Alternative Concept rates better than the Baseline, a Plus sign is entered into the cell at the intersection of the Measure's row and the Concept's column. Whereas, a Minus sign is entered, for those Alternative Concepts that rate worse than the Baseline. A Star is entered to indicate the two concepts have equivalent performance. After the relative performance has been evaluated, the overall performance of the Alternative Concepts is calculated by using a weighted sum of the relationships. The relationships are weighted by the importance of the Selection Criteria. Often, multiple iterations of this process are performed using different Baseline Concepts. An alternative way to select a Baseline is to identify the strong points of two or more concepts and create a new Super Concept. This can be a very powerful process! QFD/CAPTURE supports the Concept Selection symbol set and calculations. Select this symbol set when you create a new concept selection Matrix. 




    Defining Actions

    What should we do as the result of this QFD project?

    One of the most common problems encountered by QFD teams is that they do not know what to do with the results of a QFD study. This is largely because they did not know what they wanted the study to do for them to begin with. To avoid this problem, it is wise to define up-front exactly what the team wants to accomplish with the QFD project. For example, a perfectly valid result is "to develop a comprehensive Product Specification and to select the Product Concept which would be most efficiently implemented." If this were the objective of the team, then the appropriate Action is to develop a detailed design using the Product Specification and Concept as a guide. A more rigorous approach would be to answer the question "What actions do we need to take to achieve the targets that we have set in order to satisfy our customers?" In QFD terms, the Measures and their Targets can form the Input List to an Actions Matrix with the List of Actions forming the Output List. By defining the Relationships in this Matrix, the team is likely to identify all of the Actions required. The names of the people who are responsible to carry out each action can also be recorded. In addition to the Actions needed to achieve Target Values, there is a whole class of Actions which deal with gathering information to ensure good decision-making during the QFD project. For example, if a team is working with Design Tradeoffs, it is quite common to find negative relationships between Measures. Since a Negative Relationship indicates compromise, an Action should be defined immediately that involves someone from the team investigating the relationship and how the team might get around it. Similarly, when the team is involved in Benchmarking the competition, someone on the team is usually assigned to gather the specific information the team is interested in. This whole class of Actions can be captured as an Actions Document within QFD/CAPTURE.