A long time ago, in a conference room far away, our QA organization got together for an offsite meeting, a chance to get away from the hustle and bustle of our day-to-day projects. A chance to step back and think about what is important and perhaps think of new ways to improve our quality.

The first exercise as a team was to define quality. We brainstormed in separate teams, writing dozens of yellow sticky notes. Then, as a group we reviewed all of the ideas, grouped similar items into themes, and started pulling together a comprehensive definition.

We ended up with a large pile of definitions; each one seemed valid by itself. One pile was around meeting a number of “Quality Attributes,” another pile all about following processes and meeting criteria. Another pile was all about defects (more precisely, the lack of defects). And on and on.

The resulting definition was very comprehensive, and complex. One example, we ended up with 37 different quality attributes1, and that was just from 1 pile of sticky notes.

The next question, how does this definition help us build better software? Where should we focus our efforts? Some of the definition parts must be more important than others, but which of the 37 quality attributes were part of the vital few? Did we truly have a workable definition, one that would guide us? Well, in asking these questions, we kept coming around to the pile that was all about customers. Some of the ideas were “increased customer satisfaction,” “lack of customer support calls,” and “high net- promoter.” (Net-promoter is a metric we use to measure customers willing to refer their friends to our product)2 .

One slip had written on it, “Customers Define Quality.” The reaction was yes, this is obvious, but not too helpful. It has that feeling like “I know it when I see it.” It may be true, that our customers will be the ultimate judge of quality, but we only know if they accept it when it’s too late, after the project is complete. We needed a definition that helps guide our efforts before, during, and after the project.

However, by thinking “how can we include our customer in each stage of the life-cycle to improve quality,” we end up with a number of customer centric practices. We call these practices “Customer-Driven Quality.”