Quality and Continuous Improvement

Introduction and Context

Quality is not an inspection activity added at the end of a project. It is a management system through which an organization defines value, translates stakeholder requirements into measurable specifications, designs processes capable of meeting those specifications, and learns from performance variation. In project management, quality has a distinctive difficulty: the project is temporary, but the product, service, or capability it creates may operate for years. Decisions made during planning therefore determine not only whether the project is delivered successfully, but also whether its output is safe, reliable, maintainable, compliant, and valuable.

The Project Management Institute distinguishes between quality management activities concerned with conformance to requirements and grade, which concerns the category or functionality of a product. A low-grade product can be high quality if it consistently meets its stated requirements; a high-grade product can be poor quality if it fails to meet them. This distinction prevents managers from equating quality with luxury, excessive features, or high cost.

This chapter develops an integrated approach to quality planning, quality assurance, and quality control. It connects the cost of quality with statistical process control, Lean, Six Sigma, root-cause analysis, and continuous-improvement practices. Particular attention is given to managerial judgment: selecting useful measures, distinguishing common-cause from special-cause variation, deciding when a process requires redesign rather than inspection, and creating governance arrangements that make improvement sustainable.

Learning Objectives

By the end of this chapter, students should be able to:

1. Distinguish quality, grade, conformance, fitness for use, and customer value.
2. Design a project quality-management system covering planning, assurance, and control.
3. Calculate and interpret the cost of quality and basic process-performance measures.
4. Apply Pareto analysis, control charts, capability analysis, and root-cause methods appropriately.
5. Compare Lean, Six Sigma, PDCA, DMAIC, and related improvement approaches.
6. Evaluate the managerial, ethical, technological, and governance implications of quality decisions.
7. Integrate quality evidence into project decision-making and organizational learning.

1. Quality as a Project-System Concept

1.1 Definitions and dimensions of quality

Quality may be understood through several complementary perspectives:

• Conformance to requirements: the output satisfies explicitly specified criteria.
• Fitness for use: the output performs effectively in its intended context.
• Customer-perceived value: stakeholders judge the benefits to be worth the total cost and risk.
• Reliability: the output performs consistently over time under stated conditions.
• Resilience: the process or product continues to perform when conditions vary.
• Compliance: legal, regulatory, contractual, professional, and organizational obligations are met.

These perspectives may conflict. A project may meet a technical specification while creating an interface that users find confusing. Conversely, users may appreciate a feature that was not included in the approved scope, but adding it may create unacceptable security, cost, or schedule risk. Quality management consequently requires disciplined requirements management and explicit trade-off decisions rather than informal appeals to “better quality.”

1.2 Quality principles

Modern quality management is based on several principles:

1. Customer and stakeholder focus: requirements are discovered, clarified, prioritized, and validated.
2. Leadership responsibility: senior managers establish priorities, resources, accountability, and behavioral expectations.
3. Process approach: outcomes are produced by interconnected processes, not by inspection alone.
4. Evidence-based decision-making: claims about quality are supported by valid and sufficiently representative data.
5. People involvement: those who perform the work are essential sources of process knowledge.
6. Systems thinking: local optimization can damage end-to-end performance.
7. Prevention over detection: preventing defects is generally more efficient than finding and correcting them later.
8. Continual improvement: stable performance is not a reason to stop learning.

1.3 Quality, scope, and acceptance

Quality requirements should be traceable from stakeholder needs to acceptance criteria, work packages, tests, and evidence of completion. A useful requirements-to-verification chain is:

Need → requirement → measurable criterion → verification method → acceptance evidence.

For example, “the service must be responsive” is not sufficiently testable. A stronger requirement might state that 95% of authenticated transactions must receive a response within two seconds during a defined load profile. The latter identifies a metric, threshold, population, and operating condition. It also makes disagreement less subjective.

Quality must be distinguished from acceptance. Acceptance is the formal decision by an authorized stakeholder that deliverables meet agreed criteria. A deliverable may pass an acceptance test while still requiring operational improvement; acceptance closes a contractual or governance decision, whereas continuous improvement addresses future performance.

2. The Project Quality-Management System

A project quality system normally contains three linked processes: quality planning, quality assurance, and quality control.

2.1 Quality planning

Quality planning determines what quality means for the project and how it will be achieved. A quality-management plan commonly specifies:

