But "quality" is not one of the "Triple Constraints"! The PMBOK(R) teaches us that every project must balance time, cost and scope. When budget and schedule are constrained, it is scope that must be given up, not quality! And it is increasing scope (not quality) that increases costs or schedules.
"Grade" refers to the set of attributes on which the quality of a product will be judged. For example, you can buy beef in various grades (like "Prime" and "Select"). The government has defined a set of attributes for each grade concerning things like fat and gristle content. A low-grade cut of beef that meets all of the requirements for its rating is indeed "high-quality". While a high-grade cut that has been in the display case too long is lacking in quality (even though it still meets the definition for its grade).
The grade of the product to be produced is one of the components of project scope, and so it can be traded for cost or time. If you want a software product with lots of "bells and whistles", then it will cost you more time or money, while only one "bell" and two "whistles" will be significantly cheaper. The adage, "Fast, cheap, or good; choose two," is valid as long as we interpret the word "good" to be referring to grade, and not quality!
Once the requirements for the product have been agreed upon, its quality refers to the degree to which it meets those requirements. Producing a poor-quality product does not save time or money. In fact, as we will discuss later, quality problems actually cost us time and money!
Defect Detection is the set of activities that we normally associate with software quality: preparing for testing, running tests, doing peer reviews or software inspections, and maintaining testing tools, infrastructure and the testing group. These costs are almost always counted as quality costs and show up in the budget (both project and department) as our cost of quality.
Increasing the focus on product quality means allocating more resources to these activities. Since these tend to be seen as non-value-added overhead activities, increasing their costs is difficult to justify. That is why it is important to consider the other two components of Cost of Quality to determine what activities are justified.
Defect Correction is the set of activities that are triggered by the discovery of defects. Of course it includes reporting defects and managing the defect reports. But that is a relatively small part of the cost. The major defect correction cost is incurred by the engineers who must investigate and diagnose the problems, devise an appropriate fix, and rework the product to bring it into compliance. In addition, this includes the cost to test the fix and regression test the system to ensure that the fix did not introduce other problems. And if the problem was reported from the field, it includes the cost of distributing the fix and supporting the customers who encounter the problem.
On most software projects, the engineering cost just described is merely counted as engineering cost, making it an invisible cost of quality. Every time the engineers must fix a problem, the cost of the project increases, but that increase is not accounted for as a cost of quality. In addition, the re-testing is counted as a defect detection cost, hiding it in the wrong part of our cost of quality.
Defect Correction is often the cause of budget and schedule problems on projects, as the engineers and the testers both spend unanticipated time and money dealing with defect correction.
Defect Prevention includes any activity that can result in defects not being put in the product in the first place. This includes requirements engineering, architecture and design activities, coding standards, process improvement, and project retrospectives. Most organizations count these as overhead activities that are not related to project performance, and so they minimize them or avoid them altogether.
If these were counted as costs of quality, then they could easily be managed to ensure that they are justified, as we will discuss next.
When we minimize defect detection costs (e.g. eliminating peer reviews and abbreviating testing), we usually increase defect correction costs. This happens because the defects are still found, but they are found later in the project, when they are more expensive to correct. By investing in defect prevention and early defect detection, we can drive defect correction costs way down. This results in minimizing our total cost of quality. At the same time, it can compress our schedule as we save more time in defect correction than we spend in detection and prevention.
So, you want to save time and schedule on your project? You can't get there by minimizing quality. In fact, if you invest in the right activities, you may be able achieve those goals and improve quality too!
(R) "PMBOK" and "Project Management Body of Knowledge" are registered trademarks of the Project Management Institute.