Skip to main content

Failure Costs

Author: BVOP

Failure costs are the expenses a project or organization incurs when deliverables, processes, or services fail to meet defined quality requirements. In project management, they are one of the three categories in the cost of quality model, alongside prevention costs and appraisal costs. These costs include rework, scrap, warranty claims, and lost stakeholder confidence, and are often referred to as the cost of poor quality.

Internal and External Costs of Nonconformance

Failure costs are the costs a project or organization incurs when deliverables, processes, or services fail to meet defined quality requirements. In project management, the term usually refers to one of three categories within the cost of quality model: prevention costs, appraisal costs, and failure costs. Failure costs represent the monetary and non-monetary consequences of defects, rework, returns, warranty claims, and lost stakeholder confidence. They are sometimes called the cost of poor quality, although that broader phrase can include more than just failure events.

Project teams rarely track failure costs with the same discipline they apply to direct labor or material budgets. That is a gap because failure costs often accumulate quietly through rework, schedule compression, and post-delivery service obligations. Understanding failure costs matters less for accounting precision than for making visible the true cost of not doing quality work. The concept sits at the intersection of project quality management, risk management, and procurement management, and it influences decisions from early planning through benefits realization.

Failure Costs: Summary of Key Topics

Failure Costs Summary
Definition In project management, failure costs capture the financial losses and corrective expenditures that arise when deliverables fall short of specifications, acceptance criteria, or customer expectations.
Cost of Poor Quality This broader measure combines failure costs with the appraisal and prevention expenditures required because initial quality levels were unacceptable.
Cost Categories Effective analysis separates direct from indirect costs, tangible from intangible impacts, and project budget items from downstream costs that emerge during operations or support.
Common Examples Frequent examples include scrap, rework, retesting, defect correction, additional inspections triggered by known nonconformance, and idle capacity caused by queued rework.
Software Projects In software initiatives, internal failure costs typically include developer effort spent on defect remediation, repeated test execution, and schedule disruption caused by broken integration builds.
Manufacturing Projects In manufacturing, internal failure costs often involve material disposal, reprocessing, and production capacity absorbed by defective units that could otherwise produce conforming output.
Hidden Impacts Beyond direct charges, failure costs consume supervisory time, reduce team productivity, force schedule compression, and increase coordination overhead when deliverables remain unstable.
BVOP Perspective Business Value Oriented Project Management (BVOP) adds rigor by connecting defect analysis to predefined root cause categories and quantifying loss units to support product risk decisions.

What Is Failure Costs in Project Management?

In formal quality management, failure costs in project management are defined as the expenses and losses caused by outputs that do not conform to specifications, acceptance criteria, or customer expectations. They belong to the cost of quality framework, which separates spending into conformance costs and nonconformance costs. Prevention and appraisal activities fall under conformance costs because they aim to ensure quality before or during production. Failure costs fall under nonconformance costs because they emerge only after a defect, error, or omission has occurred.

The distinction between conformance and nonconformance is not just semantic. It changes how managers interpret quality spending. Spending money on prevention or appraisal is an investment in reducing the probability that failure costs will arise. Failure costs, by contrast, create no value. They consume resources that could have been used for new features, additional testing, or earlier delivery. A common practitioner observation is that organizations often have detailed budgets for prevention activities but very little visibility into the rework loops triggered by poor quality.

Failure costs can be thought of in two broad time periods. Internal failure costs occur before the deliverable reaches the customer or end user. External failure costs occur after delivery. Consider a construction project where the wrong concrete mix is discovered before the foundation is poured. The cost of removing and replacing the mix is an internal failure cost. If the defect is not discovered until the building is in use, the cost includes structural repairs, legal claims, and damage to the contractor's reputation. Those are external failure costs. The same logic applies to software, engineering, pharmaceuticals, and service projects.

Some project managers confuse failure costs with generic project failure, such as a missed deadline or an overrun budget. That is too broad an interpretation. Failure costs are specifically tied to quality nonconformance, not to any kind of project variance. A project can run over budget because of poor estimating without generating failure costs. A project can also have significant failure costs while still meeting its formal deadline because rework was absorbed by overtime or by reducing optional scope. The concept is about the cost of defects, not the cost of ordinary project deviation.

Failure Costs Definition and Core Meaning

