Joseph Juran, one of the founding fathers of the quality movement, published the idea of a "Cost of Quality" or "CoQ" in his Quality Control Handbook in 1951. Since it was a metric developed in the manufacturing context, it is often seen as the quality-related costs seen in building physical products in an assembly line method.
The CoQ is a little confusing because it can defined in different ways. To some, it is not the total cost to achieve quality, but rather the cost of NOT achieving quality. This is also called the "cost of non-conformance." This was the view of Phillip Crosby, who wrote the book Quality is Free in 1979.
There is also the "Total Quality Costs" (TQC) view that is comprised of more than costs of non-conformance, such as the costs of assessment and prevention. The confusion arises because many people equate TQC to the CoQ. I tend to take that view and include prevention and assessment costs in the CoQ.
As a software quality practitioner and consultant, I have often considered whether adjustments are needed to accurately apply the traditional CoQ to software quality. As a software quality practitioner and consultant, I have often considered whether adjustments are needed to accurately apply the traditional CoQ to software quality. This article will explain the traditional CoQ metric and also consider additional costs seen in software projects, but not typically seen in manufacturing.
As a point of distinction, in this article I will distinguish between the "traditional CoQ" and the "software CoQ" (which I'll refer to as CoSQ in this article).
I'm not the first person to write about the distinction between CoSQ and CoQ. Cem Kaner wrote an article published in Software QA on this topic in 1996 and Herb Krasner wrote an article for CrossTalk in 1998 on this topic.
However, I hope that this article helps in some small way to continue the thinking processes to help adapt this valuable metric to software projects. My goal is to promote a metric that clearly shows to management in companies why it makes sense to embrace software quality instead of ignoring it.
What is the Cost of Quality?
Like so many things in quality, usages and meaning of this term vary depending on when and where they were learned. I learned the following computation from my days in preparation for the CSQA (Certified Software Quality Analyst) certification:
The traditional CoQ is comprised of:
The cost of defect prevention - This can include process improvement, training, root cause analysis, or any other activities to prevent defects.
The cost of defect detection - This can include inspections, testing, or any quality control (QC) activities designed to find problems before customers find them.
The cost of failures - This includes both internal and external failure costs. Internal failures are the costs associated with the product before the customer receives it. External failures are the costs associated with the product after the customer receives it. In the manufacturing context, this also includes warranty costs. In many ways, both of these are the costs of rework and waste, but also can include the costs a failure may have on other items, people, projects, etc. These costs can also include the clean-up costs of a failure.
Just as a benchmark, the CoQ can typically range from 15% to 40% (source: qualityportal.com) of the cost to make something. For example, in software, that would be a percentage of the total project costs.
What Does the CoQ Indicate?
If you include the costs of prevention and assessment, the CoQ shows how much an organization spends to deliver products of acceptable quality to customers. However, if your view of CoQ includes just the failure costs, it is the cost of not achieving quality.
In 1979, Philip Crosby wrote one the groundbreaking books of the quality movement in the U.S., called Quality is Free. My first reaction when I saw the book's title was confusion because it seemed that quality costs a lot to achieve. However, as I read the book, Crosby's point was that while it does cost money to achieve quality, it costs more not to achieve it. In other words, quality improvement pays for itself many times over by preventing costly quality problems.
Another way that Crosby explained it was that when something is done right the first time and no rework is needed, then quality costs nothing. However, then something has to be scrapped or reworked, additional costs are seen. (I still think that it costs something extra to do something right the first time, but that's just me!)
As a real-life example, I was at the Oklahoma City airport recently getting a quick meal before my flight. When I opened the sack, I realized I had someone else's order. So, I took the sack back to the counter and explained that I had the wrong order. They were very apologetic and got my order to me, but since I had already walked away from the counter they had to discard the food I had taken the first time. This is where getting something wrong had a tangible cost to the food vendor.
Until you look at each component of the CoQ, it's impossible to know what the percentage number really means. For example, two companies may each have a 30% cost of quality. Company "A" spends almost all of its CoQ on rework and has unhappy customers, while Company "B" spends almost all of its CoQ on prevention and assessment and has happy customers.
An Interesting Dynamic
You might initially think that when you increase the cost of detection or prevention, you are just shifting the allocation of costs. For example, instead of spending 10% of a product development cost in failure cost, you may think of just spending that 10% in better testing or detection. However, there is a dynamic at work that is interesting and powerful.
For example, for every dollar that you spend in prevention and detection, you often save many more dollars in failure costs. The multiplier varies by organization and when a defect is found, but suffice it to say that this is a winning proposition. This is the case Crosby made in "Quality is Free".
Therefore, it is very feasible to reduce your CoSQ and at the same time improve quality and increase profits. Remember that every dollar spent on failure costs is one less dollar of profit. Consider multi-million dollar project failures and you have not only a costly project failure, but an equivalent profit loss! (Management may say, "Oh well, it's just a write off to the business." I say, "So are bonuses!")
The Impact of Poor Quality on Software Projects
One cost impact that seems to be very applicable to software is the cost of a failed or delayed project. Although this could perhaps be assigned to internal failure costs, the CoQ context is typically seen as the cost of product rework.
An example of this is when a project is delayed by three months because of high levels of defects found during user acceptance testing. This three-month delay causes:
- other projects to be delayed because resources are consumed with the project at hand,
- the company to lose five major contracts because a competitor beats the company to the marketplace,
- the company to spend $100,000 a month for additional staff required to support the manual work processes that are automated by the new project.
Another example is of the project that is canceled after spending $44 million on requirements specification and system analysis and design. It is determined at this point in the project that the approach is simply not feasible and that spending further money is too risky.1
Security Costs
Consider the cost to both customers and the company when customers' private data is compromised. In the case of Providence Health Systems of Portland, Oregon, the cost of a data breach has been enormous. According to Information Week, "A company official told the Portland Oregonian that he expects the case, not including litigation costs, to cost from $7 million to $9 million. That includes providing affected patients with access to credit monitoring and restoration services. There's also the prospect of civil lawsuits by state agencies or individuals whose data was stolen, potentially costing millions more."2
"ChoicePoint paid dearly earlier this year when it agreed to pay $15 million in fines after unwittingly selling more than 100,000 consumer credit reports to thieves posing as legit customers. The FTC said the company didn't have "reasonable procedures" for screening customers."3
These costs do not include the costs to customers who had to spend many hours trying to contact the credit reporting agencies, monitoring their credit card accounts and resolving fraudulent transactions.
Opportunity Costs
Poor quality software can also place a company in a position where opportunities are missed because of the inability to respond quickly. Consider the example of a bank that identifies a market opportunity. They present the idea to their IT department which provides an estimate of eight months because of high backlogs of fixes needed because of a previous project that is still experiencing problems, plus there is no project life cycle process in place. The result is that projects take longer and experience a high number of defects. Yet, nothing is ever done to improve the situation because "we don't have the time or the money" or "we're still making a profit, aren't we?"
However, what if the cost of losing the business opportunity is over $20 million dollars in lost profit? You can improve a lot of processes with that kind of money!
Why are the CoQ and CoSQ Helpful?
The main reason these metrics are helpful is because they are focused on money. I often tell people in my training classes on software testing that if you look deep into the eyes of management, you will see dollar signs and calendars.
What I mean is that money and time are at the forefront of many software managers' and executives' minds. It's hard to make a case on the goodness of quality, increased customer satisfaction, or even risk. The executives and managers ask "Where's the profit in it?" That's the question you must be prepared to answer about software quality and the CoSQ can help you do that.
Juran noted, "Because the main language of [corporate management] was money, there emerged the concept of studying quality-related costs as a means of communication between the quality staff departments and the company managers."4
How to Use This Metric
The CoSQ is a powerful metric to show management that software quality is a business opportunity, not a cost center. Yes, "quality" is a fuzzy concept and fails to resonate many times, but the costs are not fuzzy or trivial. In fact, the costs are very measurable and the companies that understand their CoQ often see higher profits because waste is reduced and opportunities are realized.
I suggest taking a baseline snapshot of your organization's cost for the major cost areas (The items shown are a suggested starting point. You may think of others.):
Prevention costs:
- Training
- Root cause analysis
- Process improvement
Detection costs:
- All forms of software and system testing
- Reviews and inspections
- Help desk costs
Internal failure costs
- Rework costs
- Delayed project costs
- Wasted time
External failure costs
- Tech support call costs
- Rework
- Patches and post-release fixes (such as hot fixes)
- Failure costs to customers
- Lost sales
- Penalties
Another good thing to do is to start measuring the average cost per defect. I know of situations where people were surprised to learn that the average cost of a defect exceeded $5,000 in their organization. You can improve a lot of things for the cost of just 4 or 5 defects!
Use Examples from Your Organization
These shouldn't be hard to find. Try to find situations where problems caused high dollar costs, or where problems have been prevented by improving processes or by inspections and testing.
Be careful with this! People can get very defensive when you use their projects as your poster child. Before using any example as a case study, I always talk to the people involved and get their blessing as well as their feedback on the accuracy of the numbers.
A Word of Warning
Don't overreach in your calculations or oversell the value of software quality. The first thing that will happen when you start discussing the CoSQ metric is that your numbers will be scrutinized and discounted. If your numbers turn out to be inflated and your claims appear to be too high, you will lose both your message and your credibility.
Instead, be conservative in your cost assumptions and don't over-promise value. You can do this and still show the powerful value of software quality.
About Your Customers
Dr. Juran was big on the idea that we have both internal and external customers. I agree that we must consider both perspectives.
I have heard some people downplay the importance of internal customers because they don't buy products or services. True, but I would argue that internal customers also generate profits because they sell things, they keep valuable customers, they develop new products and services to sell, etc.
While the external customers are very, very important, the internal customers are the ones that make the decision whether or not to outsource IT function
Many companies measure customer satisfaction. I used to think this was great until I read a book by Jeffrey Gittomer called,Customer Satisfaction is Worthless, Customer Loyalty is Priceless
This reminds me of a time I was presenting the findings and recommendations of a software testing assessment to an executive team at a financial services company. This company was spending over $250,000 a year just on the salary costs of the developers who were resolving daily software problems. The system was responsible for moving billions of dollars daily.
At one point in my presentation in which I described the risks in their current methods, the VP of Marketing spoke up and said, "The only metric I care about is how many customers we have lost, and we haven't lost any." Therefore, he saw no need for improvement.
About six months later, the CIO that had hired me for the assessment called. She was working for a different company and told me that a major "incident" had occurred and they did lose customers. The problem was that all the people who could have fixed the chronic nature of the defective software had left the company in burnout and frustration (I suppose that could be a metric as well).
Conclusion
Dr. W. Edwards Deming taught that a business is comprised of functions and activities, which can be identified, measured and improved. The goal of this effort is not to score higher on an assessment or to reach a certain level or to win an award. The goal is to improve the way a business does its work so that it becomes more profitable and healthy.
One of the key metrics that can drive this type of improvement is the Cost of Quality (CoQ). For software, we need to consider a wider view to include the costs that are typically not seen in manufacturing.
The CoSQ can be a valuable tool for conveying the value of software quality for the purpose of improving the business. Don't oversell it, but use it as a way to show the value of quality and a way to benchmark your progress.
Bio
Randall Rice is a leading author, speaker and consultant in the field of software testing and software quality. Randy has 30 years experience building and testing mission-critical projects in a variety of environments and is co-author of the book, Surviving the Top Ten Challenges of Software Testing. He is the author and instructor of Testing SOA and Structured User Acceptance Testing courses, presented by Rice Consulting Services. You can contact Randall through his web site at www.riceconsulting.com.
