Organisations seldom conclude that they have a data problem. They conclude that reporting is slow, that a particular team’s figures cannot be trusted, or that a decision keeps getting deferred. The underlying cause is the same, and it is visible earlier than most teams realise.
Three signals show up consistently, and all of them are observable without an assessment exercise.
1. The same question produces different answers
Finance reports one revenue figure, the commercial team another, and both are defensible because they are measuring slightly different things — one recognises at contract signature, the other at delivery; one includes a category the other excludes.
The problem is not arithmetic. It is that the definition lives in people’s heads and in the logic of individual reports rather than anywhere shared. This is worth catching early because it is cheap to fix at the point of disagreement and expensive to fix after both definitions have been embedded in a dozen downstream systems.
A practical first move: take the ten or fifteen measures that actually appear in leadership discussions and write down, for each, what it counts, what it excludes, which system is authoritative, and who decides if that changes. It is unglamorous work and it resolves a surprising proportion of recurring disputes.
2. Numbers arrive after the decision
If a weekly report lands on Thursday about the week that ended Sunday, it is a record, not an input. Teams adapt by making the decision on instinct and using the report to confirm it afterwards — which looks like data-driven management and is not.
The instinct is to speed up the pipeline. Sometimes that is right. Often the more useful question is which decisions genuinely need to be faster, because the answer is usually a small subset. Accelerating everything is expensive; accelerating the three things that actually change behaviour within the week is tractable.
3. Someone reconciles by hand every month
There is almost always a person, or a small team, who exports from two systems and reconciles them in a spreadsheet. They are competent and the work gets done, which is exactly why the problem persists — the manual step absorbs the inconsistency and hides it from everyone upstream.
These reconciliations are worth mapping, because each one marks a place where two systems disagree about something the business considers a single fact. That map is a better prioritisation tool than most formal data assessments, and it costs an afternoon of conversation to produce.
What not to do about it
The common response is a large platform programme: consolidate everything, govern everything, then resume normal service. These programmes are hard to fund, hard to sustain, and tend to deliver their first visible benefit long after the sponsor has moved on.
The alternative is narrower and less satisfying to plan. Take one decision that matters. Fix the definitions it depends on, establish who owns them, make the data behind it trustworthy enough to act on, and let that become the pattern. Governance that grows out of a working example tends to survive; governance introduced as policy tends to be worked around.
Ownership is the part that sticks
Tooling changes. What persists is whether a named person is accountable for a critical data domain — whether someone can say, without convening a meeting, what “active customer” means and who approves a change to it.
Where that accountability exists, quality tends to improve on its own, because somebody notices when it slips. Where it does not, quality decays regardless of platform, because everyone assumes it is someone else’s field.