Discuss Data Quality Without Blaming the Buyer’s Team
Trace source, transformation and definition defects with a worked three-record cause map, assigning evidence-based repairs and preventive controls without blame.
10/24/20263 min read
A database with inconsistent records does not tell you which person caused the problem or whether anyone was careless. Errors can originate in a source, a transformation, an unclear definition or a handoff between systems. Diagnose the path of the data before blaming the team that happens to use it.
A neutral quality discussion should make correction easier. It should identify what the record needs for its intended purpose, where the current value came from and which control can prevent the same defect. Personal judgments rarely help answer those questions.
Describe the defect without assigning motive
Replace the team never keeps records updated with a specific observation: several current-role fields lack a verification date, or the latest import removed leading zeros from identifiers. State the consequence for the task. A missing field may matter for one decision and be irrelevant for another.
Separate factual defects from disagreements about definitions. Two teams may both be using active customer consistently under different rules. The solution may be a shared definition rather than a cleanup script. Do not choose the definition that makes your proposal appear simpler without buyer confirmation.
Worked example: three different causes
Fictional buyer Grove Services reviews three problematic account records. Record A has an old company name copied from a source that was accurate at the time. Record B has a correct identifier in the source file but a changed value after spreadsheet conversion. Record C has two account owners because the ownership policy does not cover shared projects.
The completed cause map reads: A, freshness issue, verify current name and retain the appropriate historical alias; B, transformation issue, preserve identifier formatting and test the import path; C, definition issue, obtain an ownership decision from the responsible business owner. None supports the general conclusion that the researchers are careless.
The repair owners differ. Research can verify A, the import owner can investigate B, and the policy owner must resolve C. Asking one analyst to fix everything would hide those dependencies and encourage arbitrary decisions.
Trace a small number of records end to end
Choose representative examples and follow source, entry, transformation, review and use. Keep the original evidence where permitted, but do not distribute unnecessary personal information just to demonstrate the defect. A synthetic reconstruction can explain a conversion problem without exposing real contacts.
Compare the value before and after each step. If the record changed during import, investigate the mapping and format. If the value never had a source, review the research brief. If the correct value was overwritten later, examine update precedence and ownership. The goal is a causal explanation supported by the record path.
Separate repair from prevention
Repairing current rows may be necessary, but it does not establish that the process is fixed. For each defect, name the preventive control: an explicit unknown state, a validation check, a verified source requirement or a rule for conflicting updates. Test that control with a deliberately difficult example.
Avoid promising perfect data. Some facts change, sources disagree and uncertainty remains. Define an acceptable state for the intended use and keep unresolved records out of actions that depend on the missing certainty.
Use language that invites evidence
Ask where this value was introduced rather than who entered the wrong thing. Ask what the receiving team needed rather than why they failed to understand. Individuals can still have accountable responsibilities, but accountability should follow evidence and a clear process expectation.
The final artifact is a defect-to-cause-to-owner map, with separate immediate repairs and preventive tests. W3C provenance concepts help preserve how data was produced and changed; privacy considerations limit the information used in the investigation. A useful sales discussion can then propose a bounded improvement without turning the buyer's data problems into an unsupported judgment about their people.