What is quality to you? How do you measure quality? When is quality accomplished? If you don't know how your customers would answer these questions, your product probably doesn't meet their needs as well as it could. You can fix this problem.

But first you have to build a paper airplane.

Celeste Yeakley and Jeff Fiebrich talked about the Q-as-in-quality-Files. Here's how the paper airplane fits in: Celeste and Jeff had each of us make a paper airplane. When we were all ready Jeff told us that he was looking to buy one of our creations. He would be willing to pay thirty dollars for one, in fact. Here's the catch: the airplane had to have colorful logos on it (half the planes are now out of the running), it couldn't have a pointy nose (there go most of the rest), and it had to fit in a three-inch-on-a-side box (there go the last two). Jeff's thirty dollars are still in his pocket.

Jeff had a very particular definition of quality when it came to paper airplanes. When we were working on our creations one person asked whether the airplane had to fly, but most of us just went ahead and made an airplane without inquiring as to requirements. We did, however, build airplanes that *we* thought were quality airplanes that met whatever we perceived the requirements to be. The lesson: everybody has a different definition of quality, but your definition of quality is likely different than your customers' definition of quality.

Celeste and Jeff showed us how to bring the two definitions together by building a "House of Quality": Work with your customer to build a list of needs and requirements, where each requirement is ranked according to its importance to them. Then have them rank your product and your competitor products as to how well each meets those needs. All this data is poured into a funky diagram that bears some resemblance to a house (thus the name House of Quality I suppose). Slice and dice the data a bit and then BAM! you have a graphical depiction of how your customers' needs meet up with your design features and how those features compare to your competitors in terms of your customers' needs. Doing this over and over with each of your customers can help you understand what your customers really want and how that interacts with what you're planning to build.

Complex diagrams that make customers think you know what you're doing are always good, right? <g/> Seriously, the techniques Jeff and Celeste introduced this afternoon seem like they could simplify the process of crawling into customers' heads and understanding what they're really looking for. This information of course has to be updated on a regular basis just like any of the other information we gather, but that doesn't reduce its value anymore than the need to maintain unit tests as your code changes makes them less useful. This process is simple and fast enough, in fact, that it would work really well in an agile environment. "Next year at Software Development: Extreme House of Quality!" <g/>


*** Comments, questions, feedback? Want a fun job on a great team? I need a tester! Send two coding samples and an explanation of why you chose them, and of course your resume, to me at michhu at microsoft dot com. Great coding skills required.