The most precise failure costs definition distinguishes between the cost of correcting a defect and the cost of the defect escaping into the hands of users. In a project context, a defect can be a physical flaw, a missing requirement, a misconfigured component, an incomplete process handoff, or a deliverable that does not meet the agreed acceptance criteria. Failure costs include the labor, materials, equipment, schedule delay, and management attention required to deal with the nonconformance. They also include lost future value when the defect damages trust or prevents the project from realizing its intended benefits.

Cost of Quality vs Cost of Poor Quality

Cost of quality and cost of poor quality are related but not identical. Cost of quality is the total amount spent on all quality-related activities, including prevention, appraisal, and failure. Cost of poor quality is a narrower term that generally refers to failure costs plus the appraisal and prevention costs incurred because of unacceptable quality levels. In many organizations, cost of poor quality is used almost interchangeably with failure costs, but the cleaner practice is to reserve cost of poor quality for the full economic impact of not getting it right the first time. Failure costs are the most visible and usually the largest component of that impact.

Key Takeaways on Failure Costs

Failure cost definition
Failure costs capture the full financial impact of project outputs that miss specifications, acceptance criteria, or customer expectations, including direct rework and downstream losses.
Nonconformance cost category
In the cost of quality model, failure costs are treated as nonconformance costs, while prevention and appraisal spending is classified as conformance costs because it aims to avoid defects rather than absorb their consequences.
Prevention reduces failure risk
Investing in prevention and appraisal reduces the likelihood that defects, errors, or omissions will escalate into costly failures, making it a strategic safeguard rather than overhead.
Hidden drain on resources
Failure costs silently divert budget and capacity away from new features, additional testing, or faster delivery, yet many organizations track prevention spending without measuring the rework loops that consume those resources.
Internal versus late discovery
Internal failure costs occur before a deliverable reaches the customer, while post-delivery failures, such as an incorrect concrete mix in a completed building, can trigger structural repairs, legal claims, and lasting reputational harm.

Key Components of Failure Costs

The key components of failure costs are usually grouped into internal failure costs and external failure costs, but this two-part model hides important layers. Practitioners also distinguish between direct and indirect costs, tangible and intangible costs, and costs that are visible in the project budget versus costs that appear later in operations, maintenance, or customer support. Each layer demands a different measurement approach and a different management response.

Internal Failure Costs

Internal failure costs are generated before the deliverable is handed over to the customer or end user. Common examples include scrap, rework, retesting, defect correction, additional inspections triggered by a known nonconformance, and the cost of idle resources waiting for rework to be completed. In a software project, internal failure costs include the time developers spend fixing defects found during testing, the cost of rerunning test suites, and the schedule delay caused by a build that fails integration. In a manufacturing project, internal failure costs include material disposal, reprocessing, and the lost production capacity consumed by defective units.

These costs are often underestimated because rework is hidden inside normal task execution. A developer who fixes a defect during a sprint may simply log the time as development work, not as rework. A construction crew that corrects misaligned formwork may count the hours as part of the original activity. That absorption makes internal failure costs difficult to see in standard project accounting systems. Yet they are usually the most controllable category because the defect has not yet reached the customer, so the project team still has full authority to correct it without external consequences.

External Failure Costs

External failure costs arise after the deliverable has been delivered, accepted, or placed into use. They include warranty claims, customer complaints, product recalls, field service visits, legal liability, regulatory penalties, and the replacement or repair of defective deliverables. The cost of reputation damage sits in this category too, although it is harder to quantify. A project that hands over a faulty system may face escalating support costs for months or years after closure, often borne by a different operational budget and invisible to the original project team.

External failure costs are generally considered more damaging than internal failure costs for three reasons. First, they affect the customer directly, which can erode trust and future business. Second, they often include legal and compliance exposure that goes far beyond the cost of correcting the defect. Third, they are harder to trace back to the project that caused them. A product defect that triggers a recall may have originated in a design decision made years earlier, but the accounting system may never connect the recall cost to that decision.

Direct, Indirect, and Intangible Failure Costs

Direct failure costs are straightforward to measure. Rework hours, scrap materials, and warranty payouts fall into this group. Indirect failure costs are real but less visible. They include the supervisory time spent coordinating defect resolution, the lost productivity of teams waiting for a fix, the schedule compression required to recover lost time, and the increased coordination overhead caused by unstable deliverables. Intangible failure costs include damaged reputation, reduced employee morale, customer dissatisfaction, and the loss of future opportunities that never show up as a line item in any ledger.

