Problems with Traditional QFD Applied to Software

Traditional QFD applied to software had a number of problems. Some of these were not problems with QFD itself, but rather, with a limited understanding of QFD or a weak implementation approach. What went wrong, at times, when traditional QFD was applied to software?

Traditional QFD Failures

Some software project teams failed in their attempt to apply QFD because they lacked training and they had no support by experienced Software QFD practitioners during their first Software QFD project. Of course, any powerful method can fail with inadequate training or support, so this is not a fault of QFD, but there were a number of failures of this type when software organizations first tried to do Software QFD. It is important to obtain good training in Software QFD (not in Hardware QFD, as there are too many tricky details that are different) and appropriate support for those using Software QFD for the first time.

QFD is not magic. You can certainly do it so poorly that is a complete waste of time. But QFD's track record over 40 years for hardware applications, and over 20 years for software, is clear. If you learn it and apply it correctly, QFD can work, and work well.

In fact, QFD's reputation is so great that some organizations experience false positives when they try QFD. Knowing that Software QFD is a "best practice" in leading software organizations, a team may claim (and believe) that QFD worked great on their project. When asked whether they will use it again, they will say, "Yes, on a larger project." Upon further questioning, they will say it was a little too much for the size of their project. This means QFD really failedthe team would not, on their own, use it again on a similarly sized or smaller project. This is not a solid foundation for QFD to grow on in an organization. But failure, or a false positive, is not the only danger in implementing QFD.

"The Matrix Is Too Big"

The "House of Quality" matrix usually has about 50 percent more columns than rows. That is, for 100 rows, you will typically generate about 150 columns. And that means there are 15,000 cells to examineeven though typically only 20 percent to 30 percent of them take on values. This is too much effort to spend in one place in the development process. Why does the matrix get this big?

Garbage In...

The concept of "garbage in, garbage out" is the cause of many oversized "House of Quality" matrices. Unfortunately, some books and seminars still describe the rows and columns as whats and hows. This is a description, not a definition, and it allows people to put anything that they would consider a what in the rows and any answer to a how in the columns. This leads to the situation where newcomers make avoidable mistakes.

This is a special problem for software, as the terms what and how have been widely used in methods as far back as SA to explain the distinction between logical or essential (technology-and-implementation-free) models done in analysis and appearing in a functional spec, and physical or design (technology-and-implementation-specific) models done in design and appearing in a design spec.

That QFD continues to flourish despite these challenges is perhaps the best testimony to the method's robustness. Even poor QFD is significantly better than no QFD, so QFD continues to grow and spread anyway.

Criteria versus Solutions

If you have hows, or design solutions, in the columns, you will likely put the criteria for choosing the solutions in the rows. For technical people these are usually technical requirements or design requirementsthe characteristics or capabilities that the design/technology/implementation must satisfy. So we wind up with what should be the columns in the rows, and the customer needs never appear. This is a very common situation, and you will find this situation in the well-known car-door case study. Although this is a useful matrix, it is a design matrix, not a "House of Quality" matrix, produced to bridge the world of the customer and the world of the developer. (And it may not be the most important matrix for you to do, if for some reason you are doing only one.)

"It Takes Too Long"

One of the most common complaints of applying traditional QFD to software is that it can take a great deal of time. Worse, once people begin the detailed analysis that any QFD matrix requires, they often lose sight of the reason QFD exists: to ensure customer satisfaction efficiently.

In the next section, we'll see how Modern QFD addresses the purpose of QFD, but without using the matrix as the primary tool to do so and thereby avoiding this problem. The QFD framework will still aid us in keeping our focus on the "voice of the customer" and on cross-functional team communication concerning what matters most to customers, and it will act as an aid in discovering high-value customer needs and corresponding product requirements and features.

To address this problem, some practitioners of traditional QFD tried to "speed up" or "streamline" traditional QFD by

• Doing only the "House of Quality" matrix

• Doing a size-limited "House of Quality" matrix, with a restricted number of rows and columns, or by using the secondary level of the customer needs hierarchy instead of the tertiary level

• Focusing on only portions of the product where critical trade-offs occur, when doing a model upgrade

