Quality Risk Management and Design Assurance

Introduction

Quality planning is most effective when it prevents failure rather than merely detects it after production or delivery. Quality risk management provides the systematic means for identifying what can go wrong, estimating the significance of failure, selecting proportionate controls, and verifying that those controls work. Design assurance extends this logic into product and process design by ensuring that requirements are complete, risks are understood, interfaces are controlled, and verification evidence is sufficient.

In an advanced quality system, risk is not treated as a one-time form-filling exercise. It is a lifecycle activity. Risks emerge during concept development, change when suppliers or technologies change, and may only become visible through field data. Accordingly, risk analysis must be connected to requirements management, design reviews, process control, reliability engineering, nonconformity management, corrective action, and leadership decision-making.

This chapter develops practical competence in risk-based thinking, failure mode and effects analysis (FMEA), fault tree analysis (FTA), design reviews, reliability concepts, and Design for Quality (DfQ). The emphasis is on proportionate controls: high-consequence or high-uncertainty risks require stronger evidence and tighter controls than minor, easily detectable issues.

Learning Objectives

On completing this chapter, the learner should be able to:

1. Explain risk, hazard, failure, consequence, likelihood, and detectability in a quality context.
2. Apply a risk-management lifecycle from context definition through monitoring and review.
3. Construct and interpret design and process FMEAs, including limitations of numerical risk-priority methods.
4. Use fault tree analysis to investigate combinations of causes leading to an undesired event.
5. Plan effective design reviews and distinguish verification from validation.
6. Apply basic reliability measures and interpret reliability evidence.
7. Select Design for Quality techniques and proportionate controls.
8. Evaluate governance, ethical, regulatory, and technological implications of quality risk decisions.

1. Foundations of Quality Risk Management

1.1 Risk-based thinking

Risk is commonly understood as the effect of uncertainty on objectives. In quality work, the objectives may include conformity, safety, performance, delivery, regulatory compliance, customer satisfaction, maintainability, and reputation. An effect may be positive or negative, although quality risk management normally concentrates on threats and opportunities for improvement.

A useful operational model is:

This is a conceptual relationship, not a universal numerical equation. It reminds the analyst that a severe outcome can require action even when it is unlikely, and that uncertainty itself may justify investigation. Detectability is particularly important in quality because an undetected defect can escape to the customer.

Important distinctions include:

• Hazard: a source or condition with potential to cause harm.
• Failure: loss of required function or inability to perform as specified.
• Defect: non-fulfilment of a requirement.
• Cause: a condition or mechanism that produces a failure.
• Effect: the consequence of a failure.
• Control: a measure that prevents a cause, detects a failure, or reduces its consequence.
• Residual risk: risk remaining after controls are implemented.
• Risk owner: the person accountable for ensuring that a risk is assessed and treated.

Risk-based thinking does not mean reducing every risk to zero. Zero risk is generally unattainable and may be economically or technically impossible. The objective is to make decisions that are justified, transparent, legally defensible, and consistent with the importance of the product and process.

1.2 The risk-management lifecycle

A robust lifecycle contains the following connected activities:

1. Establish context: define product boundaries, intended use, users, regulatory obligations, interfaces, assumptions, and acceptance criteria.
2. Identify risks: determine hazards, failure modes, causes, effects, and vulnerable groups or conditions.
3. Analyse risk: estimate severity, likelihood, exposure, uncertainty, and detectability using qualitative or quantitative evidence.
4. Evaluate risk: compare results with decision criteria and determine whether action is required.
5. Treat risk: eliminate the hazard where possible, reduce likelihood or consequence, improve detection, transfer or share responsibility, and document acceptance where justified.
6. Verify controls: demonstrate that preventive and detective measures are implemented and effective.
7. Communicate and consult: involve design, manufacturing, service, suppliers, customers, safety specialists, and other relevant stakeholders.
8. Monitor and review: use audits, complaints, warranty data, process indicators, incidents, and change information to update the assessment.

The hierarchy of controls is valuable when selecting treatments. Elimination is normally stronger than warnings; design safeguards are stronger than operator instructions; automatic detection and interlocks are generally stronger than visual inspection alone. Administrative controls remain useful but are vulnerable to training gaps, fatigue, turnover, and workarounds.