A layered explanation may help here. If a logistics project delivers a warehouse management system with a recurring inventory sync error, the direct cost is the developer time required to fix the defect. The indirect cost includes the extra warehouse labor spent manually reconciling inventory while the fix is being developed. The intangible cost includes the client's reduced willingness to award a follow-up contract. Many failure cost models capture only the first category and miss most of the actual economic damage.

Failure Costs PMBOK and PRINCE2

Within the PMBOK framework, Failure Costs PMBOK are addressed primarily through the Project Quality Management knowledge area. Plan Quality Management includes the cost of quality as a tool and technique, and the cost of quality model explicitly recognizes prevention costs, appraisal costs, and failure costs. Failure costs are considered the cost of nonconformance, while prevention and appraisal are the cost of conformance. Manage Quality and Control Quality processes then generate the data needed to monitor defects and rework, though many project teams fail to convert that data into a complete failure cost picture.

The PMBOK approach treats failure costs as a planning input and a monitoring concern. During planning, the project manager estimates an appropriate balance between conformance and nonconformance spending. During execution, quality metrics such as defect density, rework rate, and first-pass yield provide early signals of failure cost accumulation. The framework does not prescribe a specific accounting method for failure costs, which leaves room for organizations to define their own severity levels, cost categories, and reporting thresholds. That flexibility is useful, but it also means that failure costs are often inconsistently applied.

PRINCE2 and Quality Costs

PRINCE2 does not use the phrase failure costs as a defined term in the same way as PMBOK. The PRINCE2 quality theme focuses on defining quality expectations, acceptance criteria, and quality controls, and it emphasizes that the cost of quality should be balanced against the project's risk tolerance. PRINCE2 requires that quality planning identify how products will be checked and what happens if they do not meet their quality criteria. The financial consequences of nonconformance, which PMBOK would call failure costs, are embedded in PRINCE2's emphasis on avoiding rework and in its requirement to document off-specifications and corrective actions.

In PRINCE2, an off-specification is a product that does not meet its specification, and the project manager must decide whether to accept it, reject it, or request a concession. Each of those decisions has failure cost implications. Accepting a nonconforming product may transfer a latent defect into operational use, creating external failure costs later. Rejecting it creates internal failure costs through rework or replacement. The PRINCE2 emphasis on product descriptions and quality tolerances is designed to reduce the likelihood of off-specifications, but the framework leaves the quantification of failure cost impact to the organization's financial management practices.

BVOP Perspective on Failure Costs

Business Value-Oriented Project Management adds a distinct lens by linking defect analysis to predefined root-cause categories and by tracking quantified loss size units for product risks. In BVOPM, persistent quality failure is not treated as an isolated defect event but as a signal that the project may be damaging business value through rework, rejected acceptable work, and overwork. Failure cost discussion therefore connects directly to waste reduction and to the viability of continuing the project when product risk indicators deteriorate.

Key Insights on Failure Costs

PMBOK quality management role
Within the Project Quality Management knowledge area, PMBOK classifies failure costs as the cost of nonconformance, distinguishing them clearly from conformance spending to support balanced quality investment decisions.
Planning and monitoring focus
PMBOK positions failure costs as both a planning input and an ongoing monitoring concern, relying on quality metrics to reveal cost accumulation while deferring detailed accounting methods to the performing organization.
PRINCE2 rework avoidance approach
PRINCE2 embeds failure costs within its rework prevention focus, capturing them through formal records of off-specifications and corrective actions to make quality deviations visible and actionable.
BVOP loss size tracking
BVOP offers a distinct perspective by connecting defect analysis to predefined root-cause categories and quantifying loss size units, which enables more precise tracking of product risk exposure.

Failure Costs in Agile and Hybrid Environments

Agile methods approach failure costs through a different route. Traditional methods often rely on front-loaded planning and staged quality gates to prevent defects from spreading. Agile assumes that some defects will always occur, so the goal is to detect them as close as possible to the point of origin. In this view, failure costs in Agile are minimized not primarily by more planning but by shrinking the time and distance between defect injection and defect detection. Pair programming, test-driven development, continuous integration, and frequent demonstrations are all mechanisms for reducing failure cost escalation.

The cost of defects in Agile is closely related to technical debt. When a team chooses speed over structural quality, it defers an internal failure cost into the future. That deferred cost often compounds because the codebase becomes harder to modify, tests become less reliable, and new features trigger more regression defects. Agile frameworks do not always use the term failure costs explicitly, but the concept appears in discussions of escaped defects, rework in sprint, and the cost of delay caused by unstable increments.