• applicable standards, laws, codes, and contractual obligations;
• stakeholder requirements and acceptance criteria;
• quality roles, authorities, and escalation paths;
• process standards and methods;
• measures, sampling plans, and data sources;
• reviews, audits, tests, inspections, and hold points;
• defect classification and disposition rules;
• document and configuration controls;
• reporting arrangements and improvement mechanisms.

Planning should occur early because design choices influence the majority of life-cycle cost. Quality requirements that remain ambiguous until testing typically generate rework, disputes, and schedule compression.

A quality plan should distinguish leading indicators from lagging indicators. Leading indicators include requirements volatility, review completion, training coverage, test-case readiness, and unresolved design risks. Lagging indicators include defects discovered, rework hours, warranty claims, service failures, and customer complaints. A mature system uses both: lagging measures describe what happened, while leading measures help prevent recurrence.

2.2 Quality assurance

Quality assurance is the structured evaluation of whether project processes are suitable and are being followed. It includes process audits, peer reviews, lessons-learned sessions, supplier evaluations, maturity assessments, and independent assessments. Assurance asks questions such as:

• Is the process capable of producing the required result?
• Are responsibilities understood and performed?
• Are records reliable and traceable?
• Are deviations analyzed rather than normalized?
• Does the governance system encourage early escalation?

Assurance is not synonymous with policing. If an audit merely identifies noncompliance without understanding why the process failed, it may encourage concealment. Effective assurance combines independence with coaching and focuses on system improvement.

2.3 Quality control

Quality control monitors specific results and determines whether they conform to requirements. Activities include inspection, measurement, testing, sampling, statistical analysis, defect logging, and corrective-action verification. Control produces evidence for decisions such as accept, reject, rework, repair, use-as-is under approved concession, or investigate further.

Control data should be timely and actionable. A dashboard with dozens of metrics may provide less control than five well-defined measures linked to decisions. Every important metric should have an owner, a target or specification, a data definition, a collection frequency, and a prescribed response to abnormal performance.

3. Cost of Quality

The cost of quality (COQ) makes visible the financial consequences of achieving or failing to achieve requirements. It is conventionally divided into prevention, appraisal, internal failure, and external failure costs.

The general identity is:

Here, C_P is prevention cost, C_A is appraisal cost, C_IF is internal-failure cost, and C_EF is external-failure cost. All terms must be measured over the same period, project scope, and currency basis. The identity is an accounting classification, not proof that more prevention spending will always reduce total cost.

A broader “cost of poor quality” measure is:

where C_OP represents opportunity costs, such as lost sales, capacity unavailable for value-adding work, or reputational damage. Opportunity costs are difficult to estimate and should be reported with assumptions and sensitivity ranges rather than false precision.

Worked example: interpreting COQ

An illustrative project reports the following monthly values: prevention $24,000, appraisal $36,000, internal failure $52,000, and external failure $88,000. Therefore:

The failure component is $140,000, or 70% of total COQ. Management should not conclude simply that appraisal is too expensive. The more important question is whether targeted prevention—such as improved requirements reviews, supplier controls, or automated testing—can reduce the much larger failure costs. COQ trends are more informative than one month’s value. A temporary increase in prevention may be economically desirable if failure costs subsequently decline.

4. Statistical Tools for Quality Decisions

4.1 Variation and data discipline

Variation is unavoidable. The management question is whether variation is predictable and inherent in the current process or caused by an identifiable change. Before analyzing data, managers should define the operational definition, measurement method, sampling frame, time period, and data-quality controls. A biased sample or unstable measurement system can make sophisticated analysis misleading.

For observations x₁, x₂, ..., x_n, the sample mean is:

where n is the number of observations. The sample standard deviation is:

The denominator n − 1 is used when estimating population variation from a sample. These statistics summarize data but do not, by themselves, establish process capability or causation.

4.2 Pareto analysis

A Pareto chart ranks defect categories from largest to smallest and displays cumulative contribution. It supports prioritization, not causal proof. Categories must be defined consistently, and rare but severe events should not be ignored merely because their frequency is low. A safety-critical defect may deserve priority over a frequent cosmetic defect.

4.3 Control charts

A control chart distinguishes common-cause variation from potential special-cause variation. For individual measurements, a simplified three-sigma chart is often represented as:

Here, UCL and LCL are the upper and lower control limits, CL is the center line, and σ is the estimated process standard deviation. In practice, the appropriate chart depends on the data: X-bar and R charts for rational subgroups, individuals-and-moving-range charts for individual observations, p charts for fraction defective, and c or u charts for defect counts. Control limits describe process behavior; specification limits describe customer or engineering requirements. They are not interchangeable.

A point outside a control limit is evidence of a potential special cause, not automatic proof of a defect or a reason to adjust the process. Other signals—runs, trends, cycles, and unusual patterns—may also indicate instability. Over-adjusting a stable process in response to random fluctuation can increase variation, a phenomenon sometimes called tampering.

4.4 Process capability

Capability analysis is meaningful only when the process is statistically stable and the measurement system is adequate. For a normally distributed process with lower and upper specification limits LSL and USL, the potential capability index is:

The centered capability index is:

Here, μ is the process mean and σ is the within-process standard deviation. C_p reflects spread relative to the specification width, while C_pk also reflects displacement from the center. These indices assume meaningful specification limits, stable data, and an approximately suitable distribution or an appropriate non-normal method. They should not be used to certify a process based on a small, unstable, or manipulated sample.

Worked example: capability

Suppose a stable filling process has USL = 105 ml, LSL = 95 ml, mean μ = 101 ml, and standard deviation σ = 1.2 ml. Then:

The two centered distances are:

and

Thus C_pk = 1.11. The process spread is relatively narrow, but the process is shifted upward. Reducing variation alone is not the first priority; centering the process may produce the greatest benefit.

5. Lean, Six Sigma, and Improvement Frameworks

5.1 Lean thinking

Lean focuses on value from the customer’s perspective and the removal of waste. Common waste categories include defects, overproduction, waiting, unused talent, transportation, inventory, motion, and overprocessing. Lean tools include value-stream mapping, 5S, standard work, visual management, pull systems, setup reduction, mistake-proofing, and work-in-process limits.

Lean is not simply a cost-cutting program. Removing buffers without improving process capability can make the system fragile. Lean analysis should therefore examine flow, variation, capacity, safety, employee workload, and downstream consequences.

5.2 Six Sigma

Six Sigma is a data-oriented approach to reducing defects and process variation. DMAIC—Define, Measure, Analyze, Improve, Control—is primarily used for improving an existing process. DMADV or design-for-Six-Sigma approaches are more suitable when a new process or product must be designed.

• Define: clarify the problem, customer, scope, business case, and critical-to-quality requirements.
• Measure: establish operational definitions, validate measurement systems, and baseline performance.
• Analyze: identify relationships, stratify data, test hypotheses where appropriate, and identify likely causes.
• Improve: develop, test, and implement solutions; assess risks and unintended effects.
• Control: standardize the improved process, monitor performance, and define reaction plans.

Six Sigma should not become a ritual in which every problem requires a complex statistical project. The method should match the problem, data, risk, and decision value.

5.3 PDCA and other learning cycles

The Plan–Do–Check–Act cycle supports iterative learning. Plan defines the problem and prediction; Do conducts a controlled trial; Check compares results with expectations; Act standardizes, adapts, or abandons the change. In project environments, short PDCA cycles are particularly useful for piloting workflows, testing supplier changes, and improving review practices.

Agile retrospectives are another improvement mechanism. Their effectiveness depends on psychological safety, specific evidence, commitment to action, and follow-up. A retrospective that produces observations but no owner or due date is discussion, not improvement.

6. Root-Cause Analysis and Corrective Action

Root-cause analysis should explain why a problem occurred and why existing controls did not prevent or detect it. “Human error” is usually a symptom, not a sufficient root cause. A stronger analysis asks whether the process had ambiguous instructions, excessive workload, poor interface design, inadequate training, weak supervision, conflicting targets, or insufficient error detection.

Useful methods include:

• Five Whys: iterative questioning that is effective for relatively simple causal chains but vulnerable to premature closure.
• Fishbone diagram: organizes possible causes under categories such as people, methods, machines, materials, measurement, and environment.
• Fault-tree analysis: begins with an undesired top event and works backward through logical combinations of causes.
• Failure mode and effects analysis (FMEA): identifies failure modes, effects, causes, current controls, and risk-priority considerations. Traditional risk-priority numbers should not be treated as objective probabilities; severity, occurrence, and detection ratings are ordinal judgments and may conceal critical high-severity risks.
• Process mapping and value-stream analysis: reveal handoffs, queues, rework loops, and control gaps.

