I've watched this film enough times to know the ending. An organisation notices its data is a mess — reports that disagree, a customer who exists three times under two spellings, a total that's off by an amount nobody can explain. Frustration builds until someone funds a data quality project: a team, a budget, a few months of intensive cleanup. The data gets scrubbed, the duplicates get merged, the reports finally agree, and everyone celebrates a job well done. The project closes. The team disbands. And within a year — often much less — the quality has decayed right back to where it started, because the thing that made the data dirty in the first place never changed. The cleanup was real. It just wasn't durable, and it was never going to be, because data quality is not a project you finish. It's a process you run forever, and confusing the two is the single most expensive mistake I see organisations make with their data.

Let me make the distinction concrete, because it's the whole point. A project has a start, an end, and a deliverable. You do it, it's done, you move on. A process is ongoing, embedded in how work happens, with owners who keep it running indefinitely. Cleaning your existing data is a project — a fine and necessary one. Keeping it clean is a process, and if you only fund the project, you've bought yourself a temporary state that gravity will steadily undo.

Why the project always decays

Data doesn't get dirty by accident and stay dirty out of spite. It gets dirty because of the ongoing conditions that produce it: a form that doesn't validate input, so people type the country name six different ways. An integration that silently drops a field. A process where two teams create customer records with no shared rule for what counts as a duplicate. A source system that changes a code's meaning without telling anyone downstream. Every one of those is a tap left running. Your cleanup project mops the floor beautifully, and the moment you leave, the taps are still on. Within months the floor is wet again, and everyone's baffled that the expensive cleanup "didn't work." It worked. You just didn't turn off the taps, because turning off the taps isn't a cleanup — it's a change to how the water flows, permanently.

What the process actually looks like

Running data quality as a process means putting durable machinery in place around the data, not just scrubbing the data once:

  • Ownership that persists. Every important data domain needs a named owner — a data steward — who is accountable for its quality on an ongoing basis, not a project team that dissolves. If nobody owns it after the project, nobody maintains it. This is the load-bearing wall, and it's a people decision, not a technical one.
  • Quality measured continuously, not audited occasionally. You can't manage what you don't watch. Define what "good" means for your key data — completeness, validity, uniqueness, freshness — and measure it on a schedule, so decay shows up as a trend on a dashboard rather than a crisis in a board meeting.
  • Rules at the point of entry. The cheapest place to fix bad data is before it exists. Validation on the form, constraints in the source system, a clear definition of a duplicate enforced where records are created — every rule at the source is a mop you never have to buy.
  • A feedback loop that closes. When quality slips, someone has to be told, and something has to happen. A measurement nobody acts on is theatre. The process only works if detection connects to correction and, ideally, to fixing the tap that caused it.

The communication half nobody budgets for

Here's the part that gets left out of every quality initiative I've seen, and it's the part I care about most: data quality is at least as much a communication problem as a technical one. The duplicate customer records usually exist because two teams were never given a shared definition of a customer. The country field is a mess because nobody told the people filling it in that it mattered or why. You can buy the finest data quality tooling on the market and it will not fix a problem that is fundamentally about people not sharing a definition or not understanding the consequences of a sloppy entry. The durable fix is as much about getting humans to agree on what the data means and to care about getting it right as it is about any rule or tool. Skip that and you're automating the enforcement of a definition nobody agreed to.

The reframe that makes it stick

So if you're about to fund a data quality effort, here's the reframe that decides whether your money lasts: don't ask "how do we clean this up?" Ask "why does it keep getting dirty, and what ongoing process will keep it clean?" Fund the process, not just the project — the owners, the measurement, the source-side rules, the shared definitions — and the cleanup becomes the first run of something permanent rather than a one-off you'll repeat in eighteen months at full price.

The counter-view I'll grant: you do need the project too. You can't run a maintenance process on a decade of accumulated mess without cleaning it up first, and sometimes the cleanup is what earns the credibility and budget to fund the process that follows. So do the project — just never mistake it for the finish line. The floor being clean today tells you nothing about whether it'll be clean next quarter. That depends entirely on whether you turned off the taps, and the taps are a process, running quietly, owned by someone, forever. That's not the exciting answer. It's the one that's still true a year later, which is the only test of a data quality effort that actually matters.