That may sound provocative, but it reflects a pattern seen repeatedly across organisations: systems are upgraded, migrated, integrated, and automated, yet the underlying quality problems return. The tools change. The behaviour does not.
That is why data quality needs to be treated as a leadership metric, not just a system issue.
In many organisations, the same cycle repeats:
1. A business issue appears.
2. A temporary workaround is created.
3. The workaround becomes embedded.
4. The root cause is never addressed.
5. The problem resurfaces in a new form.
That cycle is not a technical failure alone. It is a governance failure.
A strong system can make poor choices harder, but only leadership can decide that trusted data matters enough to change the operating model.
Technology can validate fields, enforce rules, flag duplicates, and improve workflows. That matters. But technology only works when the organisation decides what “good” looks like, funds the change, and makes quality part of normal business operations.
If leaders do not define accountability, the system will only automate inconsistency faster.
This is why so many data initiatives fail to create lasting improvement:
– The project ends before the process changes.
– The implementation fixes records, not responsibility.
– Governance is launched as a programme and forgotten as a practice.
– Teams continue to optimise for speed, not quality.
Systems can support quality. They cannot create ownership.
Leadership accountability for data quality does not mean a senior executive needs to manually approve every record.
It means someone at the right level owns the business outcome and can drive the operating model around it. That includes:
– Setting standards.
– Defining acceptable quality levels.
– Prioritising investment.
– Removing blockers.
– Aligning incentives.
– Tracking progress.
Without that, data quality becomes a background task that everyone depends on but nobody protects.
If data quality were on the executive scorecard, what would be measured?
Would it be:
– Duplicate rate.
– Completeness.
– Timeliness.
– Conformance to standards.
– Time to correct source records.
– Business impact from data errors.
If it is not measured, it is unlikely to be managed.
In the next post, we look at why data problems keep reappearing even after systems are implemented and projects are completed.