QFD Online

…moving into the House of Quality

When to Say When

October 9th, 2007 by James Grover

A comment was recently submitted to QFD Online regarding the limits that should be imposed on the number of requirements for any given House of Quality. The basic premise of the comment was that the number of requirements should be limited in order to keep the HOQ “maintainable”. While the core principle was accurate (i.e. that it requires care and attention when crafting a QFD in order to make sure that it can be maintained long-term), the idea that there is a one-size-fits-all limit that can be used is misguided. Luckily, however, there are processes and procedures that can be applied on a case-by-case basis to ensure maintainable requirement lists.

Different Strokes for Different Folks

It is true that one must be very judicious when adding new requirements to any House of Quality. The fact of the matter is that as the requirements lists become longer, more and more time is required for adjusting ratings and maintaining the Quality Function Deployment model. However, different industries, different products, and even different teams will have dramatically different definitions of what constitutes a “long” list of requirements for a House of Quality.

A Quality Function Deployment model might be created for a wrench manufacturer that may never contain a requirement list with more than 20 items. This QFD might be very comprehensive and do an excellent job of representing the voice of the customer in the design, manufacturing, and marketing of a given wrench line. However, a QFD model for a particular software application may have an HOQ that rates features against feature sets and requires considerably longer lists. In an “Agile” software development environment, it may not be unreasonable for such an HOQ to list over 500 features that had been requested for a product’s upcoming release.

Individual Houses of Quality within a given QFD will require different limits on the number of requirements in its lists as well. This difference in size is due largely to the target audiences for the HOQs. For example, the first HOQ in a given software QFD may list business requirements and rate them against feature sets. Executive business leaders are generally limited in their time and availability, so these lists will need to be short and represent “high-level” concepts. However, subsequent HOQs in the QFD may be maintained by “front-line” product management or development teams who have considerably more time to focus on the individual feature requests submitted by end users.

Pruning Your Lists

Even though there are no magic rules-of-thumb that can be applied to all Houses of Quality in terms of their maximum number of requirements, there are some excellent guidelines for establishing lists that are comprehensive without being overloaded. These guidelines focus on the quality of the requirements, rather than the quantity:

First, when adding any requirement to a list, make sure that it is not a proper subset of another requirement. Additionally, it is often necessary to verify that groups of requirements are not proper subsets of other groups of requirements. These redundancies are often difficult to detect but should be watched for as their presence not only makes a QFD cumbersome, they also tend to inflate the relative importance of certain requirements by being rated multiple times.

Secondly, it is important to frequently review the secondary requirements for any House of Quality to determine if they are still relevant and/or warranted. (These requirements are also referred to as the “demanded quality hierarchy”, “functional requirements”, “hows” or HOQ rows.) This review can be performed in a methodical manner by identifying the maximum rating value for the requirement in question. If the maximum rating is a “0″ or a “1″ (indicating that the secondary requirement has only weak relationships to the primary requirements), then the requirement should be considered for removal from the HOQ due to its relatively low importance.

Lastly, one should also regularly review the primary requirements for any House of Quality to see if they are still relevant and required. (These requirements are frequently referred to as the “quality characteristics hierarchy”, “customer requirements”, “whats”, or HOQ columns.) If the relative weighting of any of these requirements approaches zero too closely, it should be removed.

Finding the Missing Links

In addition to removing redundant or insignificant requirements from a House of Quality, one should also take care to ensure that the HOQ’s requirement lists include all of the needed requirements. It is just as important to make sure that requirement lists are comprehensive as it is to make sure that they are “well groomed”. The best way to review a House of Quality for missing secondary requirements is to inspect the maximum rating values for all of its primary requirements. If the maximum rating for any primary requirement is a “0″ or a “1″ (indicating that the primary requirement has nothing more than weak relationships with any of the secondary requirements), then the primary requirement is not being appropriately addressed. Thus, a new secondary requirement should be added to the HOQ for the express purpose of satisfying the needs of the primary requirement in question.

Summary

It is very import that the requirement lists for any given House of Quality are added to with care and prudence. An HOQ can quickly become unwieldy or cease to be useful if requirements are added to it haphazardly or if essential requirements are omitted. Luckily, the following guidelines can assist QFD teams in producing a well-groomed and comprehensive Quality Function Deployment model:

  • Remove any requirements that are proper subsets of other requirements or other groups of requirements.
  • Consider removing any secondary requirements that do not possess at least one moderate or strong relationship with a primary requirement.
  • Consider removing any primary requirements whose relative importance is significantly close to zero.
  • Ensure that every primary requirement possess at least one moderate or strong relationship with a secondary requirement. If necessary, add secondary requirements to satisfy the unaddressed primary requirements.

These simple guidelines will help QFD teams to construct models that will not only champion the voice of the customer, but that will be maintainable as well. Although the process outlined above is not as simple as cutting off requirements lists at an arbitrary number, the reward for following these procedures will be a sound Quality Function Deployment model that will increase communication, appropriately prioritize efforts, and assist in making sure that a product or service meets all of the needs of its customers.

This entry was posted on Tuesday, October 9th, 2007 at 5:00 pm and is filed under House of Quality, Advice, Agile, Quality Function Deployment, QFD. You can follow any responses to this entry through the RSS 2.0 feed. You can also leave a response.

2 responses about “When to Say When”

  1. Fred said:

    It seems like it would be appropriate or helpful for tools to highlight or somehow indicate to users that the “whats” are not adequately being provided for or that the “hows” aren’t actually helping any of the “whats”. Knowing the aforementioned principles, it is still easy to miss these points while maintaining, using or just reading a QFD.

  2. muhannad al nabulsi said:

    Asimple example is missing,just to elaborate the concept in few words,
    thanks and regards

Leave a Reply