Quality Management: The Mandar Approach to Defects

A defect rarely costs what the defect report says it costs.

A rejected component may appear as a ₹5,000 quality issue. A failed transaction may appear as a 20-minute rework item. A customer complaint may be logged as a service incident. A software vulnerability may be recorded as a remediation task.

But the visible defect is only the point at which the organization notices the problem.

Behind it may sit duplicated work, management attention, delayed decisions, customer frustration, disrupted schedules, excess inspection, employee fatigue, supplier intervention, lost trust, missed opportunities and weakened resilience.

This creates an important management paradox: the organization may be measuring the cost of correcting the defect while failing to measure the cost of everything the defect disrupts.

That is why quality cannot be understood only as conformance, inspection or defect reduction.

It is a question of Integrated Business Performance.

Table of Contents

The Problem Behind the Problem

Most organizations already have quality processes.

They have procedures, audits, inspections, corrective actions, dashboards, customer feedback mechanisms and escalation routes.

Yet defects continue to recur.

The conventional response is often functional:

Quality investigates the defect.
Operations corrects the process.
Engineering modifies the specification.
IT fixes the application.
Procurement addresses the supplier.
Customer service manages the complaint.
Risk records the exposure.

Each action may be reasonable.

The problem is that the organization can become very effective at correcting pieces of a problem without understanding the system that produced it.

A recurring defect is therefore not necessarily evidence of a weak quality department. It may be evidence of weak Organizational Connections.

The specification may not connect clearly to the customer requirement.

The decision may not connect to reliable data.

The process may not connect to the capability of the people executing it.

The control may detect failure without preventing it.

Technology may automate a process that was never properly designed.

Management information may describe yesterday’s failure without improving tomorrow’s decision.

This is the distinction between a symptom and a Systemic Problem.

The symptom is the defect.

The systemic problem is the set of disconnected decisions, processes, controls, capabilities and information that allowed the defect to occur and potentially recur.

Here Is Where The Mandar Approach Changes the Conversation

The Mandar Approach begins with a different proposition:

Every organizational problem is a connection problem before it becomes a performance problem.

This does not mean that every defect has a dramatic systemic cause. Some defects are genuinely isolated.

The executive task is to determine when they are not.

The Mandar Approach therefore does not treat quality as another functional discipline. It examines quality through Organizational Architecture: how purpose, decisions, processes, controls, capabilities and intelligence connect to produce Performance and Resilience.

Its architecture is:

Purpose
↓
Decision
↓
Process
↓
Control
↓
Capability
↓
Intelligence
↓
Performance & Resilience

The arrows matter as much as the layers.

The organization creates value not because these elements exist independently, but because they work as a connected system.

Applying The Mandar Approach to Quality

1. Purpose: What Is the Organization Actually Trying to Protect or Create?

Quality begins before the process.

Consider a manufacturer experiencing repeated customer returns.

The immediate question may be: Why is the product failing?

The Mandar Approach asks an earlier question:

What outcome is the organization actually trying to assure?

Is the objective merely to manufacture within specification?

Or is it to deliver reliable performance for the customer’s intended use?

Those are not necessarily the same thing.

Purpose determines what quality means.

If the purpose is poorly translated into operational requirements, downstream teams can execute their responsibilities correctly while the organization still produces the wrong outcome.

That is the first connection: Purpose must connect to the decisions that define quality.

2. Decision: Where Is Quality Being Designed Into the Organization?

Every quality outcome contains decisions.

Which specification was approved?
Which supplier was selected?
Which tolerance was accepted?
Which risk was considered acceptable?
Which process was automated?
Which control was removed to improve speed?
Which customer requirement was treated as critical?

A defect may be a delayed consequence of an earlier decision.

This is why analysing only the point of failure can be misleading.

The right question is not simply, “Where did the defect occur?”

It is, “Which decision created the conditions in which the defect became possible?”

This moves quality from inspection toward Decision-making.

3. Process: How Does the Decision Become an Outcome?

A decision becomes operational through a process.

But processes rarely exist inside one department.

A customer order may pass through sales, configuration, pricing, planning, procurement, production, logistics, invoicing and service.

A defect introduced at one interface can become visible several stages later.

That makes handoffs particularly important.

A process can be efficient within each function while being ineffective end-to-end.

For example, a production team may achieve excellent cycle-time performance while repeatedly receiving incomplete specifications from engineering. Engineering may meet its own deadlines while changing requirements after production planning has begun.

The resulting defect is not simply a production problem.

It is a connection problem between decisions and execution.

The Mandar Approach therefore examines the flow of the outcome, not merely the performance of the department.

