COPQ Calculator (Cost of Poor Quality) for Software Teams

Updated May 2026. Method derived from Juran (1951), Crosby (1979), and current ASQ guidance.

The PAF cost categories

Joseph Juran first proposed the structure that became PAF in the 1951 first edition of the Quality Control Handbook. Philip Crosby popularised the four-category split (Prevention, Appraisal, Internal Failure, External Failure) in Quality Is Free (1979), arguing that every dollar invested in prevention saves several dollars in failure cost. ASQ has carried the framework forward; the modern ASQ Cost of Quality guidance is the canonical reference for the calculation method.

For software engineering teams the categories map cleanly. Prevention is the spend on getting it right the first time: training, architecture reviews, design documents, threat modelling, accessibility audits during design, and the proactive paydown of technical debt that would otherwise generate defects. Appraisal is the spend on confirming quality: automated test maintenance, manual QA labour, code review time, security scanning tools, observability platforms. Internal failure is the work caught before customers see it: bugs found in QA, regressions caught by tests, security findings discovered before release. External failure is what customers see: incidents, hotfixes, support tickets, churn, contractual penalties, regulatory fines.

The PAF balance

Crosby's central argument in Quality Is Free is that the four categories trade against each other and the optimum is not at zero failure cost. Underspending on prevention causes failure costs to balloon, but past a certain point further prevention spend produces diminishing returns. The textbook PAF balance for a mature operation puts prevention plus appraisal at roughly 10 to 16% of payroll and failure cost at roughly 5 to 10%. An immature operation shows the opposite signature: tiny prevention spend, high failure cost, total COPQ above 25%.

When you measure COPQ for the first time, the typical software team finds total COPQ around 22 to 30% of engineering payroll with the failure categories dominating. The most common single source is internal failure, specifically the rework loops on pull requests that fail review or break tests after merge. External failure is usually smaller in raw dollars but disproportionately damaging because it costs customer trust on top of engineering time. The poor testing root-cause page goes deeper on the appraisal underspend that drives most failure cost on a software team.

Worked spreadsheet (replace with your numbers)

The CFO will not accept a COPQ number without a defensible bridge to existing line items. Build the calculation by mapping each PAF category to spend that already shows up somewhere in the engineering or operations budget, then add the missing labour estimates explicitly.

# Inputs
team_size                  = 30                  # engineers
fully_loaded_cost          = 200000              # USD per engineer per year
annual_payroll             = team_size * fully_loaded_cost

# Prevention spend (hours per engineer per year x hourly rate)
training_hours_per_eng     = 40
design_review_hours        = 60
threat_modelling_hours     = 12
accessibility_audit_hours  = 6
hourly_rate                = fully_loaded_cost / 2080
prevention                 = team_size * (training_hours_per_eng
                                          + design_review_hours
                                          + threat_modelling_hours
                                          + accessibility_audit_hours) * hourly_rate

# Appraisal spend
test_maintenance_pct       = 0.05  # 5% of engineering time
code_review_pct            = 0.04  # 4%
qa_team_payroll            = 280000  # standalone QA function
security_tooling_annual    = 90000   # snyk + scanners
observability_annual       = 140000  # datadog or new relic
appraisal                  = (test_maintenance_pct + code_review_pct) * annual_payroll
                             + qa_team_payroll + security_tooling_annual + observability_annual

# Internal failure (rework caught before release)
sprint_rework_pct          = 0.18  # share of sprint points tagged rework
internal_failure           = sprint_rework_pct * annual_payroll

# External failure (incidents + support + churn)
incidents_per_year         = 24
avg_incident_eng_hours     = 18
incident_labour_cost       = incidents_per_year * avg_incident_eng_hours * hourly_rate * 4   # 4-eng war room
support_overflow_cost      = 180000  # quarterly L3 escalations
reliability_driven_churn   = 0.012 * annual_recurring_revenue  # team-specific
external_failure           = incident_labour_cost + support_overflow_cost + reliability_driven_churn

# Total
copq_total                 = prevention + appraisal + internal_failure + external_failure
copq_pct_payroll           = copq_total / annual_payroll

When the COPQ number changes a decision

A COPQ measurement that does not change at least one staffing or budget decision is wasted effort. The three decisions a credible COPQ number usually unlocks are the staffing case for a quality engineering lead (typical break-even at $1.2M to $1.8M annual COPQ), the budget case for a managed observability tier upgrade (typical break-even when external failure exceeds 6% of payroll), and the prioritisation case for explicit tech debt paydown sprints (typical break-even when internal failure exceeds 15% of payroll). The reduce page sequences these decisions by expected ROI.

Where COPQ does not move the conversation is in single-service or single-team budget asks. If the underlying engineering organisation does not have shared accounting for quality cost, a per-team COPQ measurement is a curiosity rather than a decision tool. In that situation the more useful first step is the simpler rework cost formula applied team-by-team, with a portfolio rollup planned for the following quarter once each team has a baseline.

COPQ across the portfolio

Manufacturing companies have been measuring COPQ at the line level for decades. The recurring benchmark from ASQ work is that mature manufacturing operations land at 5 to 8% of revenue, immature operations at 15 to 25%, and the gap can be closed in 18 to 36 months with focused PAF rebalancing. Software companies that have adopted formal COPQ measurement (typically large enterprise SaaS with internal quality engineering functions) report similar starting points and similar closure timelines. The manufacturing rework cost page goes deeper on the cross-industry lessons; the cost of quality page covers the broader Juran framework that contains COPQ as a subset.

One caution: software organisations sometimes import the manufacturing COPQ rate ceilings literally and conclude they are world-class when the failure-cost share looks low. Software has a higher latent appraisal cost (the ongoing maintenance of automated tests is not analogous to a manufacturing inspection line) and a lower latent external-failure cost (a software defect rarely sends a customer to hospital). The shape of the cost curve differs, even when the headline percentages look similar. Benchmark against software-industry data sets like DORA rather than ASQ manufacturing curves.

Sources and further reading

• Juran, J. M. Quality Control Handbook. McGraw-Hill, 1951.
• Crosby, P. B. Quality Is Free. McGraw-Hill, 1979.
• American Society for Quality. Cost of Quality (COQ) Guidance. asq.org/quality-resources/cost-of-quality.
• NIST. Planning Report 02-3: The Economic Impacts of Inadequate Infrastructure for Software Testing. RTI International, 2002.
• Google DORA. State of DevOps Report 2024.
• Boehm, B. Software Engineering Economics. Prentice-Hall, 1981.

Frequently asked questions