The QFD Online Journal

Symbolic vs. Numeric Notation

admin — Wed, 23 Apr 2008 05:40:40 +0000

There has been much debate over which representation is the best to use when filling in the ratings for a House of Quality: symbolic notation or numeric notation. The premise behind the debate is that there is somehow a greater inherent value in using circles, filled circles, and triangles or in using 1’s, 3’s, and 9’s. In actuality, neither format is universally superior to the other. On the contrary, they both serve different purposes and are uniquely suited for working with different groups. Thus, just as it is important to tailor a speech or written argument to the needs of the intended audience, it is important to choose the notation for a QFD that is best suited for its target audience.

The Magnitude of the Measurement

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.

Mathematician or Marketer

Another factor to consider when choosing a QFD notation style is the technical and/or mathematical aptitude of the target audience. Numerical notation is often more appealing to technical audiences such as engineers and scientists who like to understand the algorithms involved in the House of Quality. These audiences frequently prefer numeric notation because it replaces “magical” ranking behavior with a comprehendible scientific process.

Symbolic notation, on the other hand, is often more appealing to business, marketing, and sales individuals. These stake holders are often distracted by numeric notation and begin to view a Quality Function Deployment as a “numbers game” when presented with numeric notation. Using symbolic notation often helps these target audiences to focus on the simple relationships between requirements, rather than on the numbers and calculations involved in a House of Quality. Symbolic notation helps these stake holders view a Quality Function Deployment as the communication tool that it is rather than as the mechanized dictator that it isn’t.

Playing to the Audience

The choice of notation when constructing a Quality Function Deployment can have a major impact on the audience involved. Numeric notation is better suited for teams that are technically-oriented and/or teams that need to focus more carefully on their ratings. Symbolic notation is more appropriate for less-technical audiences and/or audiences that are prone to endless debate over individual ratings.

In truth, there are many characteristics of a QFD that can and should be modified to meet the needs of the audience involved. Different audiences require different communication mechanisms, different meeting frequencies, different meeting durations, different leadership styles, and even different tools. However, when one is tailoring his or her Quality Function Deployment to meet the needs of its stake holders, notation style should not be overlooked. For when it comes to making team members comfortable with a House of Quality, using 1’s, 3’s, and 9’s has a substantially different affect than do circles and triangles. Indeed, when representing a “moderate” relationship in an HOQ matrix, one will likely find that “to three or not to three—that is the question”.

Identifying the Correct Customer

admin — Wed, 20 Feb 2008 00:00:18 +0000

Most people believe that the first step in creating a successful QFD is to identify the list of customer requirements. Although documenting customer requirements is key to ensuring that the “voice of the customer” is heard, there is actually an even more crucial first step. The very first task to complete when creating a Quality Function Deployment is to identify exactly who your “daddy” (i.e. customer) really is, and that task isn’t as easy as you might think.

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…)

Limitting Requirements

admin — Thu, 10 Jan 2008 00:00:24 +0000

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...

Modifying the House of Quality

admin — Mon, 24 Dec 2007 01:30:56 +0000

In 1979, a PBS station in Boston called “WGBH” aired a one-time, 13-part series entitled “This Old House”. Since that time, the program has grown to become one of PBS’s most popular programs, has generated spin-offs, produced a popular magazine, spawned a for-profit website, and even inspired sitcoms.[1] And why has this program been so successful? In my opinion, it’s because people have an inherent love for taking something great, stripping away its faults, and putting it to new found use. That is the same explanation that I use when people ask me about Quality Function Deployment’s resurgence in popularity during recent years. In short, when people ask me why QFD has experienced so much growth in adoption, my answer is simply: “This Old House…of Quality”.

(more…)

Swapping the Requirements Axis For a QFD Matrix

admin — Sat, 01 Dec 2007 02:00:14 +0000

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.

The Origin of Quality Function Deployment (QFD)

admin — Sat, 13 Oct 2007 00:00:17 +0000

What’s in a name? While Shakespeare may have been correct in observing that “that which we call a rose by any other name would smell as sweet”, most people would not know what you were talking about if you referred to it as a “bee leaf pollen perch”.

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.

Using QFD to Prioritize Features in an Agile Methodology

admin — Sun, 22 Jul 2007 01:30:48 +0000

Imagine for a moment that you are the president of a successful software development company. Your company is doing reasonably well from a sales perspective, but you have been dealing with some sizable challenges in terms of your development team hitting their scheduled release dates on time. (The past 2 releases have been late by more than six months a piece.) Then one day your development manager comes into your office droning on about the success of something called “Agile” development methodologies. He goes on to tell you that he knows how to eliminate the slippages that he and his team have experienced in relation to your two year development plan: simply do away with the two year development plan. Needless to say, the conversation would probably not go well. However, there is a sweetener that can assist executive management in swallowing the sometimes bitter pill of “Agile” development—and that sweetener bears the name “QFD”. (more…)

Utilizing the Difficulty Metric

admin — Fri, 15 Jun 2007 08:00:55 +0000

I was recently reviewing a QFD that was created by a group of software developers. They had opted to omit several traditional columns, rows and/or matrices, and had added some new ones. On their final House of Quality they had added a “status” column. Many of the top requirements on this HOQ (the list was sorted by calculated importance) had status values of “Prioritized” or “Completed”. However, I noticed that several of the highest ranked requirements had been skipped and had no status at all. I assumed that these items had no status because they had only recently been added to the QFD. However, I soon learned that my assumption was wrong—these items had been skipped because there simply wasn’t enough time left before the upcoming version release to try to bite off such complex or difficult features.

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…)