Quality Function deployment


Quality Function Deployment (QFD) is a specialized method for making customer needs/wants important com­ponents of the design and production of the product or ser­vice. We advise you not to get hung up on the name of the process. There has been both a loss of meaning in the trans­lation from Japanese to English, and an evolution in the QFD process which has morphed into something rather different from that to which the name was first attached. However, the original English name, Quality Function Deployment, and its abbreviation QFD are apparently with us to stay, and we should have no difficulty with that.

Since QFD was first introduced in the West in the 1980s, its history has been spotty. Should you search the internet for success stories you may find more detractors than propo­nents. The primary complaints seem to be:

  • The matrices are difficult to use and too time consuming for our new lean organizations.
  • The math used to establish priorities lacks the precision necessary for a Six Sigma company.
  • Questions regarding the validity of the math.
  • Difficulty in obtaining a clear understanding of customer wants.

That being said, there are many organizations around the world that successfully use QFD, often in a tailored form that best fits their specific needs. The motivation to use it is logical—everyone would agree that it is preferable to de­sign and manufacture a product that satisfactorily addresses the needs of prospective customers than one that doesn’t. Further, in going through the QFD process, all the func­tional departments of the organization are involved from day one, and this is a primary objective of TQM. So we think there is a place for QFD in total quality, and this chapter is intended to acquaint you with the concepts and the basics of its process. Just be aware, should you decide to use QFD at some point, that it may not be appropriate for all cases and that your particular application may have to be tailored to your specific circumstances. Quality Function Deployment is still evolving, and software is now available to make the process easier and more reliable.

One of the keys to achieving customer satisfaction and continual improvement is understanding your customer’s needs and wants, and using them to guide the design and follow-on processes that create a product your customer will purchase and use. This was, and remains, the main focus of QFD. Developed by Japanese quality expert Dr. Yoji Akao in 1966, QFD combined quality strategies with “func­tion deployment” from the field of value engineering. In a sense, with QFD the customer—the potential user of the product—becomes part of the team that designs the product. It is a system that guides designers and planners to focus on the attributes of a product which are the most important to the customer. It involves:

  1. Identifying customer needs known in QFD-speak as the “voice of the customer” (VOC).
  2. Identifying the product attributes that will most satisfy the VOC.
  3. Establishing product development and testing targets and priorities that will result in a product or service that satisfies the VOC.

One might think that all of this is rather obvious. Of course, any product should be designed to do something that cus­tomers want done. So, naturally, any company that develops a product or service must do all of these things already, right? It may seem to be common sense. Unfortunately, the list of new products coming into the market has a surprising rate of failure. Customers quickly reject products that do not satisfy their wants. The road to market is strewn with the likes of the Edsel automobile (1958), New Coke (1985), the smokeless cigarette (1988). These are some of the more noteworthy and costly (all over $1 billion) market flops, but countless other less-infamous offerings have crashed and burned because they were products that no one had asked for. This must mean that companies do not always ask for their customers’ input, or they do not understand what their customers tell them, or that they simply don’t do a good job of translating customer wants into product functions and attributes that will satisfy them. Over half a century General Motors went from the largest corporation to bankruptcy by making it a virtual religion to ignore customer wants. Many others, large and small, have followed similar paths. QFD requires that you obtain customer-want input and translate it into the set of product attributes most likely to satisfy the VOC, and can even follow through the processes of production and test­ing that best satisfy the customer wants. The QFD process involves the development and analysis of the set of matrices known as the “House of Quality” (HOQ), as explained next.


The heart of QFD is the set of interrelated matrices known as the House of Quality (HOQ), so named because the complete matrix takes on the appearance of a house. Examining Figure 17.1 you will see that the HOQ is made up of six submatrices. The HOQ is utilized by a multi­functional QFD team (1) to take input requirements from the customers, and translate them into a set of customer needs, known in the QFD world as the “voice of the cus­tomer” and (2) from the VOC, and some benchmarking with competing products, determine the prioritized fea­tures of a new (or improved) product or service that will best respond to the VOC.

The component matrices making up the HOQ are uti­lized in formal sequence from 1 through 6. In this chapter, we will take you through the process using a relatively simple and fictitious project of improving a publishing company’s marketing position for its textbooks.


