How Hard Can It Be?
December 15th, 2007 by Peter Wolfe
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?”
Category: Remodeling the HOQ™, Agile, Quality Function Deployment, QFD | 1 Comment »
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“. 
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. 
Have you ever watched a team of engineers modifying their secondary requirements (a.k.a. the “quality characteristics hierarchy” or “hows”) on a House of Quality spreadsheet? They remind me of a group of hillbillies staring at a piece of modern art—their heads are usually cocked to the side with grimaced looks on their faces. (It’s quite entertaining actually.) Considering that in a spreadsheet environment secondary requirements are generally edited far more than primary requirements (the primary requirements list or “demanded quality 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? 
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.[
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.