4. Control: Does the Organization Prevent, Detect or Merely Document Failure?

Controls are often evaluated by asking whether they exist.

A more useful question is:

What decision does this control enable?

A control that detects a defect after production may be useful.

A control that prevents the defect from entering production may be more valuable.

A control that generates information but does not trigger an accountable decision may provide documentation without meaningful performance improvement.

This distinction matters:

Compliance demonstrates that a control exists. Performance improvement depends on whether the control changes behaviour and outcomes.

Controls should therefore connect to decisions.

If a control produces ten alerts every day and nobody changes the process, the organization does not have an intelligence problem alone. It may have a governance and decision-design problem.

5. Capability: Can the Organization Reliably Execute the Intended Process?

A process can be perfectly documented and still produce inconsistent outcomes.

Why?

Because capability sits between design and execution.

Capability includes skills, experience, capacity, leadership, technology proficiency, problem-solving ability and the organization’s ability to learn.

Suppose a new digital workflow reduces manual errors in one business unit but increases exceptions because employees do not understand the new decision rules.

The technology has changed.

The process has changed.

But the capability has not.

That gap becomes a quality problem.

This is why Capability cannot be treated as a training department’s responsibility.

Capability is an operating-system issue.

6. Intelligence: Is the Organization Learning From What It Already Knows?

Data is not automatically intelligence.

An organization may have thousands of defect records and still fail to understand recurring failure patterns.

The critical transition is:

Information → interpretation → decision → action → learning.

Imagine that three customer complaints are logged separately:

One as a packaging issue.
One as a logistics issue.
One as a product-damage issue.

A functional reporting structure may create three different investigations.

Organizational Intelligence asks whether these are actually one pattern.

Perhaps a packaging specification changed six months earlier. Perhaps a supplier changed material. Perhaps transport conditions have changed.

The insight emerges only when the organization connects data across boundaries.

That is the difference between information and intelligence.

7. Performance & Resilience: What Does the System Produce Over Time?

The final test is not whether the organization reduced the defect count this month.

It is whether the system produces better outcomes repeatedly and remains capable of responding when conditions change.

Quality affects:

Financial performance
Customer experience
Productivity
Employee capacity
Operational continuity
Reputation
Risk exposure
Innovation capacity
Future opportunity

This is why quality belongs inside the broader architecture of Performance and Resilience.

A process that produces fewer defects but becomes extremely dependent on one expert may have improved efficiency while reducing resilience.

A control that eliminates one failure mode but adds excessive manual work may improve quality while reducing productivity.

An automated process that increases speed but creates opaque decisions may improve efficiency while increasing systemic risk.

The objective is not optimization of one layer.

It is integrated performance across the system.

The Cost of Delay: What Is the Organization Actually Losing While the Problem Remains Unresolved?

Executives often calculate the cost of a defect.

They should also calculate the Cost of Delay.

The Cost of Delay asks:

What continues to be lost because the underlying problem has not been resolved?

Financial Impact

The visible cost may include scrap, warranty claims, refunds, rework, overtime and additional inspection.

The less visible cost may include management time, expedited logistics, supplier intervention and capacity consumed by recovery work.

Operational Impact

Recurring defects consume productive capacity.

People stop doing planned work to investigate exceptions.

Schedules become less predictable.

Teams build buffers around unreliable processes.

Eventually, the organization can normalize rework as part of “how work gets done.”

Risk Exposure

Every unresolved recurring failure creates an exposure.

A small failure repeated thousands of times can become material.

A low-frequency failure in a critical process can be even more consequential.

The important variable is not simply frequency. It is systemic dependency and consequence.

Opportunity Loss

Capacity spent correcting preventable failures cannot be used elsewhere.

Engineers working on recurring defects are not developing new products.

Managers resolving avoidable escalations are not improving strategic execution.

Customer-service teams handling preventable complaints are not creating better customer experiences.

This is opportunity loss disguised as operational work.

Capability Loss

Rework can also weaken organizational capability.

Employees learn to become excellent at recovery instead of prevention.

New employees inherit workarounds rather than understanding the intended system.

Informal knowledge replaces robust process design.

The organization becomes dependent on experienced individuals who know how to “make the system work.”

That is a resilience warning.

Resilience Impact

A system that requires constant intervention may appear stable until demand increases, a key employee leaves, a supplier fails or a new disruption occurs.

The organization has not built resilience.

It has built compensation mechanisms.

That distinction is critical.

The Praveen Perspective: Why Defects Are More Expensive Than They Look