3.1. Gathering Customer Needs Input

Our hypothetical company publishes a series of textbooks for the college market. The company is not happy with its current position in the market, and intends to rework its of­ferings with the objective of improving its market share. The company realizes that to do that, they must produce text­books that potential customers will want. They plan to apply QFD to the publishing world.

The premise of QFD is that before any product or service is designed, the producer should have a good understanding of his potential customers’ needs in order to improve the like­lihood that the product or service will be a market success. That the producer should be aware of customer needs seems logical, but it sounds far easier than it is. Before the textbook rework is started, the QFD team must work diligently to de­termine what potential customers would like to see in terms of attributes and features of the product—and perhaps—what they don’t like about our current product. How do we get that customer input? For any product category there are a number of ways, including focus groups, user groups, polling custom­ers of existing similar products, surveys, questionnaires, cus­tomer service inputs, warranty activity, and in any other way the organization can think of. Any of these methods can take several weeks, and some will cost a lot of money.

3.2. Refining the Customer Needs Inputs

Once the cross-functional QFD team has assembled suffi­cient information on what characteristics, attributes, and features customers say they need, the information must be distilled into something useful. Typically the problem is that the inputs invariably cover the spectrum from some really good ideas and nuggets of information to some that are triv­ial or frivolous, and the volume of information so great that the designers are unable to cope with it. The data must be sorted into a prioritized set of the most important customer needs. At this point we will call on some QFD tools, the first of which is the affinity diagram. Refining a large collection of data into something that represents the essence of the VOC is done through the analysis techniques of the affinity dia­gram and QFD team discussion.

3.3. Using the Affinity Diagram

Affinity diagrams are used to promote creative thinking. They can be very helpful in breaking down barriers created by past failures and in getting people to give up ingrained paradigms that impede our ability to find new and different approaches. This is a critical element in achieving continual improvement. Affinity diagrams give structure to the cre­ative process by organizing ideas in a way that allows them to be discussed, improved, and interacted with by all the partic­ipants. Affinity diagrams are used most appropriately when the following conditions exist:

  • When the issue in question is so complex and/or the known facts so disorganized that people can’t quite “get their arms around” the situation
  • When it is necessary to shake up the thought processes, get past ingrained paradigms, and get rid of mental bag­gage relating to past solutions that failed
  • When it is important to build a consensus for a proposed solution

Figure 17.2 is an affinity diagram developed by the pub­lisher’s QFD team. With it, the goal was to organize the cus­tomer input (both what they want that the publisher didn’t offer and what they did not like about the current books) to clarify the reasons the books were not selling well. The result will be a categorized list of customers’ issues, which can then be reviewed and analyzed. Such affinity diagrams are devel­oped through these steps:

  1. A cross-functional team of employees is used. It may be the QFD team or another one specifically charged with developing the affinity diagram. Either way, teams typi­cally have membership from all relevant functional de­partments (e.g., sales/marketing, design/engineering, production/manufacturing, quality, finance, materials/ procurement, warehousing). Our team has participants from sales, marketing, production, editorial, and finance.
  2. The issue to be discussed is stated without detailed ex­planation. Too much detail can inhibit creative thinking and throw up barriers that prejudice participants. In our case, the issue was stated as follows: “Why are our text­books not selling better?”
  3. Responses of participants, armed with customer input, are stated verbally and recorded on 3 x 5 cards—one idea per card. Care must be taken to use the actual words of the customers to avoid any inadvertent translation of ideas. Also, at this point there should be no judgmental comments about the ideas proposed. The goal is to so­licit and record as many ideas as possible. Judgmental comments will inhibit the process.
  4. The cards are spread on a large table, and participants are asked to group them. Cards with related ideas are grouped together. Cards that don’t fit with any particu­lar group are put together as a miscellaneous group.
  5. Participants examine the cards in each group and try to find a descriptive word that contains the essence of the various cards in that group. This word or brief phrase is written on a card that is placed at the top of the group and becomes the heading for that group of ideas.
  6. The information on the cards is replicated on paper with boxes around each group of ideas. Copies of the draft af­finity diagram are distributed to all participants for cor­rections, revisions, additions, or deletions. The finished diagram should resemble the one in Figure 17.2.

3.4. Using the Tree Diagram

