Repurposing the Roof

For years, I questioned the return on investment provided by filling out the “roof” portion of a House of Quality. It is a very tedious process. I also frequently forgot to review the roof during actual product development periods. To be honest, I was never entirely certain what to do with the knowledge that two requirements had a positive or negative correlation. The fact that they had a positive correlation seemed simply to be a bonus that didn’t really require documenting. Additionally, negative correlations seemed like an unfortunate fact that simply had to be accepted as one tackled requirements in prioritized order.

The advent of new design principles have brought me renewed value for the data documented in the roof of an HOQ, however. For example, negative correlations can assist in identifying “contradictions” for use in the TRIZ methodology.

Remodeling the Roof

Yet, it is not just the repurposing of the roof that has made it valuable, but also the remodeling of it. One such redesign is the addition of the “dependency”. Many times requirements are not just correlated, they are dependent on one another. Under these circumstances, it is sometimes impossible to satisfy one requirement without first addressing another. This means that a requirement with a lower relative weight may need to be completed before a much higher ranked requirement.

Applications in Agile

Take software development, for example: a feature such as “user account creation” may have a substantially lower relative weight than “editing and retaining user preferences”. In reality, user accounts are of little value in and of themselves. It is only when additional features such as “data security”, “user-to-user communication”, and “user preference administration” are added that user accounts become of value. However, these valuable features cannot be added until after the ability to create a user has been added.

Under Agile development methodologies, the list of requirements in the “Feature Sets vs. Features” House of Quality can become quite large (measured in hundreds). In this setting, it is quite difficult to keep track of the various dependencies that may exist so that development assignments can be doled out in a logical fashion. By documenting dependencies in the correlation matrix of a QFD, however, a product manager or project leader can quickly determine if the feature with the highest relative weight is truly the next feature that has to be developed. If the feature with the highest weight depends on another feature, then it is the “depended-on” feature that must be addressed next. (Occasionally, a trail of dependent requirements must be followed until one is finally found that doesn’t have any prerequisite features.)

Innovations in Innovation

I truly am fascinated with the modifications that engineers and analysts have been made to the House of Quality matrix. The addition of concepts such as “dependencies” is evidence that just like products or services, methodologies need to be continually refined in order to ensure their usefulness. In short, remodeling in response to the voice of customer leads to greater value. (Perhaps if I could have convinced my parents of that principle, they would have let me turn our attic into my bedroom.)

Some of the more advanced features of the application include the ability to sort rows and columns by name, weight, or custom sort orders. Additionally, changes made to the names of requirements or their relative positions in the matrix automatically propagate to previous and/or subsequent Houses of Quality.

The most impressive feature of the software, however, is its ability to allow multiple users to view, edit, and manipulate data within the same QFD at the same time from differing machines. The product allows user to invite “collaborators” via email, who can then login to view and/or modify any of the House of Quality diagrams in the QFD (not just the one that the owner happens to be editing at the time). Users can view the changes being made by other collaborators in real time, and can tell which cells other users are modifying through the use of different colors for focus-highlighting.

The “QFD Builder” application allows users to “create, store and share Houses of Quality online”. It does not, however, provide the ability to create Failure Mode and Effects Analysis (FMEA) diagrams. Nor does the software provide a competitive analysis matrix. However, the application does boast a very prominent “Feedback” button which allows user to submit enhancement requests, so one can assume that additional functionality is coming.

All-in-all, the software is intuitive and easy-to-use. It ability to collaborate with stake holders makes it quite powerful. The fact that QFDs can be stored and accessed via the Web is also quite beneficial as it provides a centralized storage location and a single authoritative copy of the QFD for any given group of stake holders. Perhaps best of all, the software is currently being offered for free, which is quite impressive considering that competing QFD software retails for hundreds to thousands of dollars for a single user license.

(more…)

I asked the team how they knew that a given feature was too complex or time-consuming to complete before a scheduled deadline. I was informed that team members were assigned to do some preliminary analysis on top features in order to estimate how difficult it would be to complete them. When I then asked where they logged this information, I was informed that they “just remembered it”. I then asked how they communicated this information upstream to the business stake holders and received some blank stares. When I asked why they had removed the “difficulty” row from their QFD, I was met with questioning glances and the response, “difficulty row?” (more…)

(more…)

Similarly, the name “Quality Function Deployment” gives little hint as to what the tool actually is or what purpose it serves.  So why is its name so perplexing?  The answer lies in two main issues…

First, “Quality Function Deployment” was originally created by two Japanese professors back in the 1960’s (Drs. Yoji Akao and Shigeru Mizuno).  Thus, the process was originally given a Japanese name, which was later translated into English.  The original Japanese name, “Hin-shitsu Ki-no Ten-kai”, was translated quite litterally into the name “Quality Function Deployment”.  Although the name supposedly carries with it a more intuitive meaning in Japanese, it doesn’t seem to have the same readily apparent meaning in English.

Additionally, the term “QFD” is used by many people today to refer to a series of “House of Quality” matrices strung together to define customer requirements and translate them into specific product features to meet those needs.  However, these prioritization matrices were only a small part of the system that Drs. Akao and Mizuno originally created.  (See “What is the House of Quality?  Why it isn’t a QFD?” at qfdi.org for more information on this topic.)  Thus, the application of the term “QFD” has changed over the course of the past 30+ years as well.  Even though much was lost in translation from its Japanese name, “Quality Function Deployment” was a much more apropos name for the system of processes originally created by Akao and Mizumo than it is for the derivative tool that it has come to refer to today.

Numerous QFDs fail (i.e. cease to be used or to be useful) because too many features are added to the relevant product or service in a manner that bypasses the QFD altogether. These assignments are made in a manner that circumvents the system in order to address “urgent” requirements. Unfortunately, as soon as a window is opened for non-customers to push “urgent” matters to the front of the queue, they stop using methodical processes for prioritization altogether. Soon, every pet project or feature gets identified as “urgent” or “imperative”, and the QFD falls to the wayside with the voice of the customer close behind.

This may seem like an easy problem to fix—all that needs to be done is to make sure that these “urgent” items get added to the QFD like every other feature or requirement. If needed, these items can be evaluated and rated before other requirements, but they won’t be worked on until they merit attention. The problem is that many of these urgent items would never warrant attention, according to the QFD, because the wrong customer was identified in the first place.

(more…)

(more…)