Corrective action should contain five elements: a clearly defined problem, verified cause or causal mechanism, action addressing the cause, responsible owner and completion date, and effectiveness verification. Containment protects customers immediately but is not the same as corrective action. Preventive action addresses plausible future failure modes before an incident occurs.

7. A Detailed Applied Case: Northstar Clinical Scheduling Platform

The following is a fictional illustrative case based on common project-management conditions.

Background

Northstar Health Network initiated a project to replace its fragmented appointment-scheduling systems with one platform. The project had a fixed regulatory launch date, multiple suppliers, and approximately 250 clinics. Quality requirements included accurate patient identification, correct appointment allocation, response-time targets, auditability, accessibility, and protection of personal information.

Problem

During pilot testing, 7.8% of appointment transactions required manual correction. The project team initially classified most failures as user error. Clinics reported duplicated bookings, incorrect provider availability, and delays during peak demand. The launch date was approaching, and pressure existed to increase testing volume rather than redesign the process.

Analysis

The quality team first established operational definitions and separated defects by type, clinic, transaction path, release version, and time of day. A Pareto analysis showed that two defect categories accounted for most corrections: stale provider-availability data and ambiguous patient matching. A process map showed that availability updates passed through two interfaces, one of which operated on a delayed batch schedule. A review of requirements revealed that “near real time” had never been assigned a measurable threshold.

Control-chart analysis of response time showed stable performance during ordinary demand but special-cause signals during the daily peak. A measurement-system review found that clinics recorded manual corrections inconsistently, so the baseline was corrected before comparing pilot sites. A fishbone analysis identified contributing factors in data synchronization, interface design, training, and governance. The analysis did not treat operators as the sole cause.

Approach and solution

The team adopted a DMAIC structure. It defined critical-to-quality requirements, including a measurable freshness limit for availability data and a patient-match confidence rule requiring manual verification below a threshold. It measured transaction performance using a common logging standard. It analyzed peak-load behavior and data-interface latency. It improved the system by:

1. replacing delayed availability batches with event-based updates for high-risk fields;
2. introducing a visible “data last updated” indicator;
3. adding a confirmation step for ambiguous patient matches;
4. conducting load tests using realistic peak patterns;
5. revising training around exception handling rather than generic system navigation;
6. creating a daily defect-review meeting with clinic, supplier, security, and product representatives;
7. establishing a control plan with response rules for data freshness, duplicate bookings, and response time.

The team also used a change-control board to prevent untested local modifications from reintroducing synchronization problems.

Outcome

After four weeks of controlled rollout, manual corrections declined from 7.8% to 1.9%, and duplicate bookings fell by 84% relative to the pilot baseline. Response-time performance improved during peak periods, although one rural clinic retained a connectivity constraint requiring a separate mitigation. Prevention and appraisal costs increased temporarily because of interface redesign and additional testing, but projected external-failure costs—complaints, rebooking work, and regulatory exposure—fell substantially.

Learning points

First, a quality problem often crosses organizational and technical boundaries. Second, data definitions and measurement reliability must be addressed before interpreting trends. Third, “user error” can conceal design and process weaknesses. Fourth, control plans must specify what happens when a metric leaves its acceptable range. Finally, a project’s quality system should protect the public and users, not merely help the team pass a launch gate.

8. Governance, Ethics, Technology, and Contemporary Practice

Quality decisions have ethical consequences when failures can harm patients, customers, employees, communities, or the environment. Managers should not suppress unfavorable data to protect milestones, redefine defects to improve dashboards, or accept undocumented deviations because escalation is inconvenient. Quality governance should provide independent escalation, protected reporting channels, traceable approvals, and explicit authority to stop work when risk is unacceptable.

Regulatory and contractual requirements may impose validation, records retention, accessibility, cybersecurity, environmental, or safety obligations. Compliance is a minimum condition, not a substitute for fitness for use. Audits should preserve evidence integrity and respect confidentiality and privacy.

