A long time ago, in a conference room far, far away, our Quality Engineering team 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. This day led to the Customer-Driven Quality framework.

The first exercise as a team was to define quality. We brainstormed in separate teams, filling 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. At the end of the exercise, we had 37 different quality attributes.

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

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 after they accept it, after the project is complete. That is too late. 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.

Customer-Driven Quality – The Framework

Customer-Driven Quality is a set of practices for developing software to ensure that customer’s expectations are met or exceeded.

Customers are, naturally, at the center of the framework. Everything we do in this methodology is about building the right software for our customers. Surrounding the customers is the iterative software development life-cycle: Define -> Build -> Test -> Support. Traditionally, the definition and support phases of the life-cycle involve (or should involve) customers. Customer-Driven Development involves customer interactions throughout.

Surrounding the development life-cycle, several practices help the organization prepare for developing software. Before you can build software for your customers, you need to learn about your customers, your developers need to build empathy for your customers, your organization must focus on customer-driven development, and directly engaging with customers removes communication filters and inefficiencies.

Practices for Customer-Driven Quality

The practices for Customer Driven Quality are described in the following posts:

I’ve been using many of these Customer-Driven Quality practices to focus on what is truly important, delivering the quality that our customers deserve and expect.

Want to learn more? Check out the Software Leadership Academy.