From Praveen Shekdar’s perspective, the economics of a defect should not be examined only through the traditional lens of quality cost.

With more than 25 years across IT, telecom, operations and enterprise consulting, and a positioning spanning business transformation, risk advisory, information security, privacy, resilience, ESG and operational excellence, the Praveen Perspective places quality within the broader architecture of business performance.

This creates a different executive question:

What happens to the rest of the business when a quality failure crosses functional boundaries?

A defect in a product may become a customer-service issue. A process failure may become a financial-control issue. A data-quality problem may become a privacy or information-security exposure. A supplier-quality failure may become a business-continuity risk. A recurring operational problem may eventually constrain growth.

The defect has not changed.

Its organizational consequences have expanded.

Praveen’s Cross-Functional View of Quality

The Praveen Perspective connects management systems, operational excellence, risk management, sustainability, digital governance and business performance rather than treating them as independent programmes.

Applied to quality, this means asking six connected questions:

Quality: What failed, and why?
Operations: What additional work, delay or capacity loss has the failure created?
Risk: What exposure does the failure create if it repeats or escalates?
Technology & Information: What systems, data or digital dependencies are involved?
Customer & Stakeholder Trust: What confidence is affected by the failure?
Resilience: Can the organization continue to perform if the same failure occurs under greater pressure?

This is particularly important because organizations often create separate reports for quality, risk, information security, sustainability and operations while the underlying business event may be the same.

The Praveen Quality-Risk-Performance Connection

A useful way to express this perspective is:

Defect → Disruption → Exposure → Decision → Resilience

The first stage is the visible defect.

The second is the operational disruption created by that defect.

The third is the risk exposure created when the disruption affects customers, information, suppliers, regulatory obligations, finances or continuity.

The fourth is the management decision required to address the underlying condition.

The fifth is the organization’s ability to absorb future variation without repeating the same failure.

This moves the conversation from “How do we close the corrective action?” to “What business capability must change so that the organization performs more reliably?”

Why Compliance Alone Cannot Explain the Cost

Management systems should become part of the operating model rather than another layer of administration.

The same principle applies to defects.

An organization may successfully document a corrective action and satisfy an audit requirement while the business continues to experience the underlying failure.

That is the difference between activity and outcome.

Closing a corrective action is an activity.

Reducing recurrence, protecting customer trust, releasing capacity and strengthening process capability are outcomes.

The Praveen Lens: Follow the Consequence, Not Just the Defect

Consider a critical supplier whose component begins failing inspection.

A conventional quality response may focus on supplier corrective action and incoming inspection.

A cross-functional Praveen Perspective would follow the consequence across the organization.

Quality asks why the component failed.
Operations assesses production disruption and rework.
Procurement evaluates supplier dependency and alternatives.
Risk evaluates the resulting exposure.
Information security considers whether supplier-system dependencies or information exchanges are affected.
Finance assesses expediting, working-capital and recovery implications.
Customer teams assess potential delivery and trust implications.
Business continuity considers whether the dependency could threaten continuity under a larger disruption.

The issue is still a supplier-quality problem.

But it is no longer treated as only a supplier-quality problem.

This is the essence of cross-functional business thinking.

A Practical Praveen Framework: The 5C Quality Test

For CXO-level diagnosis, the issue can be examined through five connected dimensions:

1. Cause

What created the defect, and which upstream decision or process condition enabled it?

2. Consequence

What does the defect disrupt beyond the immediate process?

3. Connection

Which functions, systems, suppliers, controls, people or decisions are connected to the failure?

4. Capability

What organizational capability is missing, weak or overly dependent on individual intervention?

5. Continuity

What happens if the same failure occurs during higher demand, a cyber incident, supplier disruption, regulatory change or another external shock?

The fifth question is particularly important for resilience.

A process that performs well only when conditions are stable may not be a resilient process.

Quality therefore has to be considered not only under normal operating conditions, but also under stress.

The Executive Implication

The Praveen Perspective ultimately reframes the economics of quality.

The question is not simply how much the organization spends correcting defects.

The more strategic question is:

How much organizational performance is being consumed because the system has not yet learned how to prevent, absorb and respond to the failure?

That connects quality directly to transformation, risk, resilience and operational excellence.

The value of a management system is determined by the business performance it enables, not merely by the documentation it produces.

When quality is viewed through this lens, defects become more than non-conformities.

They become signals about the strength of the organization’s architecture.

Those signals can help leadership identify where the business needs stronger processes, better decisions, more capable people, better intelligence, stronger controls or greater resilience.

A Practical Application of The Mandar Approach

Consider a recurring order-entry error.

