Cost of Quality Is the Language CFOs Understand

Of all Quality Assurance metrics, Cost of Quality may be the only one that requires no translation for senior management — and, ironically, it is also the least measured. While we engineers discuss defect density, functional coverage, and lead time, the CFO reasons in terms of cost, risk, and return; and Cost of Quality is precisely the point where these two languages meet, to begin with.

The problem is that, since this cost is rarely made explicit, it ends up absorbed (in estimates, proposals, and planning) as development cost. In other words: the technology budget carries a hidden component that distorts the real productivity of teams and turns engineering into an opaque cost line — the kind that senior management only knows how to cut, because it cannot read it. Philip Crosby, one of the founding fathers of the discipline, summed up the issue in the provocation “quality is free”: what is expensive is not quality, but, rather, non-conformance; and it is this price of non-conformance (what we spend, or fail to spend, on prevention, appraisal, and correction) that should drive investment decisions regarding processes, tools, and team profiles.

And here it is worth bringing back Fred Brooks. I have written in this space before about his iconic “No Silver Bullet” and the distinction between essential complexities (inherent to the business domain, irreducible) and accidental ones (created by us, software engineers, ourselves). I propose extending this distinction to Cost of Quality: there is an essential component of this cost, derived from domain complexity — there is no “cheap” version of ensuring conformance in a credit approval process, with its regulatory and business requirements — and this component cannot be eliminated by architecture, tooling, or model, lest we fall into the very same silver bullet illusion. But there is also an accidental component: bureaucratic defect lifecycles, rework caused by poorly translated requirements, automation built without governance or maintenance. It is only this second component that we can (and must) attack; and it is only measurement that allows us to separate it from the first.

Without this separation, incidentally, silver bullet purchases are born: a cutting-edge tool is acquired (nowadays, typically, some AI solution) to attack a cost that was, at the end of the day, procedural bureaucracy. In my experience, I came across a project that showed a low escaped defect density (on paper, a success story) but whose cost per defect was so high that the few bugs found compromised entire timelines; the culprit, uncovered precisely through the exercise of decomposing the cost of defects, was a triple approval flow in the defect lifecycle, which inflated reporting time. A low defect density is worthless if each bug costs a small fortune; and no tool would solve what was, essentially (forgive the Brooksian irony), an accidental problem.

The scale of this is far from trivial: the CISQ consortium estimated that poor software quality cost the American economy US$ 2.41 trillion in 2022 alone — a GDP-sized number that nevertheless remains invisible in corporate budgets because it is scattered, project by project, inside “development cost.”

Making Cost of Quality explicit is, therefore, what allows senior management to treat Quality Assurance decisions as investment decisions with ROI; it is what takes technology out of the condition of a cost line to be controlled and places it in the condition of a results engine to be scaled; the first step requires no tool at all: it requires recording how much the team spends preventing, appraising, and correcting. The mere exercise, I assure you, already reveals bottlenecks.

Source: “The Cost of Poor Software Quality in the US: A 2022 Report”, CISQ (https://www.it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2022-report/).