posted 11 July 1999 12:04 AM               

From: Pat Dey
Subject: RE: Q: Defining "cost of quality" /.../Dey/Multhopp/Dey

I should have said "more precise".

In software development, prevention, appraisal and failure costs can be measured in terms of effort spent on process improvement, inspection and test, bug fixing, help desk etc. The ultimate costs of non-conformance in terms of lost business, lost references and so on can be estimated well enough to focus attention.

Using CoQ vocabulary with (more) precise definitions sharpens the debate away from generalities about quality, to specifics of what the customer really wants.

Classifying costs using the CoQ idea means that investments in process improvement can be measured for effectiveness. Examples:

A process improvement program costs effort, which increases CoQ in the short term. However, if it's successful, CoQ ought ultimately to go down -- by more than the process improvement cost. (That's why quality departments should always be small IMHO.) Since there will be a lag, a pay-off period might be defined up front.

Adding inspection to a software development process will drive CoQ up but ought to reduce downstream testing and failure costs: net result ought to be to drive CoQ down. If it does not, then either the software is so well written that inspection is redundant, or the inspections are inefficiently conducted -- or the software is so bad everyone gave up reporting bugs long ago.

On guesswork: my experience in software has been that when several 'experts" meet to form a "judgement" they often argue, interminably. Frequently the sad result is that the loudest or most senior person takes the decision arbitrarily. Since there's little buy-in, the work proceeds with low commitment, morale goes down and the ship is aimed squarely at the rocks.

In software quality, a frequent problem is that "quality" is frequently misunderstood to mean "perfect" -- and nobody agrees what "perfect" means. Meanwhile the customer only wants, and is only willing to pay for, "good enough and on time".

Further, costs are neither understood nor controlled. Managers fear that by investing in new tools and processes costs will go up whilst quality stays the same, and engineers can't quantify ROI for improved processes and tooling.

By adding structure to the guesswork, defining terms and asking for costs and probabilities to be estimated or -- yes -- guessed, some mutual understanding and structure is brought into the debate. More people can understand the reasoning behind the decision. If the figures happen to be available, so much the better.