The next tool to be used is the tree diagram. Tree diagrams can be used for countless purposes. It will be used here simply to refine the affinity diagram results to make the list of customer needs, or WHATs that will be placed in the HOQ. Although a tree diagram could go all the way down into the nuts and bolts of a new design, remember that the objective here is not to design the new product, but to list the items to be addressed by the de­sign team once the entire HOQ is completed. Follow these steps:

  1. Clearly identify the issue/problem to be solved. It can be taken from the affinity diagram, or it can be a problem that was identified through discussion of the affinity dia­gram. Write it on a card and place the card at the top of a large table.
  2. Have the team conduct a brainstorming session in which participants record on 3 x 5 cards all possible tasks, methods, solutions, and activities relating to the affinity diagram issues. Continually repeat the following question: “To achieve this, what must hap­pen first?” Continue this until all ideas have been exhausted.
  3. Lay all the “what-must-happen” cards on the table below problem card. Put them in order based on what must happen first, working from top to bottom. As this task progresses, it may be necessary to add task cards that were overlooked during the brainstorming session.
  4. Duplicate the table’s layout of cards on a sheet of paper and distribute copies to all participants. Allow partici­pants to revise and correct the document.
  5. Figure 17.3 is a partial tree diagram that was devel­oped to address the issues identified in Figure 17.2. We have deliberately oversimplified our tree diagram to keep the HOQ construction easier to follow. Notice that the team’s choice of things that must happen to make our textbook artwork acceptable to customers includes the use of color in the artwork and ensuring that examples are plausible. These two items represent the abbreviated customer needs with respect to our artwork issues.

In practice, the team reduces the total list of needs to those considered by the team to be the most significant. The final list of customer needs covering the complete set of is­sues may be as many as 20 or 30, or a few as eight to ten, depending on the situation. These needs are what the cus­tomers would like to see in (or have corrected in) the prod­uct. They are what the company must address in order to produce a product that will find favor with customers. This list representing the VOC is entered into the first HOQ ma­trix called Customer Needs, or WHATs. We illustrate this in Figure 17.4.

Note: The final customer needs should be nonlimit­ing and nonspecific in terms of solution and measurement to allow the team to consider without bias all possible ap­proaches to meet the needs.

3.5. Customer Importance

Also coming out of the analysis is the team’s best estimate of the relative importance of each listed customer need. Customer importance is usually based on a scale of 1 to 5 with 5 being the highest priority. This information is solic­ited from customer sources, but unanimity in ranking by the customers is unlikely, so the team has to do its best to evaluate and assign priorities as they believe the aggregate of customers would. These importance rankings are entered in the Customer Importance column to the right of the needs entries, as shown in Figure 17.4.


4.1. Competitive Benchmarking

Next we must gather and analyze customer satisfaction data relative to our product and competing products, develop a planned satisfaction rating target for our forthcoming prod­uct, and calculate improvement factors and sales points.

First we are going to engage in some competitive bench­marking between our existing product and its competition. We are interested in customer satisfaction ratings of compet­ing products because they will come into play in determining what we have to do to make our products more appealing than those of our competitors. In order to obtain that information, we might use a focus group to compare our product against its competition. We could also send questionnaires to customers who use competing products and to those who use ours. In both situations, participants will be asked to rate the products on each of the characteristics listed in the Customer Needs matrix, using the familiar 1 to 5 scale (5 being most favorable).

Our publisher collects this information for its own ex­isting books and for competing books of two prime competi­tors. The information is plotted on the Planning matrix as shown in Figure 17.5.

4.2. Planned Customer Satisfaction Performance

Also plotted on the Planning matrix will be the team’s de­sired customer satisfaction performance for the new product for each of the customer needs. The same 1 to 5 scale is used. One might ask, why wouldn’t the team desire the best rating (5) for every need? The reason the company has to back off perfection is money. The practical objective is to produce a textbook that will satisfy customers while not pricing itself out of the market. That is not to say that improvements should not be made if they can be done without putting the book out of reach of its prospective customers or making the book uncompetitive for cost reasons in the market. The pub­lisher would like to be the competitive leader, but not neces­sarily the most expensive producer.

The team works out a target customer satisfaction goal for each of the customer needs. These are also plotted on Figure 17.5.