Digital technologies can improve quality through automated testing, process mining, sensor data, anomaly detection, digital twins, and machine-learning prediction. However, automation introduces risks: biased training data, opaque models, concept drift, false alarms, cybersecurity vulnerabilities, and responsibility gaps. AI-generated recommendations should be validated against authoritative data and governed through human accountability, version control, access control, and monitoring. An algorithm that predicts defects is not itself evidence of causation, and a high-performing model in one process may fail after suppliers, demand patterns, or operating conditions change.

Contemporary quality practice increasingly emphasizes resilience, sustainability, supply-chain transparency, and quality by design. Climate events, geopolitical disruption, and cyber incidents demonstrate that quality includes the ability to maintain critical performance under disruption. Supplier quality should therefore examine not only conformance of incoming items but also process capability, change notification, traceability, business continuity, and ethical sourcing.

9. Implementation Guidance and Common Failure Modes

A practical implementation sequence is:

1. Identify stakeholders, intended use, critical risks, and applicable obligations.
2. Convert needs into measurable, testable requirements.
3. Map the end-to-end process and identify interfaces and handoffs.
4. Select a small set of meaningful quality measures.
5. Validate measurement methods and establish a baseline.
6. Design prevention, assurance, and control activities proportionate to risk.
7. Use appropriate statistical and qualitative tools to analyze variation.
8. Test improvements on a controlled scale and assess side effects.
9. Standardize successful changes and assign process ownership.
10. Review trends, lessons, and residual risks after project closure.

Common failure modes include treating quality as the testing team’s responsibility, using control limits as specification limits, collecting data without decisions attached, launching improvement projects without verified causes, rewarding throughput while ignoring rework, and counting training completion as proof of competence. Another failure is excessive measurement: metrics can become targets, and targets can be gamed. Measures should therefore be balanced with qualitative inquiry and periodic review of whether they still represent value.

Chapter Summary

Quality and continuous improvement form an integrated project-management discipline. Quality begins with stakeholder value and measurable requirements, not final inspection. Quality planning defines standards, responsibilities, measures, controls, and acceptance criteria. Quality assurance evaluates whether processes are capable and followed, while quality control evaluates specific results and triggers action.

The cost-of-quality framework distinguishes prevention, appraisal, internal-failure, and external-failure costs. Statistical tools help managers understand variation, prioritize defects, detect instability, and assess capability, but only when data definitions, measurement systems, assumptions, and sampling are sound. Control limits are not specification limits, and capability indices require a stable process.

Lean emphasizes value and flow; Six Sigma emphasizes variation and evidence; PDCA supports iterative learning; DMAIC structures improvement of existing processes. Root-cause analysis should address system conditions rather than assign blame, and corrective actions must be verified for effectiveness. Ethical governance requires truthful reporting, escalation of material risk, protection of affected stakeholders, and responsible use of technology. Sustainable improvement occurs when new practices are standardized, owned, monitored, and connected to organizational learning.

Key Terms

Quality: The degree to which characteristics fulfill requirements and intended use.

Grade: A category or classification assigned to products or services with different functionality.

Conformance: Compliance with specified requirements.

Quality planning: Determining quality requirements, methods, responsibilities, and evidence.

Quality assurance: Systematic evaluation of process suitability and adherence.

Quality control: Monitoring and testing outputs for conformity.

Acceptance criteria: Conditions that must be satisfied for formal approval.

Cost of quality: Total prevention, appraisal, internal-failure, and external-failure cost.

Cost of poor quality: Failure and opportunity costs associated with inadequate quality.

Common cause: Inherent, predictable variation produced by the current system.

Special cause: Variation attributable to an identifiable unusual factor.

Control chart: A time-ordered chart used to assess process stability.

Specification limit: A customer, engineering, or contractual boundary.

Process capability: The ability of a stable process to meet specification limits.

Lean: An approach focused on customer value, flow, and waste reduction.

Six Sigma: A data-oriented approach to reducing defects and variation.

DMAIC: Define, Measure, Analyze, Improve, and Control improvement cycle.

Root cause: A condition or mechanism whose removal reduces recurrence of a problem.

Corrective action: Action addressing a verified cause of nonconformance.

FMEA: A structured analysis of possible failure modes, effects, causes, and controls.

Review Questions

Short Answer Questions

1. Distinguish quality from grade using an example.
2. What is the difference between quality assurance and quality control?
3. Name the four conventional categories in the cost of quality.
4. Why must a process be stable before capability indices are interpreted?
5. What is the purpose of a control plan?