1.3 Proportionality and risk acceptance

Controls should be proportionate to the credible consequence and the quality of available evidence. A low-cost design change that removes a serious failure mode should normally be preferred to a complex inspection regime. Conversely, extensive controls for a trivial and readily detectable cosmetic issue may waste resources.

Risk acceptance criteria should be defined before results are viewed where practical. They may include severity categories, likelihood bands, legal requirements, customer specifications, reliability targets, and escalation rules. A risk matrix can support discussion, but it cannot replace engineering judgement. Categories near a boundary deserve particular scrutiny because small changes in assumptions may change the decision.

2. Failure Mode and Effects Analysis

2.1 Purpose and types

FMEA is a structured, team-based method for anticipating how an item, process, or system could fail and how those failures might affect requirements or users. It is preventive: the analysis should influence design and controls before failure occurs.

Common forms include:

FMEA is most effective when linked to customer needs, regulatory requirements, lessons learned, drawings, bills of material, process maps, and field performance data. It should begin early and be updated after design changes, process changes, incidents, or new evidence.

2.2 FMEA logic

A conventional FMEA records the function or requirement, failure mode, effect, severity, cause, occurrence, current prevention controls, current detection controls, recommended action, responsibility, and due date. The team should distinguish the direct local effect from the next higher-level effect and, ultimately, the end-user effect.

A failure mode should be stated precisely. “Unit fails” is too vague; “seal leaks above specified pressure after thermal cycling” is more useful because it supports causal analysis and test planning.

Many organisations use ratings for severity (S), occurrence (O), and detection (D), often on a 1–10 scale. A traditional risk priority number is:

Here, S, O, and D are ordinal rating scores, not necessarily measured physical quantities. The product is therefore a prioritisation index rather than a probability of failure or a true risk magnitude. It is meaningful only when rating definitions are consistent within the organisation.

For example, if a team assigns S = 8, O = 3, and D = 6:

This calculation does not mean that the failure has a 144-unit risk. It means that the team’s scoring convention places the item at an index of 144. A failure with S = 10, O = 1, D = 2 has an RPN of 20 but may deserve higher priority because its consequence is catastrophic. For this reason, severity thresholds, action-priority categories, criticality analysis, and explicit escalation rules should supplement or replace uncritical reliance on RPN.

2.3 Improving FMEA quality

A high-quality FMEA has the following characteristics:

• A multidisciplinary team including design, operations, quality, service, safety, and supplier expertise.
• Clear functions and measurable requirements.
• Causes stated at a level that can be acted upon.
• Existing controls separated into prevention and detection.
• Evidence-based ratings with documented definitions.
• Explicit linkage to design verification, control plans, test methods, and special characteristics.
• Actions assigned to named owners with dates and closure evidence.
• Review after changes and comparison with actual field or process data.

Common weaknesses include copying old FMEAs without confirming applicability, treating inspection as the primary prevention method, omitting interfaces, confusing causes with effects, and closing actions merely because a meeting occurred. FMEA is not a substitute for design competence, testing, or process capability evidence.

3. Fault Tree Analysis

3.1 Logic and notation

FTA begins with a defined top event, such as “loss of braking function” or “sterile package compromised,” and works deductively toward basic causes. Events are connected using logical gates:

• OR gate: the output occurs if any input event occurs.
• AND gate: the output occurs only if all input events occur, subject to stated assumptions.
• NOT or inhibit logic: an event is conditional on another condition.

FTA is particularly useful for safety-critical or system-level events, complex interactions, common-cause failures, and allocation of reliability targets. FMEA is generally bottom-up and component-oriented; FTA is top-down and consequence-oriented. They are complementary rather than competing methods.

If independent basic events A and B are connected by an OR gate, the probability of the top event is:

If A and B are independent:

For an AND gate with independent events:

The independence assumption must be justified. Shared power, environment, software, maintenance, supplier, or human factors can create common-cause dependence, making simple multiplication invalid.

3.2 Illustrative probability calculation

Suppose two independent protective devices fail during a defined mission with probabilities 0.02 and 0.03. If loss of protection requires both devices to fail, then:

Thus the estimated probability is 0.0006, or 0.06%, under the stated mission and independence assumptions. If both devices share a power supply that can fail, the common-cause path must be added; otherwise the estimate will be optimistic.

FTA also supports minimal cut sets: the smallest combinations of basic events sufficient to produce the top event. These identify vulnerabilities and can reveal that a nominally redundant architecture is not truly independent.

4. Design Reviews, Verification, and Validation

4.1 Design review as a control mechanism

A design review is a planned, documented evaluation of design maturity, adequacy, risk, and readiness for the next stage. It is not simply a presentation by the designer. Effective review teams are technically competent and sufficiently independent to challenge assumptions.

Typical review stages include concept review, requirements review, preliminary design review, critical design review, verification-readiness review, production-readiness review, and post-launch review. The names vary by sector, but the underlying questions remain similar:

• Are customer, statutory, regulatory, safety, and operational requirements complete?
• Are requirements unambiguous, measurable, traceable, and testable?
• Have interfaces and foreseeable misuse been addressed?
• Are high-risk failure modes supported by adequate controls and evidence?
• Are materials, tolerances, human factors, maintainability, cybersecurity, and service conditions considered?
• Are verification methods, sample sizes, environments, and acceptance criteria appropriate?
• Are unresolved issues visible, owned, and subject to escalation?

A review should produce decisions, action owners, due dates, assumptions, open risks, and objective evidence. A checklist can improve consistency but should not prevent discussion of novel risks.

4.2 Verification versus validation

Verification asks whether the output conforms to specified requirements: “Did we build the product right?” It may involve inspection, calculation, analysis, simulation, code review, or testing.

Validation asks whether the product meets intended use and user needs in the actual or representative operating context: “Did we build the right product?” Validation may involve field trials, usability studies, clinical or operational evaluation, environmental testing, and customer acceptance.

A design can pass verification and still fail validation if the original requirements were incomplete, users behave differently from assumptions, or the operating environment was inadequately represented. Traceability should connect user needs to requirements, design outputs, risks, verification activities, validation evidence, and changes.

5. Reliability Concepts and Evidence

Reliability is the probability that an item performs its required function for a specified time under stated conditions. It is not an intrinsic permanent property; it depends on load, environment, duty cycle, maintenance, manufacturing variation, and definition of failure.

Let T be the time to failure. The reliability function is:

The failure distribution function is:

The hazard rate, when defined, is the instantaneous failure rate conditional on survival to time t:

where f(t) is the probability density of T. These relationships require a well-defined population, mission, time scale, and failure criterion.

For a constant failure rate λ, the exponential model gives:

The model assumes a constant hazard rate and is often useful for a random-failure period, but it is not automatically suitable for infant mortality or wear-out. Under this model, the mean time to failure is:

MTTF describes a non-repairable item. For repairable systems, mean time between failures (MTBF) is interpreted with care and should be defined in relation to operating time, repair policy, and failure classification.

For a simple series system, where the system fails if any component fails and component failures are independent:

For a parallel redundant system, where the system succeeds if at least one independent component succeeds:

Real systems may not satisfy independence because of common-cause failures, imperfect switching, shared utilities, maintenance errors, or environmental stresses. Reliability demonstration testing must therefore consider confidence, test duration, censoring, sample size, and the distinction between demonstrating reliability and merely finding no failures.

6. Design for Quality

Design for Quality embeds prevention into product and process architecture. It aims to make the desired outcome easy and the undesired outcome difficult.

Core practices include:

• Quality Function Deployment: translate the voice of the customer into measurable technical characteristics and priorities.
• Robust design: reduce sensitivity to noise factors such as temperature, variation, misuse, and supply differences.
• Design for manufacturability and assembly: simplify parts, operations, orientation, joining, and inspection.
• Tolerance design: allocate variation so functional requirements remain satisfied.
• Poka-yoke: prevent incorrect assembly or make the error immediately apparent.
• Modular and interface design: control boundaries, compatibility, and change impact.
• Design for serviceability: enable safe diagnosis, replacement, calibration, and maintenance.
• Simulation and digital testing: identify stress concentrations, thermal issues, software interactions, and process constraints before physical release.

