Correcting a data error does not necessarily change the process that produced it. The report can be ready for use while the people supplying its numbers remain unaware that anything went wrong. That distinction should shape what a data quality initiative is expected to deliver.
In their September HBR article, Masha Shunko and Serguei Netessine argue that companies struggle to generate enterprise-wide returns from AI because they automate individual tasks rather than redesign the workflows that produce business value. For data leaders, this raises a useful question about the scope of improvement: does the work end when a number is corrected, or does the correction inform how the next number is produced?
A successful correction can leave the cause untouched
Thomas Redman's “Data’s Credibility Problem” opens with an executive preparing a presentation. She spots something wrong in the market share figures. Her assistant traces the error to data supplied by Market Research, and the figures are corrected. The presentation goes well. She rewards the assistant and proposes making double-checking the numbers a policy.
Nobody tells Market Research about the error or works with the department to prevent it happening again. The immediate problem is resolved, but the proposed policy adds a recurring check without addressing how the faulty data was produced.
That is a specific failure a data quality initiative can address. The correction needs to reach someone who can investigate its cause and change the relevant work. Otherwise, even a well-executed repair leaves the source process unchanged. Automating the check could make it less costly, but it would still leave that investigation undone.
This does not make downstream checks unnecessary. In Redman's example, checking protected the presentation. The missing step was to connect that useful intervention to prevention. A data team should be able to explain both what its checks catch and what happens after they catch it.
Define what happens after an error is found
Before funding the next data quality initiative, ask which process creates the data, described as it is actually performed, and which manager can change that process. Then agree how errors will reach that manager and how a proposed correction will be checked against subsequent data.
For the market share example, that would mean sending the discrepancy back to Market Research, investigating why it occurred, and checking whether the next delivery contains the same problem. These are proposed follow-up steps, not events reported in Redman's account. They give the initiative a way to distinguish successful repair from reduced recurrence.
The remit matters for the data leader as well. In their 2021 article on CDO tenure, Tom Davenport, Randy Bean and Josh King observe that many companies do not seem to know exactly what they want from the role. For a data quality initiative, I would make the expectation explicit: identify who delivers the immediate correction and who is responsible for changing the source process.
If the funding covers only detection and repair, describe that scope honestly. A commitment to reduce recurring errors needs to include the work required to prevent the next one.
Sources
- Stop Automating Old Processes. Design New Ones Instead., Harvard Business Review
- Data’s Credibility Problem, Harvard Business Review
- Why Do Chief Data Officers Have Such Short Tenures?, Harvard Business Review