4.3. Improvement Factor

The team next calculates the improvement factor for each need for the new product. The equation for improvement factor with a 1 to 5 scale is:

Improvement Factor = {(Planned CS Rating – Existing CS Rating)0.2} + 1

where CS is customer satisfaction

For example, if a planned CS rating is a “4” and the CS rating for our existing product is a “3,” then the improve­ment factor is:

{(4 — 3) X 0.2} + 1 = 1.2

These data are also plotted in the Planning matrix, as shown in Figure 17.5.

Sales Point A strategic marketing factor, sometimes called a sales point, may also be placed in the Planning ma­trix. Sales point is a number from 1 to 1.5 that is used to place emphasis on the customer needs. It is an estimate of the marketing importance of the need in the promotion of the new product, and is therefore used, along with customer
importance and improvement factor, in the calculation for overall weighting of the customer needs. A sales point of 1 results in no change in the overall weighting, whereas a 1.5 sales point increases the overall weighting half again beyond that indicated by the customer importance of the need and its improvement factor. The team develops the sales point data and places it in the Planning matrix.

Overall Weighting The team next calculates the overall weighting for the individual needs using the formula:

Overall Weighting = Customer Importance X Improvement Factor X Sales Point

For example, the comprehensible text need has a cus­tomer importance rating of 5, an improvement factor of 1.2, and a sales point of 1.1. Therefore, the overall weighting is:

5 X 1.2 X 1.6 = 9.6

The calculated overall weightings are entered into the Planning matrix as shown on Figure 17.5.

Percentage of Total Weighting Next, we convert the overall weightings to percentages in order to better under­stand how much of the design or improvement effort should be placed on each of the customer needs. The percentage of total weighting is calculated by the following equation:

% of Total Weighting = (Overall Weighting , Sum of Overall Weightings) X 100

For example, the sum of the overall weightings in Figure 17.5 is 51.3. The comprehensible text need has an overall weighting of 6.6. Therefore, the percentage of overall weighting for the comprehensible text need is:

(6.6 , 51.3) X 100 = 13

Percent data are entered in the final column of the Planning matrix. See Figure 17.5.

From the Planning matrix then, you can see that consid­ering together customer importance (how critical is this need to the customer), improvement factor (how much of an im­provement do we have to make in our product for this need), and sales point (importance of this need from the market­ing point of view) leads to an overall weighting for the need. That in turn tells us through the percent of total weighting roughly how our resources need to be allocated across the total design or improvement project. For example, the need for accuracy has the highest overall weighting and percent of total weight. It is very important that the publisher achieves its planned rating of 5 for accuracy. Affordability comes in a close second, with comprehensibility of text third.

Before we move on to the next matrix, we want to leave you with a caution. We do not recommend that the company allocate the work of improving the product or service strictly or solely by these numbers. They are, after all is said and done, the result of a lot of opinion and estimating all the way from the customer, through the team’s deliberations and dis­cussions. The math is going to produce numbers accurately reflecting the various ratings and factors—but the source data for those numbers should not be considered to be abso­lutely accurate. Remember, it evolved from opinion and esti­mates. Our best advice is to consider it to be guidance rather than absolute. It seems to work well in most situations, but if the customer needs input is faulty, the organization can do the HOQ matrix work perfectly, deploy its resources in ac­cordance with the matrices, and end up designing the wrong product that no one wants. Keep your sensors wide open for information that may warn you of problems.


The Technical Requirements room of the HOQ states how the company intends to respond to each of the customer needs. It is sometimes referred to as the voice of the company. We must state at the outset that the technical requirements are not the design specifications of the product or service. Rather, they are characteristics and features of a product that is perceived as meeting the customer needs. They are measurable in terms of satisfactory achievement. Some may be measured by weight, strength, speed, and so on. Others by a simple yes or no, for example a desired feature, appearance, test, or mate­rial is or is not incorporated. The other side of the coin is that the technical requirements must not be limiting, but must be flexible enough to allow the company to consider every cre­ative possibility in its attempts to satisfy the need.

The technical requirements are generated by the QFD team through discussion and consultation with the Customer Needs and Planning matrices used as guidance. The team may use affinity or tree diagrams to develop, sort, and rank the requirements, similar to the customer needs develop­ment process. The difference here is that the input is from within the company rather than from external customers.