Tolerance decisions should be based on functional requirements rather than tradition. Where dimensions contribute independently to a critical characteristic, a worst-case stack-up may be used for guaranteed limits, while statistical approaches may be appropriate when distributions, independence, and process controls are justified. Statistical tolerance assumptions must never be used to conceal an unsafe worst-case condition.

Design teams should also address human factors, accessibility, cybersecurity where connected functions exist, sustainability, material traceability, and foreseeable misuse. A design that is technically conforming but confusing or unsafe to operate is not a quality success.

7. Integrated Risk Controls and Control Plans

Risk analysis becomes operational through linked controls. A typical chain is:

Requirement → risk analysis → design control → verification method → process control → inspection or monitoring → reaction plan → field feedback.

For example, a high-risk torque joint may require a specified torque requirement, tool capability study, calibrated tool, error-proof socket, automatic recording, independent audit, and reaction plan for an out-of-control condition. Merely instructing an operator to “tighten correctly” is weaker and less auditable.

Control plans should identify the characteristic, specification, measurement method, sampling frequency, responsible role, control method, and reaction plan. The plan should distinguish control of process inputs from detection of outputs. Statistical process control, capability analysis, automated interlocks, supplier controls, and layered process audits may be combined according to risk.

A process capability index is meaningful only when the process is stable and the measurement system is adequate. For a stable approximately normal process with specification limits USL and LSL, and process standard deviation σ:

The index measures potential capability assuming the process is centred. The centred capability index is:

where μ is the process mean. These indices are not valid substitutes for risk analysis, and non-normal or unstable processes require appropriate alternatives or transformation.

8. Illustrative Case: Medical Infusion Pump Occlusion Detection

Background

The following is a fictional illustrative case. A manufacturer is developing an electronic infusion pump for hospital use. The pump must deliver fluid at a programmed rate and alert the user when downstream occlusion causes pressure to rise. Failure to detect an occlusion could delay therapy or cause excessive pressure.

Problem

A prototype passed basic functional tests, but a design review identified uncertainty about sensor drift, tubing variability, software thresholds, and alarm audibility in a noisy ward. The initial team proposed final inspection and a user instruction as primary controls.

Analysis

A DFMEA identified the failure mode “occlusion not detected within the specified time.” Effects included interrupted therapy and possible patient harm. Causes included pressure-sensor drift, flexible tubing compliance, incorrect threshold calibration, software timing error, and alarm masking. Detection controls based only on end-of-line testing were inadequate because some interactions depended on operating conditions.

An FTA was then developed for the top event “unsafe occlusion condition not annunciated.” OR branches included sensor failure, software failure, power interruption, and invalid calibration. An AND branch examined a latent sensor degradation combined with inadequate diagnostic coverage. The analysis revealed a common-cause vulnerability: the same reference used for calibration also influenced the alarm threshold.

Approach and solution

The team implemented the following actions:

1. Added an independent plausibility check comparing pressure change, motor current, and delivery response.
2. Defined sensor drift limits and a start-up self-test.
3. Added a diagnostic for implausible or frozen pressure signals.
4. Tested tubing types, temperatures, flow rates, back pressures, and representative alarm environments.
5. Conducted a usability validation to confirm that users noticed, understood, and correctly responded to the alarm.
6. Updated the PFMEA and control plan for calibration, software loading, and traceability.
7. Established field monitoring for false alarms, missed alarms, and service returns.

Outcome

Testing showed that the original threshold produced unacceptable delays with one tubing family at low flow. The revised algorithm used validated response limits and a plausibility check. Verification demonstrated conformance over the specified operating envelope, while validation confirmed that clinical users could distinguish the alarm from competing alarms. The product was released with residual risks documented, post-market indicators defined, and change-control triggers established.

Learning points

The case demonstrates that risk controls must address interfaces and realistic use conditions. End-of-line inspection could not detect every dynamic interaction. FMEA helped organise failure modes; FTA exposed a common-cause path; design review coordinated evidence; and validation addressed actual user behaviour. The strongest improvement came from changing the design, not from adding paperwork.

9. Governance, Ethics, and Contemporary Practice

