The choice of notation formats depends largely on how much attention one wants to draw to the relative magnitudes between rating values. If an engineer or product manager wishes to encourage more careful analysis of the relationships, then numeric notation is often a better choice. Viewing the exponential scale while one is rating often helps stake holders to be more judicious in assigning "low" and "strong" relationship values. By the same token, if a
QFD practitioner is worried about inducing "analysis paralysis" among the targeted stake holders, then symbolic representation is probably the preferred notation. Symbolic notation often shortens the perceived chasm between "moderate" and "strong" ratings, and helps to reduce the reluctance felt by some stake holders to provide decisive ratings.
The truth of the matter is that 99% of the time, the true “customers” for any manufacturing, engineering, or service project are the internal stake holders. These stake holders (usually the executive business team) determine what constitutes a successful product or service delivery, regardless of the end consumer’s opinion. Put simply, if the consumer market loves a product or service, but internal business objectives aren’t accomplished through the delivery of the product or service, then the project will be deemed a failure. In general, if a product or service development team is to be truly successful, they will have to give focus to the wants and needs of their internal customers before all others.
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....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....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...
In truth, the QFD tool is very useful for avoiding waste in the early design phases of any project. However, it is not the use of the Quality Function Deployment tool in applying Lean principles that has had the largest influence on QFD usage. On the contrary, it is the application of Lean principles to the QFD tool itself that has had such a profound impact on its adoption. In other words, it was the introduction of waste-conscious modifications made to the QFD that has broken down some of the barriers to QFD use in mainstream settings.
Considering that in a spreadsheet environment secondary requirements are generally edited far more than primary requirements (the primary requirements list or “quality characteristics hierarchy” is usually pulled automatically from other Houses of Quality in the QFD), have you ever wondered why it is that the secondary requirements are the ones that are flipped on their sides and run across the top of the HOQ?...Because it was paper-based, there was no benefit one way or the other as to which set of requirements took which axis when the QFD tool was originally created. Most people just rotated their page to write in secondary requirements, and there was no reason to swap the orientation of the primary and secondary requirements. Today, however, very few people produce Quality Function Deployment models by hand. Most engineering and management teams use proprietary software or spreadsheets (and you’ll note that rotating most monitors is not nearly as easy as rotating a piece of paper)....So if you are looking for a way to simplify your QFD process, you just might find that changing the direction of your headings may get you heading in the right direction.
“Quality Function Deployment” was originally created by two Japanese professors back in the 1960's (Drs. Yoji Akao and Shigeru Mizuno)....The original Japanese name, “Hin-shitsu Ki-no Ten-kai”, was translated quite litterally into the name "Quality Function Deployment"....However, these prioritization matrices were only a small part of the system that Drs. Akao and Mizuno originally created.
The issue of prioritizing the pool of features to be developed under an Agile methodology is indeed a vexing one....Unfortunately, prioritization in Agile environments is typically made by “best guesses”, rather than any form of data-driven decision making....Implementing Quality Function Deployment when moving to an Agile methodology can help to alleviate many of these executive concerns while building a better, more customer-focused product....The benefits of moving to an Agile development methodology combined with QFD prioritization go far beyond just pacifying fears and replacing old high-level management tools, however....These executives will find that they have the ability to release software that meets their customers’ wants and needs while their customers still want and need it.
When I asked why they had removed the "difficulty" row from their QFD, I was met with questioning glances and the response, "difficulty row?"...I encouraged them to scrape off the glue and reinstate the difficulty column in their QFD. Doing so would not only allow them to communicate to stake holders why certain features were being temporarily skipped, it would also help them to more accurately remember estimates for features that became de-prioritized due to changes in upstream Houses of Quality....Before you decide that entering difficulty values in your QFD isn’t worth the effort required to do so, you should consider whether or not difficulty will affect your prioritization. If cost, complexity, and/or difficulty will affect your prioritization, then before you decide that entering difficulty values is too laborious, perhaps you should instead ask yourself, “how hard can it be?”