Agile Built-In Quality and Failure Cost Drivers

Built-in quality practices shift spending toward prevention and appraisal while lowering the probability of failure costs. A team that writes automated tests before code is spending appraisal and prevention resources. A team that discovers a defect during a daily build is generating an internal failure cost, but a small one. A defect discovered by the customer after release generates an external failure cost and often triggers an emergency patch, a support ticket, and a loss of confidence. Agile practitioners often observe that the real cost multiplier is not the defect itself but the time elapsed before anyone notices it.

Hybrid and Predictive Differences

In predictive environments, failure costs tend to concentrate around phase gates and final acceptance testing. Because feedback arrives late, defects can remain hidden for long stretches, making correction expensive and disruptive. In hybrid environments, some work products follow predictive controls while others follow iterative feedback loops. The challenge is that failure costs may be measured inconsistently across those two modes. A requirements defect found in a formal review is easy to track, while a defect found informally during a sprint conversation may never be logged as a failure cost at all.

Purpose and Importance of Tracking Failure Costs

The primary purpose of tracking failure costs is to make the financial consequences of poor quality visible enough to justify prevention spending. When the importance of failure costs is ignored, quality initiatives often look like overhead because their benefits are indirect. A project manager who wants funding for additional testing or a dedicated quality reviewer needs a credible argument that the investment will reduce future failure costs. Without failure cost data, that argument is based on intuition rather than evidence.

Failure cost tracking also changes behavior. Teams that regularly see the dollar value of rework become more careful about handoffs, acceptance criteria, and technical readiness. It is not about blame. It is about creating a shared understanding that defects are not free. The act of estimating failure costs during planning forces the project owner to think through what could go wrong after delivery and to assign resources to preventive measures. That conversation often reveals risks that never appear on a standard risk register.

Why Failure Costs Are Usually Underestimated

Most project teams underestimate failure costs because they only count the obvious direct costs. A defect that causes a two-hour rework task looks small, but the same defect may also trigger a test rerun, a code review, a documentation update, a status meeting, and a delay in another dependent task. Those indirect effects are rarely attributed to the defect. In addition, external failure costs often land in operational budgets after the project has closed, so the project team never sees them. The result is a systematic bias toward underestimating the cost of poor quality and underinvesting in prevention.

Key Insights on Failure Cost Tracking

Quantifying quality's financial impact
Tracking the dollar value of poor quality converts a general preference for prevention into a concrete, evidence-based business case, enabling leaders to justify targeted investments in testing, quality reviewers, and other safeguards with measurable return on investment.
Behavioral change through cost visibility
When teams see the cumulative dollar cost of rework, they begin to treat handoffs, acceptance criteria, and technical readiness as financially meaningful controls, which reduces preventable defects before they escalate.
Hidden cascade of defect costs
Even a two-hour rework task can trigger a hidden cascade of test reruns, code reviews, documentation updates, status meetings, and downstream delays, while external failure costs frequently surface only in operational budgets long after the project has closed.

Common Misconceptions About Failure Costs

One of the most persistent misconceptions about failure costs is that they are an inevitable part of doing business and therefore not worth measuring. This belief confuses the existence of defects with the need to ignore their cost. Defects may be inevitable in complex work, but their financial impact is not fixed. Early detection and better prevention can reduce the severity of failure costs even when they cannot eliminate every defect.

Another misconception is that failure costs are only relevant to manufacturing or physical products. In fact, service projects, software implementations, business process redesigns, and organizational change initiatives all generate failure costs. A poorly designed training program that fails to prepare users creates a failure cost through reduced adoption and increased support calls. A poorly specified process handoff creates rework for downstream teams. The concept applies anywhere that a deliverable can fail to meet its intended purpose.

Some organizations treat failure costs as a quality department metric rather than a project management concern. That separation undermines the value of the concept. Project managers control the schedule, scope, and resource decisions that influence whether defects are caught early or allowed to escape. If failure costs are reported only after the fact by a quality function, the project team loses the opportunity to act on early warning signs. Failure costs are most useful when they are integrated into the project's regular performance monitoring.

It is also a mistake to use failure costs as a punitive measure against individual team members. When failure cost data is weaponized, people hide defects, underreport rework, and avoid discussing near misses. The result is worse data and worse outcomes. Effective failure cost management depends on psychological safety and a learning culture. The goal is to reveal systemic causes, not to assign personal blame.