The use of an affinity diagram or tree diagram will help the team focus on the textbook characteristics and features, procedures, and production processes likely to achieve the planned improvement. Our publisher’s team developed the tree diagram of Figure 17.6. They categorized the diagram in three elements, listing the points considered most likely to produce customer acceptance. For example, under the first cat­egory, Writing and Editorial, cards for four issues are displayed:

  • Accuracy checking policy
  • Revision to the Authors/Editors Guideline manual
  • Policy on chapter aims and summaries
  • Font selection policy

This is carried down through successive tree diagram nodes until the technical requirements are developed. For example, the Authors/Editors Guideline Revision node branches into a triple node consisting of relevant items to be addressed in the revised guidelines:

  • Consistent writing style
  • Comprehensibility
  • Credibility check

This general tree development pattern is repeated for the remaining categories to form the list of items from which the technical requirements to be placed in the HOWs room of the HOQ are finally selected by the QFD team.

Refer to Figure 17.7 to see the eight technical require­ments that were developed.


Now that we have the QFD team’s technical requirements (HOWs) in the HOQ, the next step is to examine how they relate to the WHATs of the Customer Needs. The results will be shown in the Interrelationships matrix, which links the HOWs and the WHATs. At each intersection cell of the Interrelationships matrix, the team must assess the degree of relationship between the WHAT and the corresponding HOW. This is usually done using scales of significance of 1 to 5 or 1 to 9, with the higher number indicating a stronger relationship. Sometimes these numbers are entered, but often symbols are used. For our example we will use symbols as follows:

© = 9 (strongest relationship)

O = 3 (medium relationship)

Δ = 1 (weak relationship)

Blank cell indicates No relationship

Let’s see how this works. Refer to Figure 17.7, and con­sider the first customer need, comprehensible text. Now look at each of the intersections on that row to see which HOWs have a relationship with comprehensible text. Authors/editors guide seems to offer a relationship. Certainly the publisher’s guidance to the author and the level and effectiveness of the editing process will impact the quality and comprehensibil­ity of the text. We have identified an interrelationship, but how strong is it? The team has to decide, and the result may not be very exact, but rather is a well-discussed estimate. Let’s say that the strength is high. We should enter either a “9” or the double-circle symbol in that cell. The next compre­hensible text relationship cell appears to be under text clar­ity. The interrelationship between this WHAT and HOW is strong, so a 9 or the double-circle symbol is entered. All cells must be checked for interrelationships, and when such ex­ists, the strength of the relationship must be evaluated.

As we have mentioned, either numbers or symbols may be used. If you use numbers, use only 1, 3, and 5 or 1, 3, and 9 rather than 1, 2, 3, 4, 5, and so on. Remember, we are only estimating the interrelationship’s strength: Is it strong, me­dium, weak, or nonexistent? There is little to be gained by trying to be precise in an area where the result is a best guess or an estimate.

There is a rule of thumb in QFD that only about 15% of the interrelationship cells will show a relationship be­tween WHATs and HOWs. So don’t be concerned when your matrix appears a bit empty. There is, however, one firm rule with the Interrelationships matrix—every row and every column must have at least one entry. An empty column means that the HOW (a technical requirement) is not delivering value to the customer needs. For example, if Figure 17.8 had a technical requirement to make the books smaller we would find that it does not relate to any of the figure’s customer needs, and the column would be empty. To expend any effort to reduce the book’s size would be a waste of resources since the customers will not find value in a smaller book. On the other hand, a horizontal row with all cells blank indicates that the WHAT (a customer need) is not being addressed. For example, if Figure 17.8 showed a customer need for an e-book version for an electronic book reader, that row would have no cell entry because that need is not addressed by any of the technical require­ments. Just remember that all the listed customer needs must be addressed in the technical requirements, and any technical requirement that does not address a customer need probably shouldn’t be there. Figure 17.8 shows the Interrelationships matrix completed.