Quality risk decisions may affect health, safety, privacy, employment, access to essential services, and the environment. Organisations must not downgrade severity to meet a commercial launch date or conceal uncertainty behind a favourable average. Risk acceptance should be approved at an appropriate authority level, with rationale and evidence retained.

Regulated sectors may require formal design controls, traceability, post-market surveillance, supplier qualification, software validation, cybersecurity controls, or safety-case evidence. The exact requirements depend on jurisdiction and industry; organisations should consult applicable laws, standards, contractual obligations, and competent authorities rather than assuming that a generic risk matrix is sufficient.

Artificial intelligence can assist by searching historical nonconformities, clustering complaint data, suggesting possible causes, monitoring signals, and identifying missing links in traceability. However, AI outputs may reproduce biased historical decisions, miss novel failure modes, generate plausible but unsupported causes, or expose confidential data. Human experts must validate recommendations, preserve data lineage, control model changes, and ensure that automated decisions remain explainable and contestable where consequences are significant.

Contemporary best practice is moving toward integrated digital threads connecting requirements, FMEA, designs, tests, suppliers, manufacturing records, service data, and field performance. Digital integration improves traceability but also creates cybersecurity, access-control, data-quality, and configuration-management risks. More data does not automatically mean better risk management; the data must be relevant, reliable, and interpreted in context.

10. Challenges and Limitations

Risk methods have limits. Ratings can be subjective, teams can suffer from groupthink, historical data may not represent new technology, and rare events may have insufficient observations for reliable frequency estimates. FMEA can become excessively large, while FTA can omit human, organisational, or software interactions if the analyst defines the system too narrowly.

Risk matrices may imply false precision and can produce inconsistent decisions when category boundaries are poorly defined. Reliability models can be misleading when assumptions about constant failure rate, independence, normality, or operating conditions are unjustified. Inspection can create an illusion of control when defects are difficult to detect or when inspection itself is unreliable.

These limitations are managed through competent teams, explicit assumptions, sensitivity analysis, independent review, field feedback, measurement-system evaluation, scenario analysis, and escalation of high-severity uncertainty. The quality professional’s responsibility is not merely to complete an analysis but to challenge whether the analysis is credible enough for the decision being made.

Chapter Summary

Quality risk management is a lifecycle process for identifying uncertainty, analysing possible failures, evaluating significance, implementing proportionate controls, and monitoring residual risk. FMEA provides a structured bottom-up method for examining functions, failure modes, effects, causes, and controls. Traditional RPN can support prioritisation, but its ordinal scores and multiplication can obscure high-severity risks; explicit severity rules and action priorities are essential.

FTA provides a top-down analysis of combinations of events leading to an undesired outcome. Probability calculations require clearly stated assumptions, especially independence and common-cause conditions. Design reviews provide formal opportunities to challenge requirements, interfaces, assumptions, risks, and evidence. Verification demonstrates conformity to specified requirements, whereas validation demonstrates suitability for intended use.

Reliability is conditional on time, environment, duty cycle, and failure definition. Reliability functions, hazard rates, series and parallel models, and exponential assumptions are useful only within their applicability limits. Design for Quality prevents defects by improving requirements, robustness, manufacturability, tolerance design, usability, interfaces, and error-proofing. Finally, risk analysis must be connected to control plans, supplier management, change control, field data, governance, ethics, and continual improvement.

Key Terms

Risk: Effect of uncertainty on objectives.

Hazard: Source or condition with potential to cause harm.

Failure: Loss of a required function.

Defect: Non-fulfilment of a requirement.

Residual risk: Risk remaining after controls are applied.

Risk owner: Person accountable for managing a specified risk.

FMEA: Structured analysis of potential failure modes, effects, causes, and controls.

DFMEA: FMEA focused on product or design risks.

PFMEA: FMEA focused on process risks.

RPN: Product of severity, occurrence, and detection ratings in a traditional FMEA.

Fault tree analysis: Deductive analysis from a top event to contributing causes.

Top event: Undesired system event at the head of a fault tree.

Minimal cut set: Smallest combination of basic events sufficient to produce a top event.

Verification: Demonstration that specified requirements have been met.

Validation: Demonstration that intended use and user needs are met.

Reliability: Probability of performing a required function for a stated time and condition.