Failure Costs vs Prevention and Appraisal Costs

The relationship between failure costs vs prevention and appraisal costs is one of the most important ideas in quality economics. Prevention costs include training, process design, quality planning, and improvement initiatives. Appraisal costs include inspections, testing, reviews, and audits. Failure costs include everything that happens when prevention and appraisal fail to catch a defect before it damages value. In general, a dollar spent on prevention tends to reduce multiple dollars of failure cost, but the exact ratio depends on the industry, the project phase, and the nature of the deliverable.

The comparison is not simply about spending more on prevention. Some prevention activities have limited returns, and excessive appraisal can create bottlenecks without improving quality. The practical challenge is to find the point where additional prevention or appraisal spending stops producing meaningful reductions in failure costs. That optimum is different for every project. A high-risk medical device project may justify very high prevention and appraisal spending. A low-risk internal reporting tool may not. The failure cost lens helps tailor that decision.

The 1-10-100 Rule and Its Limits

Many practitioners cite the 1-10-100 rule as a heuristic for understanding failure cost escalation. The idea is that a defect caught during design costs one unit to fix, a defect caught during development costs ten units, and a defect caught after release costs one hundred units. The rule is a useful communication device, but it is not a universal empirical constant. It originated as a rule of thumb in manufacturing and engineering environments, and its actual multipliers vary widely. Teams should use it to illustrate the principle of early detection, not as a precise forecasting tool.

Why Prevention Is Not Just Another Cost

Prevention spending often gets cut first when budgets tighten because its payoff is delayed. That is a natural but risky reaction. The failure costs avoided by prevention are not visible in the budget, so the cut looks like a savings. In reality, delaying prevention shifts spending into failure costs later, often at a higher total amount and with less controllability. Organizations that track failure costs over multiple projects begin to see this pattern clearly. Until then, prevention remains vulnerable to short-term cost pressure.

Balancing Quality Cost Investments

Prevention costs defined
Prevention costs encompass investments in training, process design, quality planning, and proactive improvement initiatives aimed at eliminating defects before they occur.
Appraisal costs defined
Appraisal costs cover inspections, testing, reviews, and audits that verify products conform to quality standards before they reach the customer.
Failure costs explained
Failure costs represent the losses incurred when prevention and appraisal activities fail to catch a defect before it erodes value, and these costs escalate sharply as defects move further downstream.
The 1-10-100 escalation rule
This heuristic states that a defect corrected during design costs one unit, during development costs ten units, and after release costs one hundred units, illustrating how defect costs multiply at each stage.
Finding the optimal balance
The core challenge is to identify the investment point at which additional prevention or appraisal spending stops producing meaningful reductions in failure costs, because these investments yield diminishing returns and excessive appraisal activity can create operational bottlenecks.

Failure Costs Across the Project Lifecycle

The practical application of failure costs changes depending on where the project is in its lifecycle. During initiation and planning, failure costs are estimated and used to justify quality investment. During execution, they are monitored through defect metrics and rework indicators. During closure and handover, they are considered as latent risks that may become external failure costs. Each phase requires a different level of detail and a different stakeholder conversation.

Planning and Estimation

In planning, the project manager can include a cost of quality estimate in the business case or quality management plan. This estimate should identify the main sources of potential internal and external failure costs and assign rough dollar impacts. Even a rough estimate is valuable because it makes the cost of poor quality a planning assumption rather than an afterthought. It also helps decision makers compare options. For example, a cheaper vendor may appear to save money but carry a higher expected failure cost due to lower quality.

Execution and Monitoring

During execution, failure costs are often tracked through rework rates, defect counts, test escape rates, and the time spent on corrective actions. These metrics provide an early warning when quality is deteriorating. A sudden increase in rework hours may indicate a specification problem, a skills gap, or an unrealistic schedule. Project managers can then adjust resources, clarify acceptance criteria, or escalate risks before the failure costs compound. Earned value analysis may also show the impact indirectly, because rework consumes budget without completing planned work.

Handover and Closure

At closure, the project team should identify any quality risks that may become external failure costs after handover. Latent defects, incomplete documentation, and untested operational scenarios all carry this potential. Some organizations create a warranty reserve or a transition support budget to cover expected failure costs in the weeks and months after delivery. Transferring these risks to operations without a corresponding budget or monitoring mechanism sets up a situation where the project is declared successful while external failure costs quietly accumulate elsewhere.

Evolution and Current Thinking on Failure Costs