As a product or service is being designed, there will inevitably be some technical requirements that tend to benefit one an­other and some that tend to work against one another. Those that benefit each other are said to have a supportive or positive correlation. Those working against each other have an imped­ing, or negative correlation. It is always helpful to know what kind of correlation exists in order to take advantage of the
supportive correlations, and to contrive trade-offs for those that impede. Failure to know this may result in a product that does not meet requirements, or one that requires expen­sive redesign in order to conform to customer requirements. Getting it right the first time is the purpose of the Correlation matrix or roof of the HOQ. One might say that getting it right the first time is the purpose of the entire QFD process.

The Correlation matrix is constructed by drawing a tri­angle (looking like a roof) over the Technical Requirements section of the HOQ. Refer to Figure 17.9. Intersecting diago­nal columns are drawn within the triangle from the top of each Technical Requirements column. Next the correlation type, whether supportive, impeding, or having no correlation, is determined for each of the technical requirements against all other technical requirements. A supportive correlation is indicated by a plus sign (+) at the intersecting columns of the two technical requirements under consideration. A negative correlation is indicated by the use of the minus sign (—). If there appears to be no significant correlation, that intersec­tion cell is left blank. Should it be beneficial, the supportive and impeding classifications may be expanded to strongly supportive, supportive, impeding and strongly impeding.

In practice, the QFD team asks some variation of this question, “Does improving this technical requirement result in the other’s improvement, or does it result in degradation of the other?” If neither improvement nor degradation is in­dicated, there is apparently no correlation between the two.

In our example, the QFD team will first ask the ques­tion, “Will employing a better authors/editors guide sup­port or impede lower cost production?” It might impede lower cost production if the new-and-improved guide significantly increased the work for the authors and edi­tors, but the team doesn’t think that will be so, so the in­tersection cell for those two columns is left blank. Next, the team will look for correlation between authors/editors guide and the technical requirement for enhanced du­rability. Clearly there is no correlation there. The next correlation check is between authors/editors guide and the technical requirement for text clarity. The better the guide, the better the text clarity should be, so this repre­sents a supportive correlation. A plus sign will be placed in the intersecting cell of the technical requirements of authors/editors guide and text clarity. There are four more correlation checks for the authors/editors guide technical requirement, and all turn out to be supportive. Next, we will examine the possible remaining correlations for the lower cost production requirement. The first will be with enhanced durability. In this case the correlation is imped­ing, because making the product more durable would be expected to directly increase the cost of production, not lower it. The intersecting cell will get a minus sign. This means that during the design process, either some trade­offs must be made between the needs for lower cost and enhanced durability, or better yet, that some process must
be discovered to improve the book’s durability while hold­ing or reducing cost. This examination is repeated for all remaining correlation cells, and the Correlation matrix you see in Figure 17.9 is complete.

For an HOQ with eight technical requirements such as our example, there are 28 possible correlations. Adding one more technical requirement expands that number to 36, adding two more results in 45, and so on. Real world HOQ diagrams are often much larger than ours, suggesting that a lot of time and effort must be expended before the team has it completed. The bigger and more complex they be­come, however, the greater the need for the power of the HOQ. The HOQ’s information presentation makes it easier to work through complex situations with assurance that all important factors have been considered and evaluated. That should make it much more likely that our new product will be successful with our customers.


The HOQ is almost complete, needing only a final section called Design Targets. If the customer requirements de­scribe WHAT the customer needs, and the design require­ments tell HOW the company is going provide the product characteristics necessary to address those needs, then the design targets specify HOW MUCH of the characteristic needs to be provided. For example, in our HOQ the cus­tomer has said he wants our books to withstand heavy use without having the binding fall apart. In our design re­quirements, we said we needed to enhance the binding’s durability. Now in the Design Targets matrix we need to determine HOW MUCH more durable the binding must be. That will be determined by the data that we have al­ready entered into the HOQ, along with data from bench­marking and testing as required. This section summarizes the conclusions of the QFD process and translates them into product specifications.

The Design Targets section is completed in three sections:

  • Technical priorities (from data already in the HOQ)
  • Technical benchmarking (newly developed data)
  • Design target values (developed from the previous two)

8.1. Technical Priorities

