QFD is a quality system. QFD is not "doing a 'House of Quality' matrix." "Kindergarten QFD" is just doing a "House of Quality" matrix, especially if no one can explain why that matrix (and not any of the other matrices in QFD) was done, and done first. QFD is not a canned method, and you should tailor it to the project's needs and the organization's development process. Stagnation occurs when the QFD process in an organization remains substantially unchanged for many years.
QFD has deployments (subsystems) to address any aspect of product or process that is important to the intended customers. Especially important for DFTS projects are deployments for quality (customer responsiveness), reliability, safety, security, and maintainability. Another important deployment is that of schedule (cycle time or delivery time), which QFD addresses with critical chain project management.
Project goals and strategies are important for developers to understand at a very early stage. If the project charter does not state this clearly, you can use methods such as the New Lanchester Strategy to help clarify it. Also note that not all projects are strategic.
Understanding what type of customers you intend to satisfy is necessary in order to focus your requirements discovery. You can devise customer segments in many ways, but the team must have a common understanding of who the customer is.
Much of the apparent ambiguity in customer requirements stems from the developers not understanding the customer's situation. If you cannot accurately model the customer's process, how can you expect to build the right software?
The gemba is the actual place where your software should add value to the customer or user. The gemba is not a conference room, unless you are developing conferencing software. Go where the user actually does what they need help with. Observe.
Whatever the customer tells you is not a requirement or a need, but a verbatim (an actual statement of their "raw words"). We must analyze their statements (and actions) to derive their needs, which we should confirm with them.
To structure the confirmed customer needs the customer develops an Affinity Diagram. We need to understand the way the customer thinks about their needs (we don't care what developers think about customer needs).
A Hierarchy Diagram, once it is quantified, prioritized, and confirmed, is the most important single work object in the entire development process. It is the definition of value to the customer. Understand that, and you have a chance to build software that will satisfy your customers.
You must scale priorities by ratio or nomalized before using them as weights. AHP is the simplest, currently known method for obtaining ratio-scale priorities. Priorities that are not ratio scaled cannot legitimately be used as weights or multipliers. And benefit/cost analysis cannot be done if the benefits are not quantified on a ratio scale.
The MVT defines on one page, over the entire project, your plan for how you intend to satisfy your target customers efficiently. It is an extremely valuable result to focus a project team, and an experienced cross-functional team can produce it in one day when guided by a capable QFD facilitator.
You should perform downstream deployments in QFD only when required, and only to the extent required, not by default. Match the size and investment of effort to the project's need for the answers they can provide. The complaints that QFD is "too big" or "takes too long" reflect traditional or poor practice, not best current practice of modern QFD.
The reduction in schedule made possible by the methods in QFD Schedule Deploymentnamely, Critical Chain project managementcan free up enough time (within 12 months of implementation) to recoup even a very substantial investment in QFD training and education, and the Blitz QFD approach presented here is very efficient with respect to training and application time. The excuse of "we don't have time to do QFD" simply doesn't hold up on serious consideration.
Chapter 3 elaborates on the issue of metrics and quantification, which this chapter only considers for the Hierarchy Diagram. Chapter 7 deals with the 7 MP Tools in greater depth. Chapter 12 provides further ideas for design decisions and concept selection. Chapter 13 covers risk and Failure Mode Effect Analysis in greater detail. Chapter 16 considers other issues concerning requirements, Chapter 24 covers the case of defining customer needs for brand-new (new to the company) products, and Chapter 26 addresses the application of QFD to project management.