Study guide
4.4 Root-Cause Analysis & Remediation
DAMA Certified Data Management Professional CDMP
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview & DMBoK Framework
1.1 CDMP Exam Details & Strategy 1.2 The DMBoK Framework 1.3 Data Management Organization & Roles
2 Chapter 2: Data Governance (Part A)
2.1 Data Governance Principles & Drivers 2.2 Operating Models & Structures 2.3 Policies, Standards, and Procedures
3 Chapter 2: Data Governance (Part B)
2.4 Data Stewardship 2.5 Governance Metrics & Implementation
4 Chapter 3: Data Modeling and Design (Part A)
Section 3.1: Conceptual, Logical, and Physical Models Section 3.2: ERD Notations & Relational Modeling Section 3.3: Normalization
5 Chapter 3: Data Modeling and Design (Part B)
3.4 Dimensional Modeling 3.5 Naming Standards & Modeling Best Practices
6 Chapter 4: Data Quality (Part A)
Section 4.1: Data Quality Dimensions Section 4.2: Data Quality Policy & Rules Section 4.3: DMAIC & DQ Improvement Lifecycle
7 Chapter 4: Data Quality (Part B)
4.4 Root-Cause Analysis & Remediation 4.5 DQ Metrics, Tools, and Reporting
8 Chapter 5: Metadata Management (Part A)
5.1 Business, Technical, and Operational Metadata 5.2 Metadata Lineage & Impact Analysis 5.3 Repository Architectures
9 Chapter 5: Metadata Management (Part B)
5.4 Standards and Semantics 5.5 Metadata Governance & Integration
10 Chapter 6: Master and Reference Data Management
6.1 Master vs Reference Data 6.2 MDM Repository Architectures 6.3 Match-Merge & Identity Resolution 6.4 Reference Data Governance & Standards
11 Chapter 7: Data Warehousing and Business Intelligence
7.1 DW Architectures: Inmon vs Kimball 7.2 Data Warehousing Storage & Load Patterns 7.3 BI Delivery & OLAP 7.4 Data Marts & Enterprise Data Warehouses
12 Chapter 8: Data Architecture
8.1 Enterprise Data Architecture & Zachman Framework 8.2 Data Flow Diagrams & Value Chains 8.3 Architecture Frameworks & Standards
13 Chapter 9: Document and Content Management
9.1 Records Management & ECM 9.2 Retention, Disposal, and E-Discovery 9.3 ARMA GARP Principles & Taxonomies
14 Chapter 10: Data Integration and Interoperability
Section 10.1: Integration Patterns & Technologies Section 10.2: Replication & Virtualization Section 10.3: Canonical Models & Integration Standards
15 Chapter 11: Data Security
Section 11.1: Security Principles: CIA Triad & Privacy Section 11.2: Access Control & Encryption Section 11.3: Security Regulations & Standards
16 Chapter 12: Data Storage and Operations
Section 12.1: Database Technologies & DBA Roles Section 12.2: Backup, Recovery, and High Availability Section 12.3: Performance Tuning & Operations
17 Chapter 13: Big Data and Data Science
13.1 Big Data V's & Technologies
18 Chapter 14: Data Ethics
14.1 DMBoK Data Ethics Framework
19 Chapter 15: Data Management Process and Maturity
15.1 Maturity Assessment Frameworks
4.4 Root-Cause Analysis & Remediation
Key Takeaways Explain This Topic AI
Root-cause analysis (RCA) shifts data quality management from reactive correction of symptoms to proactive prevention of errors at the source.
The Five Whys technique is an iterative inquiry method used to trace technical symptoms down to process or governance deficiencies.
Fishbone (Ishikawa) diagrams categorize potential error sources into standard domains: People, Process, Technology, Data, and Control/Measurement.
The 1-10-100 Rule establishes that prevention ($1) is ten times cheaper than correction ($10) and one hundred times cheaper than downstream failure ($100).
Last updated: July 2026
Introduction to Root-Cause Analysis in Data Quality
In data quality management, organizations often fall into the trap of treating symptoms rather than solving fundamental issues. Root-Cause Analysis (RCA) is a structured process used to identify the underlying factors responsible for a data defect. Within the Data Management Body of Knowledge (DMBoK2) framework, data quality issues are treated as process failures. When bad data is discovered, simply correcting the value (e.g., patching a corrupt ZIP code) is reactive and temporary. Because the system or process generating the error remains unchanged, the error will reoccur. RCA shifts the focus from Correction (reactive clean-up) to Prevention (proactive avoidance).
A rigorous RCA process follows these steps:
Identify the Defect : Clearly define the data anomaly and the affected datasets.
Determine the Impact : Understand downstream business processes, applications, and reports affected.
Map the Data Flow : Trace the lifecycle of the data from the point of entry through integration stages (ETL pipelines) to the target.
Apply Analytical Techniques : Use structured methods like the Five Whys and Fishbone Diagrams .
Formulate Remediation Plans : Propose permanent fixes to processes, applications, or governance policies.
The Five Whys Technique
The Five Whys is an iterative interrogative technique used to explore the cause-and-effect relationships underlying a particular problem. The primary objective is to peel away layers of symptoms by repeatedly asking "Why?" until the root cause is exposed. Often, what appears to be a technical database error is actually a process, training, or governance deficiency.
Applying the Five Whys: A Data Quality Example
Problem Statement : The weekly sales forecasting dashboard displays inaccurate regional sales numbers.
Why 1 : Why is the dashboard showing inaccurate regional sales figures?
Answer : Because the regional sales database is missing transaction logs from three branch stores.
Why 2 : Why are the transaction logs from those branch stores missing?
Answer : Because the batch file transfer process failed to upload files to the integration server.
Why 3 : Why did the batch file transfer process fail?
Answer : Because the File Transfer Protocol (FTP) credentials for those stores expired.
Why 4 : Why were the FTP credentials expired and not renewed?
Answer : Because the system administrator upgraded the security certificate on the integration server and did not update the branch configurations.
Why 5 (Root Cause) : Why was the server upgraded without updating the branch configurations?
Answer : Because the infrastructure team lacks a formal change management protocol linking application upgrades to data integration touchpoints.
By tracing the problem to this process failure, the organization can implement a permanent governance fix, rather than repeatedly resetting credentials manually.
The Fishbone (Ishikawa) Diagram for Data Quality
The Fishbone Diagram (or Ishikawa Diagram ) is a visual tool used to systematically identify and categorize the potential causes of a problem (the "effect"). The diagram resembles a fish skeleton, with the "head" stating the problem and the "bones" representing categories of potential causes. In data quality, standard categories are modified to address data management realities:
People : Lack of data literacy or training for data entry staff, ambiguous data ownership, or absent Data Stewards .
Process : Poorly defined business rules, manual workflows without double-entry verification, and inadequate testing.
Technology : Legacy systems with structural constraints (e.g., short field lengths) or lack of automated API validation rules.
Data : Missing reference metadata, ambiguous schemas, or format drift in source feeds.
Measurement/Control : Absence of proactive data profiling, inadequate monitoring, and poorly defined metrics.
Category Potential Cause of Bad Data Practical Remediation
People Users type placeholders like "N/A" to bypass mandatory fields. Redesign training; explain downstream impacts; restrict placeholder values.
Process Data is manually transcribed from paper forms to digital databases. Digitize intake processes; implement optical character recognition (OCR) with validation.
Technology System timeout during batch processing causes truncated records. Allocate system resources; introduce transaction rollback and logging mechanisms.
Data Vendor feeds change format (e.g., date formats swap from MM-DD-YYYY to YYYY-MM-DD). Define Data Sharing Agreements (DSAs) and schema validation checks at ingestion.
Control No alerts are triggered when null rates spike in key fields. Implement Statistical Process Control (SPC) and automated dashboard notifications.
Prevention vs. Correction: The 1-10-100 Rule
The ultimate goal of RCA is to prioritize Prevention over Correction :
Prevention refers to proactively designing data entry mechanisms, integration interfaces, and training to ensure data is captured correctly the first time (e.g., drop-down menus, database constraints).
Correction refers to reactively repairing data errors after they enter the system (e.g., running clean-up scripts, deduplication).
The economic justification for prevention is summarized by the 1-10-100 Rule :
Prevention ($1) : Spending $1 upfront on validation rules, training, and database design. Example: implementing email validation on a signup web form.
Correction ($10) : Spending $10 to detect, isolate, and clean data errors after they have been saved. Example: running automated scripts to clean invalid emails in a CRM.
Failure ($100+) : Incurring $100 or more in costs when bad data reaches downstream users or customers. Example: mailing marketing materials to invalid addresses, failing audits, or losing customers due to billing errors.
Error Profiling and Pattern Analysis
Error Profiling is the systematic practice of identifying, analyzing, and documenting patterns of errors within a dataset. Unlike general data profiling, which analyzes the entire dataset, error profiling isolates the subset of records that failed quality checks to analyze how and why they failed.
Key techniques include:
Error Classification : Grouping errors into logical categories based on the dimension they violate (e.g., missing values as completeness errors, invalid zip codes as validity errors).
Pattern Matching : Analyzing the structural patterns of failed records (e.g., identifying that phone numbers failed because they are exactly 9 digits instead of 10).
Source Clustering : Grouping errors by origin channel (mobile app, desktop site, API version) to isolate the faulty interface.
Temporal Analysis : Looking at when errors occur (e.g., spikes during night batch runs) to trace issues to scheduling or infrastructure events.