To determine the relative importance, or priorities, of each of the stated technical requirements (HOWs) in meeting the cus­tomer needs (WANTs), the QFD team simply multiplies each of the interrelationship ratings of the technical requirement (0, 1, 3, or 9) from the Interrelationships matrix times the corresponding customer need’s overall weighting value in the Planning matrix, and then sums the columns. All of the data for these calculations are already in the HOQ of Figure 17.9. Starting with the technical requirement for a new and respon­sive set of Authors/Editors Guide, we find that its relationship to the customer need for a comprehensible text was indicated in the Interrelationships matrix as a 9. Looking across the row to the Overall Weighting column of the Planning matrix we find a value of 6.6. Multiplying them gives us a value of 59.4.

There are three more interrelationship values for the au­thors/editors guide technical requirement, so a total of four multiplications must be done and then summed.

For the comprehensible text need        9 * 6.6 = 59.4

For the accuracy need,                         9 * 9 = 81.0

For the plausible examples need,         9 * 5 = 45.0

For the consistent writing style need,    3 * 2 = 6.0

Authors/editors guide technical priority          = 191.4

The value of 191.4 is entered in the Technical Priorities row of the Design Targets matrix under the Authors/Editors Guide column. See Figure 17.10. The Technical Priorities row is completed by repeating the process for each of the other technical requirements.

The meaning of the resulting technical priorities num­bers like 191.4 and 42.3 does not jump out at you like a percentage does. For that reason, some QFD users translate the priority values into a percentage scale. This is done, of course, by dividing the individual technical priority values by the sum of all the priority values and multiplying by 100.

% of Total Priority = (Technical Requirement Priority , 2 Technical Priorities) X 100

In the case of the authors/editors guide technical requirement,

% of Total Priority = [191.4 , (191.4 + 75.6 + 42.3 + 63.6 + 19.8 + 9 + 53.1 + 49.5)] X 100 = (191.4 , 504.3) X 100 = 38

The rest of the percent of total priority values are calcu­lated, and placed in a row just below the Technical Priorities. See Figure 17.10. Except for small errors for rounding, the row’s sum should equal 100.

With 38% of the total priorities, and with the next high­est at 15%, and decreasing from there, that means that in meeting the customer’s needs, the new authors/editors guide is by far the most important technical requirement. That this technical requirement has a much higher percent of total priorities than the others seems reasonable since it impacts four customer needs while the others only relate directly to one or two. This information is used by the organization as guidance for the appropriate deployment of limited re­sources for the project.

8.2. Technical Benchmarking

The next section of the Design Targets matrix involves com­paring the organization’s intended product with competing products, in our case from same competitors A and B that we used in the Planning matrix. In HOQ Matrix 3 the team identified the technical requirements—how they plan to meet the customer needs. The Technical Benchmarking sec­tion is intended to provide specific information on where the organization’s current product (assuming there is one) stands relative to competing products, with respect to each of the technical requirements. The source of information for the competing products may come from customers, focus groups, the press, by actual testing and measurement of those products, and so on. Usually it is dredged from a com­bination of all possible sources. The team starts by gathering the data on its own existing product for each of the technical requirements.

Authors/Editors Guide. This proposed new set of guide­lines is intended to respond to several elements where the publisher’s books are a bit weak: namely comprehensibility of text, accuracy, plausible examples, and consistent writing style. The team grades those elements for the publisher’s cur­rent books, and sets the overall score at 5 on a 1 to 10 scale, with 10 being best.

Lower Cost Production. This one is easy. What does the book cost to produce? The answer on average for the current books is $40, so that is the score.

Enhanced Durability. The publisher’s books have had a tendency to come apart more often than its competitors do. Testing suggests that the binding process and the materi­als used could be better. Destructive testing yields a relative strength (the ratio of pull strength to binding stress) of 1.1 for current products.

Text Clarity. This is related to two customer needs: com­prehensible text and easily readable fonts. Upon evaluation the team assigned a 1 to 10 based score of 7 for the current books.

Flowing Text Sequence. In this case, rather than trying to determine a score, the team used a YES-NO system. If the text seemed to flow in a logical, orderly sequence it was graded YES. If the flow jumped back and forth from subject to subject, it was given a NO. The publisher’s books tended toward the latter, and got the NO.

Effective Artwork. The purpose of artwork, that is the figures, drawings, and illustrations, is to clarify and illumi­nate the text. The team used a 1 to 10 scale to grade how effectively the books’ artwork accomplished those goals. They gave the current versions a 7.

