Cost of Quality: Well, hello, my old, complex friend….

Dawn Keller | 12 February, 2013

Topics: Project Tools, Six Sigma, Quality Improvement, FMEA

As I sat down to examine Cost of Quality (COQ) at Minitab, I flashed back to my CQE exam almost 20 years ago. I can still vividly remember staring down at a particularly difficult Cost of Quality question and wondering why I didn’t just follow my 4th-grade career assessment and become a novelist.  

Mental note: a study of the correlation between 4th grade career assessments and actual career paths would make for an interesting blog post.

I briefly considered fleeing the building, buying a bottle of absinthe and channeling Hemingway.  But then I remembered that, even with absinthe, I was no Hemingway and was probably ill-equipped to produce the next great novel.  So, alas, I stayed, answered the COQ questions, and here I am 20 years later: assessing the cost of software quality.

Okay, the absinthe part isn't true. Everyone knows that the Alcohol and Tobacco Tax and Trade Bureau didn't lift the absinthe ban until 2007.

Though it is a bit complex to calculate, Cost of Quality is a very worthwhile evaluation. The study of COQ, and process improvements surrounding it, can help to reduce costs while improving outgoing quality levels.

Components of Cost of Quality (COQ)

Cost of QualityThe Cost of Quality has two main components: the cost of good quality (the cost of conformance) and the cost of poor quality (the cost of non-conformance).

The cost of poor quality consists of those expenses surrounding the failure to meet customer requirements. These include internal failure costs such as re-designing, reworking due to design changes or defects (also called “bugs” in the software world), and the costs of re-testing.  It also includes external failure costs like lost sales, technical support calls, and processing customer complaints.

The costs of good quality are the costs associated with preventing and appraising the quality of the product. Appraisal costs include such things as testing throughout development and product reviews. Prevention costs include things like quality improvement activities, education, and failure prevention analysis (example: FMEA analysis).

Impacts on Cost of Quality

Studies have shown that more than half of software defects are introduced in the design and requirements phase (versus the coding phase). Most people in the software business have probably seen a variation of the "Defect Cost by Development Phase" graph outlining the relative costs to fix software defects. If you haven't, here's the bottom line: the cost to fix an error gets exponentially worse as time goes on. It is estimated to be 100 times more expensive to fix an error in the maintenance phase than in the design phase. This study holds true at Minitab, as well.  The earlier we detect defects, the better. Nobody likes redesigns. It’s that simple.

Defect Cost by PhaseIn addition, a study has shown that a typical company spends 5 -10% of quality costs on prevention, 20 - 25% on appraisal and the remaining 65 - 75% on internal and external failure costs. 

Managing the Cost of Quality

One view of COQ suggests that we should shift our costs from rework/failure to appraisal and prevention activities. While it’s clearly better to catch stuff the first time around, I’m not necessarily a fan of the “more is better” philosophy.  Whether it is more code reviews, more design reviews, etc., in my opinion, it’s not as simple as cost shifting.

That’s why we quality engineers get paid the big bucks, right?

So, when Minitab assesses cost of quality, it’s part of a broader continuous improvement effort. We definitely want to shift our focus to earlier in the process, but  not necessarily by adding more inspection to the front end.

Our goal is to prevent issues and, if they occur, to detect them as soon as possible. We use various techniques to do that, including:

  • Get our customers involved.  Early. Earlier than early.  
  • Plan. Plan. Plan. We are thoughtful about how we plan feature development throughout a release cycle. If we are trying something that might have an impact across the application, we want it done as early as possible. The feature will then benefit from the development and testing of every other feature implemented after that.
  • Test Early. Test Often. We focus on validation as early as design. Ensuring that requirements are met is done initially and continually.
  • Ownership. We all own the quality of the product at Minitab. Don’t deliver unclear or incomplete designs. Don’t deliver buggy code. Don’t deliver buggy software.

In the end, maybe calculating COQ isn't as glamorous as writing the next great novel. I doubt my quotes are going to appear on Pinterest.  (I’ll keep looking, but I doubt it.)  I'm just an engineer who is passionate about customer focus, quality and efficiency, but that's glamorous enough for me!

Now, where's that absinthe?