Hazard rate: Conditional instantaneous rate of failure.

Design for Quality: Designing products and processes to prevent defects and reduce variation.

Poka-yoke: Error-proofing method that prevents or immediately detects mistakes.

Common-cause failure: Multiple failures arising from a shared cause.

Review Questions

Short Answer Questions

1. Distinguish a failure mode, a cause, and an effect.
2. Why should risk controls be proportionate to consequence and uncertainty?
3. What is the difference between DFMEA and PFMEA?
4. Define verification and validation.
5. State one limitation of using RPN as the sole basis for prioritisation.

Long Answer Questions

1. Explain the complete quality risk-management lifecycle and show how monitoring feeds back into risk review.
2. Compare FMEA and FTA in terms of direction of analysis, typical outputs, and appropriate applications.
3. Explain how design reviews contribute to design assurance and identify the evidence that should be produced.
4. Discuss the assumptions and limitations of the exponential reliability model and series-system reliability.
5. Explain how Design for Quality can reduce dependence on final inspection.

Analytical / Application Questions

1. A process team assigns S = 9, O = 2, and D = 5 to one failure mode, and S = 6, O = 6, and D = 6 to another. Calculate both RPN values and explain why the first failure may still require priority treatment.
2. Two independent protective devices have failure probabilities of 0.01 and 0.04 during a mission. Use an AND-gate assumption to estimate the probability that both fail, then identify one reason the estimate could be optimistic.
3. Develop a mini-DFMEA for a consumer product of your choice, including at least three failure modes, their effects, causes, current controls, and recommended design actions.

Multiple Choice Questions with Answers

Question 1

Which statement best describes risk-based thinking in quality management?

A. Every identified risk must be eliminated regardless of cost

B. Controls are selected according to consequence, likelihood, uncertainty, and detectability

C. Only risks supported by statistical data should be considered

D. Risk is measured exclusively through inspection results

Correct Answer: B. Controls are selected according to consequence, likelihood, uncertainty, and detectability

Question 2

In a traditional FMEA, if S = 7, O = 4, and D = 3, what is the RPN?

A. 14

B. 21

C. 84

D. 147

Correct Answer: C. 84

Question 3

What is a principal limitation of RPN?

A. It cannot be calculated using ratings

B. It is a probability expressed in physical units

C. It may give low priority to a very severe failure with low occurrence

D. It applies only to financial risks

Correct Answer: C. It may give low priority to a very severe failure with low occurrence

Question 4

An OR gate in a fault tree represents a top event that occurs when:

A. All input events occur simultaneously

B. Any one of the input events occurs

C. No input event occurs

D. The inputs are statistically independent

Correct Answer: B. Any one of the input events occurs

Question 5

For two independent events with probabilities 0.02 and 0.03 connected by an AND gate, what is the probability that both occur?

A. 0.0006

B. 0.005

C. 0.05

D. 0.60

Correct Answer: A. 0.0006

Question 6

Which activity primarily asks whether the product meets intended user needs in its operating context?

A. Verification

B. Validation

C. Calibration

D. Inspection

Correct Answer: B. Validation

Question 7

Under a constant failure-rate exponential model, reliability is represented by:

A. R(t) = 1 + λt

B. R(t) = e^(−λt)

C. R(t) = λ/t

D. R(t) = t/λ

Correct Answer: B. R(t) = e^(−λt)

Question 8

Which is generally the strongest type of quality control?

A. A warning label alone

B. Final inspection after production

C. A design change that eliminates the failure possibility

D. Retrospective complaint analysis

Correct Answer: C. A design change that eliminates the failure possibility

Question 9

What is a common-cause failure?

A. A failure with no identifiable effect

B. Multiple failures arising from a shared cause

C. A failure found only during customer validation

D. A failure caused by independent random events

Correct Answer: B. Multiple failures arising from a shared cause

Question 10

Which statement correctly distinguishes process capability indices?

A. C_p considers centring while C_pk ignores centring

B. C_pk reflects both spread and distance from the nearest specification limit

C. Both indices are valid for unstable processes without qualification

D. C_pk is calculated without a process mean

Correct Answer: B. C_pk reflects both spread and distance from the nearest specification limit