The concept of failure costs originated in manufacturing quality management and became widely known through the work of quality thinkers such as Armand Feigenbaum and Joseph Juran. Early applications focused on scrap, rework, and warranty expenses in production environments. Over time, the concept expanded into service industries, software engineering, healthcare, and project management. The current thinking on failure costs emphasizes systems, feedback loops, and the economic consequences of delayed defect detection more than raw accounting categories.

Total quality management and Six Sigma brought failure cost analysis into broader organizational use. Six Sigma projects often use cost of poor quality as a baseline to justify process improvement efforts. Lean practitioners connect failure costs to waste, especially the waste of rework, overprocessing, and correction. Agile and DevOps shifted the conversation toward continuous delivery and fast feedback as mechanisms for reducing the cycle time between defect creation and defect discovery. In this modern view, the most powerful failure cost reduction strategy is not better inspection but shorter feedback loops.

Current debates around failure costs focus on measurement accuracy, behavioral consequences, and the appropriate balance between prevention and innovation. Some experts argue that aggressive failure cost tracking can create a blame culture and discourage experimentation in complex product development. Others contend that without quantified failure costs, organizations consistently underinvest in quality. The practical middle ground is to track failure costs at a level of detail that supports decision making without turning every defect into a financial inquisition.

Key Insights on Failure Cost Thinking

Manufacturing quality origins
Failure cost analysis originated in manufacturing quality management, where pioneers such as Armand Feigenbaum and Joseph Juran established an early focus on quantifying scrap, rework, and warranty expenses.
Shift toward feedback loops
Modern approaches extend beyond static accounting categories to examine how system structure, feedback loops, and delayed defect detection produce economic consequences in service, software, healthcare, and project management environments.
Broader organizational adoption
Total quality management and Six Sigma broadened the application of failure cost analysis by using the cost of poor quality as a baseline for improvement initiatives, while Agile and DevOps accelerated defect discovery through continuous delivery and shorter release cycles.
Balanced tracking approach
The most effective failure cost reduction strategy emphasizes shorter feedback loops over more intensive inspection, but cost tracking should stay decision-useful without creating a blame culture that discourages experimentation.

Limitations of Failure Cost Analysis

Like any management concept, failure cost analysis has limitations. The most obvious is measurement difficulty. Indirect and intangible failure costs are real but resist precise quantification. Reputation damage, customer dissatisfaction, and employee turnover can be described qualitatively but are hard to convert into defensible dollar figures. Even direct failure costs can be difficult to attribute when a defect has multiple causes or spans multiple teams. The analysis often relies on estimates and assumptions that can be challenged or manipulated.

Another limitation is context dependence. A failure cost that is trivial in one project may be severe in another. A software defect in a customer-facing billing system carries different consequences than the same defect in an internal reporting utility. The cost of failure also depends on the contractual relationship, the regulatory environment, and the customer's tolerance for defects. Applying generic benchmarks or multiplying factors without understanding the project context leads to misleading conclusions.

Failure cost analysis should not be used as a standalone performance measure. It works best when combined with quality metrics, risk indicators, customer satisfaction data, and schedule performance information. A project with low measured failure costs may simply have a poor defect detection system, not a defect-free deliverable. The absence of recorded failure costs can hide a problem as easily as it can reflect good performance. That is why effective quality management treats failure cost data as a starting point for investigation, not as proof of quality.

The ultimate value of understanding failure costs lies in its ability to reframe quality as an economic decision rather than a moral imperative. When managers see quality spending as a hedge against rework, warranty exposure, and lost trust, they make better trade-offs among scope, schedule, cost, and quality. That reframing requires discipline and honesty, but it is one of the most practical contributions that quality economics makes to project, program, and portfolio management.

Understanding the Concept More Deeply

Failure Costs vs. Cost of Poor Quality

Failure costs are often used interchangeably with cost of poor quality, but the terms are not identical. Failure costs are the specific subset of quality costs that arise after a defect, error, or nonconformance has occurred. They include internal failure costs such as scrap, rework, and re-testing before delivery, and external failure costs such as warranty claims, returns, and legal liability after the customer receives the output, making them important in actual cost comparisons.

Cost of poor quality is broader. It can include failure costs but may also cover the wasted effort caused by poor process capability, excessive inspection, unnecessary handoffs, or the opportunity cost of displaced value-adding work. In other words, all failure costs are costs of poor quality, but not all costs of poor quality are failure costs.

