Product Development Systems & Solutions Inc.-click to homepage
News from PDSS Inc.
"Leading the Future in Product Development" 
November 2011- Vol 4, Issue 11
In This Issue
Avoid These 5 Goblins in Yours Houses of Quality
Greetings!   
Our November issue is a little early, as we wanted to wish you a Happy Halloween and present you with some advice to avoid "haunted" Houses of Quality in your product development. Our next issue will be in December on the usual schedule. Enjoy the rest of autumn!

-Carol
Avoid These 5 Goblins in Your Houses of Quality
Halloween is upon us, so today I will advise you on how to avoid a "haunted" House of Quality. In product development, a House of Quality (HOQ) is a tool to help translate customer requirements into measurable technical requirements and prioritize those requirements. The resulting matrix looks like a house with a triangular roof. The tool is also referred to as Quality Function Deployment (QFD).

 

A House of Quality could be haunted by a) too many customer needs and resulting product requirements that weren't differentiated between what is critical vs. trivial, b) a confusing mixture of customer needs and product requirements that are not compartmentalized at the right level and finally, c) customer needs that are merely re-expressed as solutions rather than measurable technical requirements. These common problems can cause fear, mayhem and angst, just as ghosts in a Halloween haunted house! Look for these five goblins in your House of Quality and perform an exorcism!

  

1. Poorly designed Customer Interview Guides:

If we do not ask open-ended probing questions, we will not uncover New, Unique or Difficult (NUD) Customer Needs that are critical to what a customer values. These simply cannot be discovered by anemic, lack-luster Interview guides! Develop them to surprise yourself when you hear the true points of view your customers really have! Don't put your customers on the rack - just ask exploratory questions that give them a chance to open up and express their real issues, needs, desires and frustrations.

 

 

2. Incomplete sorting, ranking and processing of Customer Need Statements:

Once you have great Customer Needs data, you must consolidate redundant statements and determine which are truly New, Unique and/or Difficult (NUD). This means separating the Easy, Common and Old (ECO) needs from the surprising, enlightening NUDs! Use Kano Analysis to help in this discrimination process to see differences between basic satisfaction, linear growth satisfaction where more or less of something is better, and true customer delighters. It is very important to isolate the Customer Needs at the level they apply: system, subsystem, subassembly, layer, part, material... Pay close attention to exactly where in your product's composition these needs apply. Even Dr. Frankenstein got most of the parts in the right place!

 

 

3. Improper translation of Customer Needs into measurable Technical Requirements:

When your customer uses their particular vocabulary and context to express their needs, be very careful to translate their terms into your technical requirements vocabulary and units of measure for fulfillment. Show clear linkage between how you will technically measure the fulfillment of the requirement and how that directly relates back to the customer's original intent and their way of measuring satisfaction or delight. Remember - a werewolf can only be killed with a silver bullet! Vampires will laugh if you only bring leeks and onions!

 

 

4. A lack of Systems Engineering discipline that discriminates between Technical Requirements and places them into their proper level and allocation layer in subordinate HOQs:

To really confuse the development team, make sure you mix all requirements together when you construct your Product Level HOQ! Instead, sort your technical requirements into the appropriate "bins" so they are placed in the proper level of HOQ. Ask your team to think through each translated technical requirement to determine its nature and units of measure. We want each requirement to be "possessed" at the right level!

 

 

5. Confusing a HOQ and a Pugh Concept Evaluation Matrix: 

It always scares me when I find people confusing the HOQ and the Pugh Matrix. The HOQ exists for requirement translation, prioritization, hierarchical allocation and metrification. ONLY NUD REQUIREMENTS belong in an HOQ. Easy, Common and Old (ECO) requirements can go directly into your requirements documents and data base. The Pugh Matrix is for the evaluation of new concepts against a Best-in-Class Benchmark in light of a balanced mix of NUD and ECO requirements. To summarize:

 

 

QFD = REQUIREMENTS DEVELOPMENT, RANKING, PRIORITIZATION & MEASUREMENT; results in HOQ

 

PUGH PROCESS = CONCEPT DEVELOPMENT, EVALUATION, HYBRIDIZATION & SELECTION; results in Pugh Concept Evaluation Matrix

 

The HOQ has nothing to do with concepting except to provide the requirements used later in concept development and evaluation. The HOQ inputs NUD requirements to the Pugh Matrix. Mixing the two can lead to a Dr. Jekyll and Mr. Hyde contrast in your HOQ and that can be a real problem!

 

May your Houses of Quality be free of evil spirits as we pass through the graveyard of dead and decaying requirements. Happy Halloween! 

 

 

Is there a topic you'd like us to write about? Have a question? We appreciate your feedback and suggestions! Simply "reply-to" this email. Thank you!
 
Sincerely,
Carol Biesemeyer
Business Manager and Newsletter Editor
Product Development Systems & Solutions Inc.
About PDSS Inc.
Product Development Systems & Solutions (PDSS) Inc.  is a professional services firm dedicated to assisting companies that design and manufacture complex products.  We help our clients accelerate their organic growth and achieve sustainable competitive advantage through functional excellence in product development and product line management.

Copyright 2011, PDSS Inc.
Join Our Mailing List!
 
See PDSS Inc.'s Archived E-Newsletters