• Terminating the QFD process when it has provided "enough" answers to critical questions

Unfortunately, such approaches did not succeed and are not pursued today. Instead, by going back to the fundamentals of QFD and applying QFD to itself, a more efficient form of QFD was developed, whereby the matrix is an optional tool and is used only when specifically required. Another benefit of this analysis was to clearly show the power of QFD for new-product development, including products that are new to the company and are new to the world.

"We Knew That Already"

A common complaint concerning Software QFD is that the results were not of sufficient valuein other words, they weren't worth the effort required to produce them. As many people are still only doing the "House of Quality" matrix for their software development projects, this means that the "House of Quality" matrix required too much effort and yielded too few insights. The common complaint is, "We knew that already. The answers were obvious."

Weak Content

A major cause of lack of value in the "House of Quality" matrix is weak content. Several things cause content to be weak, and the most common is not having a clear understanding of the project's strategyin other words, not having a clear idea of the project's success factors and how the project fits with the organization's overall strategy. This can lead to irrelevant QFD results. The second cause of weak content is not defining what types of customers the project has to satisfy, and how much it has to satisfy themthat is, which customers are most important to the project's success, and why. This leads to the wrong customers being visited, a greater proportion of customer needs from the least important customers, and a lack of important needs from the most important customers. The final cause of weak content is not having a strong upstream "voice of the customer" process prior to doing the "House of Quality" matrixthat is, not being clear, trained, or skilled at observing the context of the customers, gathering their statements, and organizing and prioritizing their needs. This leads to important needs being lost or misunderstood by the time they get to the "House of Quality." Before you invest time and effort in doing a "House of Quality" matrix, make sure the inputs are correct.

But even if the content was correct, there were other problems...

Weak Understanding

If QFD was a newly developed technique, we could understand why certain errors are so common. But despite the fact that QFD is a mature method, an almost random pattern of learning and dissemination of bits and pieces of QFD occurred in the first 15 years of QFD's spread to North America and Europe.

The problem is further aggravated by QFD's role as a key component in both TQM^[33] and DFSS.^[34] Because too few people in the Six Sigma community have acquired a comprehensive understanding of QFD, the biggest benefits to using QFD are still ahead for most organizations that use DFSS.

Filter the Input

The "House of Quality" matrix should have only customer needs in the rows, and only the related software characteristics and capabilities in the columns. Nothing else should be in this particular matrix. To ensure this, you should sort out the customer statements using a Customer Voice Table (CVT), organize them using an Affinity Diagram, structure them using a Hierarchy Diagram, and prioritize them using the AHP (we will discuss all of these issues shortly). After this upstream processing is done, you will have good input to your "House of Quality" matrix.

This will prevent the problem of mixed items in your matrix, but what about the sheer size of the matrix. What if we have lots of customer needs?

Control the Size

There are several aspects to making sure you are not overwhelmed in the QFD process, and the first aspect is to focus on your most important customers, by prioritizing your strategy and your customers, and then having the customers prioritize their needs. This allows you to concentrate on the top n customer needs. The second aspect is to plan what matrices you should do (if any), and limit their size. There is no point in working through a matrix with many more customer needs than you can act on with best efforts. Take the top n customer needs and choose n to be within what the team can tackle. Finally, do not exhaust all of your QFD efforts in one shot at one point in the project. It is far better to do ten 10x10 matrices (or other QFD tools) to address ten key dimensions during your project at ten carefully chosen points in time, than it is to do one 100x100 "House of Quality" matrix at one point.

If at any time, you feel that your matrix (or any QFD tool) is "too big," it means you have not managed the size of your work objects properly. In software engineering, we have to do complete work objects. You have to put all the objects in your system on your class hierarchy diagram, not just the most important ones. But in Software QFD, we are focused on value, so working on the top n of anything is not only allowed, but also is essential for focus and efficiency.

Check the Matrix

Every step in the QFD process involves procedures for checking the step, catching errors, and assuring correctness. (This is a basic property of any good quality method.) QFD matrices can contain a variety of structural errors, and methods for checking for such errors do exist, as do methods for conducting simple mathematical checks on the values in the matrix. Learn how to do the work right, and how to check that you have done so.