A distinguishing example appears in a software project where a developer spends several days fixing a module that failed integration testing. The fix and retesting are internal failure costs because a defect occurred. If the team also conducts extra manual reviews because it does not trust the automated test suite, that extra review time may be a cost of poor quality, but it is not a failure cost unless a defect is actually found.

The distinction helps project managers decide where to intervene. Failure costs point to defect events, while the broader cost of poor quality points to systemic quality weaknesses that may or may not have produced a visible failure yet.

Origins in Feigenbaum and Juran's Quality Cost Models

The separation of failure costs from other quality costs originated in the mid-twentieth-century quality management movement. Armand Feigenbaum is widely credited with formalizing the prevention, appraisal, internal failure, and external failure categories in his 1951 book Total Quality Control. Joseph Juran reinforced the financial view of quality through the cost of quality concept, often describing hidden failure costs as a mine of potential savings.

The original problem was not simply poor products. Manufacturers needed a way to justify quality improvement to executives who saw inspection and testing as overhead. By separating conformance spending from nonconformance spending, Feigenbaum and Juran made the economic trade-off visible: preventing defects costs less than finding and fixing them after they occur.

In that early context, failure costs referred mainly to factory scrap, rework, warranty claims, and customer returns. Over time the meaning expanded beyond manufacturing. Project management adopted the categories to include schedule delays, missed acceptance criteria, re-planning, lost stakeholder confidence, and post-delivery service obligations.

Service industries and software projects now use failure costs to describe help desk escalations, patch releases, rework from ambiguous requirements, and even reputational damage. The shift reflects a broader understanding that failure costs are not only production line losses. They are the accumulated economic consequences of any output that does not meet agreed requirements, regardless of industry.

Boundary Conditions in Exploratory and Intangible Work

The failure cost model works best when requirements are stable, acceptance criteria are clear, and defects can be observed. It breaks down in several boundary conditions. In exploratory research, product discovery, or early innovation projects, the line between a failed attempt and a learning iteration is blurred.

A prototype that does not work may generate useful information about what not to build, so labeling its cost as a failure cost can mislead decision makers. Similarly, when quality expectations are ambiguous or shifting, classifying an output as nonconforming is often contested. A late requirement change can turn a previously acceptable deliverable into a rework cost, but the cause may be market change rather than poor quality.

The model also struggles with intangible and delayed consequences. Reputational damage, reduced team morale, customer distrust, and lost future opportunities are real, but they resist precise measurement. If an organization only records visible rework and warranty expenses, its failure cost totals understate the true economic impact.

In addition, the model assumes failure events can be attributed to specific activities or decisions. In complex systems with many interacting teams, a defect may have multiple causes and no clear owner, making failure cost allocation unreliable. Project managers should treat failure costs as a useful lens, not an accounting system that works in all contexts.

Misinterpretation: Failure Costs Are Only Direct Rework

Misinterpretation: Many people believe failure costs are limited to direct, visible expenses such as scrap, rework hours, and warranty repairs. Fact: As part of quality costs, failure costs include a much wider range of direct and indirect consequences. Internal failure costs can involve re-planning, schedule compression, idle team members waiting for a corrected component, additional testing, and the management time spent investigating root causes.

External failure costs can include customer support escalations, field service visits, product recalls, legal settlements, and lost repeat business. Some of the largest failure costs are non-monetary or delayed, such as damaged trust, reduced team morale, and a weakened brand. Another common error is assuming that failure costs end when a project closes.

In many projects, the most expensive failures appear after handover, when users encounter defects that were not detected earlier. The fact is that external failure costs are often far greater than internal failure costs because they occur in the customer's environment where corrections are slower and reputational effects are immediate. Project teams that only track rework completed before delivery may therefore report a healthy quality picture while the true cost of poor quality is only beginning to accumulate after release.

Recognizing this distinction helps teams justify investments in early prevention and appraisal, even when the initial budget appears higher.