Long Answer Questions

1. Explain how a project quality-management plan connects requirements, verification, acceptance, and continuous improvement.
2. Compare Lean and Six Sigma in terms of objectives, methods, data requirements, and appropriate applications.
3. Explain the difference between common-cause and special-cause variation and discuss the managerial risks of confusing them.
4. Evaluate the strengths and limitations of Pareto analysis, control charts, and root-cause analysis.
5. Discuss the ethical and governance responsibilities of project managers when quality data threaten a scheduled launch.

Analytical / Application Questions

1. A project reports prevention cost of $30,000, appraisal cost of $45,000, internal failure cost of $65,000, and external failure cost of $110,000 in one quarter. Calculate total COQ and determine the percentage attributable to failure costs. Recommend two areas for investigation, explaining why the recommendation requires more than simply cutting appraisal expenditure.
2. A stable process has USL = 52, LSL = 48, μ = 51, and σ = 0.5. Calculate C_p and C_pk, then explain whether variation or centering should receive priority.
3. A software project has a high rate of defects classified as “operator error.” Design a root-cause-analysis plan that tests whether interface design, requirements ambiguity, workload, training, data quality, and governance contributed to the failures. Specify the evidence you would collect and how you would verify corrective-action effectiveness.

Multiple Choice Questions with Answers

Question 1

Which activity is primarily a quality-assurance activity?

A. Inspecting each completed unit against acceptance criteria

B. Auditing whether the approved development process is being followed

C. Repairing a defective deliverable

D. Calculating the number of customer complaints

Correct Answer: B. Auditing whether the approved development process is being followed

Question 2

A project reports prevention cost of $20,000, appraisal cost of $30,000, internal failure cost of $40,000, and external failure cost of $10,000. What is total COQ?

A. $60,000

B. $70,000

C. $90,000

D. $100,000

Correct Answer: C. $90,000

Question 3

Which statement correctly distinguishes a specification limit from a control limit?

A. A specification limit is calculated from recent process data

B. A control limit is always set by the customer

C. A specification limit describes required performance, while a control limit describes process behavior

D. The two terms mean the same thing

Correct Answer: C. A specification limit describes required performance, while a control limit describes process behavior

Question 4

What is the primary purpose of Pareto analysis?

A. To prove the root cause of a defect

B. To prioritize categories contributing most to an observed problem

C. To calculate process capability

D. To replace measurement-system validation

Correct Answer: B. To prioritize categories contributing most to an observed problem

Question 5

For a stable process with USL = 105, LSL = 95, and σ = 1, what is Cp?

A. 0.60

B. 1.00

C. 1.67

D. 3.00

Correct Answer: C. 1.67

Question 6

A process has USL = 105, LSL = 95, μ = 101, and σ = 1. Which statement is correct?

A. Cpk is determined by the lower specification distance and is approximately 2.00

B. Cpk is determined by the upper specification distance and is approximately 1.33

C. Cp and Cpk must be identical because the process is stable

D. Capability cannot be assessed because the mean is not zero

Correct Answer: B. Cpk is determined by the upper specification distance and is approximately 1.33

Question 7

Which DMAIC phase focuses on validating the measurement system and establishing a performance baseline?

A. Define

B. Measure

C. Improve

D. Control

Correct Answer: B. Measure

Question 8

Why is “human error” often insufficient as a root cause?

A. Human beings cannot make errors in stable processes

B. It may fail to identify design, workload, instruction, or governance conditions that enabled the error

C. It automatically proves that training is unnecessary

D. It can only be used in manufacturing

Correct Answer: B. It may fail to identify design, workload, instruction, or governance conditions that enabled the error

Question 9

Which response best represents prevention rather than appraisal?

A. Adding a final inspection after production

B. Increasing the number of rejected items recorded

C. Redesigning a workflow to prevent an input from being entered incorrectly

D. Rechecking a completed deliverable

Correct Answer: C. Redesigning a workflow to prevent an input from being entered incorrectly

Question 10

Why should AI-based quality predictions be governed by human accountability?

A. AI systems always produce random results

B. Predictions may be affected by biased data, model drift, opacity, or changing operating conditions

C. Human review makes measurement unnecessary

D. AI cannot process quality data

Correct Answer: B. Predictions may be affected by biased data, model drift, opacity, or changing operating conditions