The visible problem is inaccurate orders.

A conventional response might be to retrain employees.

The Mandar Approach expands the analysis.

Purpose

What customer outcome must the order process protect?

Decision

Which commercial or configuration decisions are creating ambiguity?

Process

Where does information change between sales, operations and fulfilment?

Control

Where can the error be prevented rather than detected later?

Capability

Do employees understand the decision rules, or are they relying on experience?

Intelligence

Which error patterns, customers, products or channels are recurring?

Performance & Resilience

What happens to cost, cycle time, customer experience and capacity if the problem continues?

The resulting intervention might not be “more training.”

It could involve redesigning the product configuration logic, simplifying approval rules, changing the digital workflow, improving master data, redesigning a control, clarifying decision rights or changing how exceptions are analysed.

That is the difference between fixing an error and redesigning the system that produces errors.

The Mandar Approach and The Praveen Perspective: Two Connected Lenses

The two perspectives approach the same organizational problem from complementary directions.

The Mandar Approach focuses on the internal architecture of the organization: how Purpose, Decision, Process, Control, Capability and Intelligence connect to create Performance & Resilience.

The Praveen Perspective extends the analysis across business transformation, risk, information security, privacy, resilience, ESG and operational excellence, asking how a quality issue can create consequences across multiple organizational disciplines.

The Mandar Approach	The Praveen Perspective
Starts with the organizational problem and its connections.	Starts with the cross-functional consequences and business exposure.
Uses Purpose → Decision → Process → Control → Capability → Intelligence → Performance & Resilience.	Uses a cross-functional lens connecting Quality → Operations → Risk → Technology & Information → Trust → Resilience.
Explores how disconnected systems create performance problems.	Explores how quality failures travel across business functions and create wider exposure.
Emphasizes Organizational Architecture.	Emphasizes transformation, risk, resilience and operational context.
Uses the Cost of Delay to reveal what the organization continues to lose.	Uses the consequence chain to reveal broader business impact and exposure.
Connects management disciplines to Integrated Business Performance.	Connects quality to enterprise risk, digital governance, resilience and operational excellence.

The distinction is useful because neither perspective reduces quality to a single function.

The Mandar Approach asks, “How is the organizational system connected?”

The Praveen Perspective asks, “How far does the consequence travel across the business?”

Together, these questions create a more complete executive view of quality.

The Defect Multiplier

One proposition that follows from The Mandar Approach is:

A defect has a direct cost, but a disconnected system gives that defect a multiplier.

The multiplier comes from everything the defect touches.

A single failure may trigger rework.

Rework consumes capacity.

Reduced capacity delays delivery.

Delayed delivery affects customer experience.

Customer dissatisfaction creates additional service work.

Management attention shifts to recovery.

Strategic work is deferred.

The organization then measures each consequence separately.

The system, however, experiences them as one connected event.

This is why the economics of quality cannot be reduced to the cost of non-conformance.

The real question is how far the defect travels through the organization.

Ask These Questions

What is the visible symptom—and what systemic condition could be producing it?
Which earlier decision allowed this failure to become possible?
Where are the critical connections between functions, systems or processes weak?
What work is being consumed by recovery, rework and escalation?
What is the Cost of Delay if the problem continues for another 6 or 12 months?
What data would change the decision we are currently making?
Are we building prevention and capability—or becoming better at recovery?

These questions shift the conversation from “Who caused the defect?” to “What architecture allows the defect to recur?”

That is a more useful management question.

Quality as an Integrated Operating System

The deeper lesson is that quality is not a department.

It is an emergent property of how the organization makes decisions, designs processes, develops capability, applies controls and uses intelligence.

This is why the same logic applies beyond traditional quality.

It can be applied to cybersecurity incidents, sustainability failures, operational disruptions, regulatory exposure, customer complaints, project overruns and transformation failures.

In each case, the visible problem may belong to one function.

The underlying problem may belong to the Integrated Operating System.

The Mandar Approach asks leaders to see that system.

Not to replace functional expertise, but to connect it.

Not to create another checklist, but to understand the architecture through which business outcomes are produced.

Not to pursue compliance as an end in itself, but to connect governance and controls to Performance.

Not merely to make the organization efficient under normal conditions, but to strengthen its Resilience when conditions change.

The ultimate objective is therefore not simply fewer defects.

It is an organization in which defects are less likely to emerge, easier to detect intelligently, faster to resolve, less expensive to absorb and less likely to recur.

That is what Integrated Business Performance looks like when quality is understood as a connected system.

And it returns us to the central principle of The Mandar Approach: