A short guide to data quality

Teams tend to reach for this after something has already gone wrong. Everything we would tell a client about data quality in the time it takes to drink a coffee.

Numbers get quoted in meetings long after anyone remembers how they were calculated. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

The reason this keeps coming up

Bad data spreads faster than anyone corrects it. The teams that handle this well are rarely the ones with the biggest budgets. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

How we handle it

Automated checks catch drift that eyeballs miss. Where this goes wrong is almost never a lack of knowledge. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

The mistakes we see most

Someone must own each dataset or nobody does. The cost of getting this wrong is rarely visible on the day it happens. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

In practice

Data outlives the applications built on top of it, which is why the model deserves more thought than the screens. Three things worth confirming about data quality before you move on:

• Someone can say what the current setup is without going to look
• Bad data spreads faster than anyone corrects it — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If any of that sounds like a description of your current setup, it is fixable.