Additional resources:

  • The Drexler Sibbet Team Performance Model is a seven-stage framework for understanding how teams form, build trust, define purpose, commit to work, deliver results, and ultimately renew or disband. In project...

  • Assumption and Constraint Analysis is the systematic process of identifying, documenting, and validating the presumptions and limitations that underpin a project plan. It ensures uncertainty is explicitly acknowledged...

  • Feasibility is a structured assessment in project management used to determine whether a proposed project can be delivered successfully and whether its expected outcome justifies the required investment. Before formal...

  • The ADKAR Model is a goal-oriented change management framework that defines the five sequential conditions an individual must meet to successfully adopt and sustain a change. Unlike organizational change models that...

  • A change log is a formal, sequential record of all change requests, their evaluation outcomes, and the actions taken in response to proposed alterations to a project’s approved baselines. It functions as a single source...

  • Delivery models in project management are structured configurations of lifecycle phases, development approaches, governance controls, team structures, and delivery cadence used to convert project inputs into completed...

  • Analogous estimating is a top-down estimation technique that uses historical data and expert judgment from similar past projects to forecast the duration or cost of a current activity or project. It provides a quick,...

  • Compliance in product and deliverable is the extent to which a project’s products, services, or unique results meet their functional and nonfunctional requirements, acceptance criteria, quality standards, and regulatory...

  • Deliverables are unique and verifiable products, results, or capabilities required to complete a process, phase, or project. They give objective shape to effort and anchor how teams plan, execute, track, and close work....

  • Decision making is the process by which a project manager, team, sponsor, or governance body selects a course of action from two or more alternatives to move the project toward its objectives. In project management, it...

  • An Agile Charter is a concise, jointly developed document that defines a project’s purpose, boundaries, and collaborative principles among Agile team members and stakeholders. It serves as a lightweight compass rather...

  • Actual cost compared to planned cost is the fundamental financial comparison in project management, directly contrasting real expenditures against the budgeted baseline. It serves as the basis for calculating cost...

  • Brainstorming is a facilitated group technique used in project management to generate a large volume of ideas, uncover risks, and define requirements through free-flowing, non-judgmental conversation. It temporarily...

  • A checklist is a structured list of items, actions, criteria, or deliverables used in project management to verify that specific project activities have been completed, reviewed, or approved. It serves as a cognitive...

  • Ambiguity types in project management are the distinct categories of unclear, equivocal, or multi-interpretable conditions that obscure a project’s scope, requirements, technology, environment, or stakeholder...

  • Celebrating success is the deliberate recognition of achievements, milestones, and completed deliverables within project management. It acts as a strategic lever to reinforce team morale, demonstrate value to...

  • Change requests are formal proposals to modify an approved project plan, baseline, deliverable, or project document. They initiate a structured process of review, impact assessment, and decision making; the request...

  • A Backlog Refinement Meeting, also known as backlog grooming, is a recurring Agile ceremony where the product owner, development team, and stakeholders review, clarify, estimate, and prioritize upcoming backlog items....

  • Communication planning is the structured process of determining what information project stakeholders need, when and how they should receive it, and who is responsible for delivering it. It produces a communications...

  • Customer Requests are formal or informal expressions of a customer's need, preference, expectation, or desired change that may require action from the project team. They enter the project environment through...

  • Delivery measurements are the quantitative and qualitative indicators used in project management to assess whether project outputs, work products, and intended benefits are completed and delivered according to agreed...

  • A Cycle Time Chart is a graphical representation that plots the elapsed time from the start of active work on an item to its completion. In Agile and Lean project management, it displays individual cycle time values as...

  • Failure analysis is a structured diagnostic process used in project management to investigate failed project outcomes, phase breakdowns, or recurring delivery defects. It identifies root causes by separating cause from...

  • Change management in project management is a formal governance process for evaluating, authorizing, and documenting modifications to a project’s scope, schedule, budget, or deliverables. It ensures that every proposed...

  • The adaptive development approach is a product delivery methodology where requirements are not fully known at the start, but emerge through iterative development cycles and ongoing stakeholder input. It manages high...

  • An Enterprise-Level PMO is a permanent organizational function that establishes centralized governance, standards, and strategic alignment for project, program, and portfolio management across the entire enterprise. It...

  • Benchmarking is a structured process used in project management to compare an organization’s practices, processes, and performance metrics against those of industry leaders or standards. It serves as a diagnostic tool...

  • Bidder conferences are formal meetings held by a buyer after issuing procurement documents but before bids are submitted, giving all prospective sellers equal access to clarifications and requirements. In project...

  • An assumption log is a project document used to systematically catalog all assumptions and constraints that shape a project’s planning and execution. It acts as a living repository where the project team records...

  • A Change Control Plan is a formal component of the project management plan that establishes the procedures for requesting, evaluating, approving, and implementing modifications to project baselines, documentation, and...

×
Become a Certified Project Manager
$280   $130
FREE Online Mock Exam Become a Certified Manager