Color Emphasis. Color can be used not only in the artwork, but also in the text to make something more inter­esting, eye-catching, and hopefully more memorable. The team concluded that a telling rating would be the percent­age of pages having color. It was easy to grade the publisher’s current books because no color was used except on the cov­ers. Score 0%.

Chapter Aims and Summaries. This is another YES- NO category. A book either uses them or it does not. The current books mostly did not, so they got a NO score.

These scores were entered in the Our Product row of the Technical Benchmark section. See Figure 17.10.

Next, the same data were developed by the team for the books of competitors A and B. You will find that data in the next two rows of Figure 17.10’s Technical Benchmark section. The data shows that this publisher’s books come off second or third-best of the three. Good reason for low market share, the issue that prompted the company to get involved with QFD in the first place.

If you compare these ratings with those of the Planning matrix, you should notice that the rankings of this pub­lisher’s books versus those of its competitors are very much in agreement. If that does not turn out to be the case, then something is wrong, and should be discovered before pro­ceeding. Was the customer understood correctly? Was the data reliable? Have we put our emphasis on the wrong thing?

8.3. Design Targets

The objective of the design targets is to establish specific ob­jectives for the design team. For example, the QFD team de­termined that through the application of, and adherence to, an improved set of guidelines for all the people involved in authoring and editing the books, increasing the score to an eight would better the competition, and should be possible. Similarly, setting a target of $30 per book (on average) for production cost will beat the competition by $4 per book. However, that represents a 25% reduction from the present situation, and the publisher is also asking to markedly im­prove the durability of its books. This is the kind of situation where one must consider a radical change that can achieve both goals, and that is what the QFD team is counting on. They expect a complete change in the materials and pro­cesses used in binding the books.

A measurement of book durability is relative strength. That is the ratio of pull strength divided by binding stress. The publisher’s current products have a relative strength of 1.1, while the competitors A and B score 1.5 (much bet­ter) and 1.2 (somewhat better), respectively. By investing enough, the publisher can equal Competitor A’s 1.5, but is that necessary? Competitor B’s books have a relative strength of 1.2, and the books seem quite durable. This becomes a trade-off. The publisher can switch its current binding pro­cess to new modern processes and materials making the bindings more robust than most customers would ever need, or the company can scale the improvement back a bit in the interest of economy, and still have adequate durability while simultaneously achieving lower production costs. The QFD team sets the target at 1.4.

Our books scored 7 out of a possible 10 for clarity of text, against the competitors’ scores of 10 and 9. The QFD team sets the design target value at 10—there is no reason to publish anything lacking clarity, and the competition proves it.

In similar fashion, the team sets YES for the design ob­jective for text sequence flow. If the authors can’t manage it, the editors must.

The design goal for having artwork that is effective in clarifying and illuminating the text was elevated from the cur­rent level of 7 to a 9, the same as leading Competitor B. The target for color emphasis was set at having 15% of the pages with some use of color. That is much less than Competitor B, but in line with the customer’s needs. And finally, the team determined that the publisher must include chapter aims or objectives and chapter summaries in its books. This is in­dicated as a YES. See Figure 17.10 for all the inputs to the Design Targets matrix.

At this point the HOQ is complete. See Figure 17.11. What happens next? That depends on the situation. HOQ is often used at this level to guide all departments in their efforts to design and produce the product. The HOQ will help the organization ensure that all aspects of the product’s design adhere to the customer’s needs, that extraneous bells and whistles are prevented, and that all relevant activities of the company are involved and participating.

In some cases, depending on the application, an HOQ like the one we have just developed will be just the starting point, with lower level HOQs being developed for the various organizational functions. For example, subor­dinate HOQs may be utilized for the actual design of the product, procurement of parts and materials, gearing up to manufacture the product, and so on. It is important to understand that QFD is appropriate for services as well as for tangible products. Our development of an HOQ involved a tangible product, but we could as easily have addressed the improvement or development of a service instead. Our objective here has been to acquaint you with the purpose of QFD, and its language, layout, processes, and functions.

Source: Goetsch David L., Davis Stanley B. (2016), Quality Management for organizational excellence introduction to total Quality, Pearson; 8th edition.

Leave a Reply

Your email address will not be published. Required fields are marked *