On this page
The short answer
Do not try to fix everything at once. That is the most common mistake, and it is why messy data setups stay messy: the effort spreads thin across ten problems, and none of them ever finishes.
A better approach has three steps. First, take an inventory: a plain, written list of what you have and where it hurts. Second, score each issue two ways: by impact (how much it blocks or distorts a real decision) and by effort (how much time, risk and dependency the fix carries). Third, start with the one change that makes the next three easier.
That change is almost never a new tool. It is usually something structural and unglamorous: agreeing what your key numbers mean, or fixing how the same customer is recognised across systems. Get one of those right and several other problems shrink on their own. Buy a dashboard tool first and you have simply built a faster way to display numbers no one trusts.
What this usually looks like
The symptoms are familiar long before anyone calls them a data problem.
Every team has its own numbers. Sales quotes one revenue figure, Finance another, and the board pack a third. Each is defensible; none agreed. Month-end involves a lot of manual work: someone exports files, pastes them into a spreadsheet, fixes the same errors by hand, and rebuilds the report they rebuilt last month. Ask where a number comes from and the honest answer is often “from someone’s file”, not “from the billing system”.
No one is sure what is authoritative: which source is the one to trust when two disagree. Reports get copied and edited until there are five versions and no original. The person who understands the master spreadsheet becomes a single point of failure; when they are away, reporting stops.
None of this means anyone did a bad job. It is what happens when a company grows faster than its data setup. Tools were added one at a time, each to solve one problem, and no one stepped back to make them work together. The mess is an accumulation, not a single mistake. That is also why it will not clear itself up without a deliberate decision about sequence.
Start with these checks
Before you change anything, write down what you actually have. This is a data audit (a structured review of your sources, definitions and processes), and you can do the first pass yourself in a day or two. Work through the list below and keep the answers in one document. The point is not to fix as you go; it is to see the whole picture before you decide.
What the inventory tells you
The inventory will be long. A shortlist is what you act on.
Read back through your notes and pull out the distinct problems: the causes, not the symptoms. “Sales and Finance disagree on revenue” is a symptom; “revenue has no agreed definition” is a finding. “The monthly report takes three days” is a symptom; “the report is rebuilt by hand from five separate exports” is a finding. Aim for a single page: five to ten findings, each written as a plain statement of what is wrong.
Group them as you go. Most findings fall into a few buckets: definitions (the same word means different things), identity (the same entity appears as several records), quality (data is wrong or missing), process (too much is done by hand), and ownership (no one is responsible). The shape of the buckets tells you something on its own. If half your findings are identity problems, that is your foundation, and no amount of dashboard work will paper over it.
Some findings point at larger questions. A recurring “we cannot join across systems” is really a question about whether you need a data warehouse; a run of “no one owns this” is a question about whether you need a data team. Note those and move on. They are decisions for later. Do not let them stall the shortlist.
How to prioritise: impact × effort
With a shortlist in hand, prioritisation becomes a scoring exercise rather than an argument.
Score each finding two ways. Impact is how much the problem blocks or distorts a real decision. A wrong revenue definition that misleads the board scores high; a cosmetic label on an internal chart scores low. Effort is what the fix will cost you: time, technical risk, and dependencies on other work or other teams. A fix that needs three systems changed at once is high-effort even when each change is small.
Plot the findings on an impact × effort grid: impact up the side, effort along the bottom. Four regions appear. High impact and low effort are quick wins; do them first. High impact and high effort are major projects: worth doing, but plan and sequence them. Low impact and low effort are fill-ins, to do when you have a spare hour. Low impact and high effort are thankless; leave them.
Then adjust for sequence, because some fixes make later fixes cheaper. This is where foundational work earns its place. Agreeing definitions and resolving identity are often only medium-impact on their own, but they act as multipliers: once a metric is defined once, and once a customer is one entity everywhere, half of your quality and reconciliation findings become easy. Fixing the dashboard is a surface fix. It belongs after the definitions it displays are trustworthy, not before. Lineage and ownership are multipliers too: a fix with clear lineage is safe to make, and a fix with a named owner is the only kind that stays fixed.
One cheap check often earns a place near the top of the list: how fresh is each source, really? You can answer it in a single query that reads the newest record each source holds:
-- illustrative: how fresh is each source, really?SELECT 'crm' AS source, MAX(updated_at) AS last_updated FROM crm.accountsUNION ALLSELECT 'billing' AS source, MAX(updated_at) FROM billing.invoicesUNION ALLSELECT 'product' AS source, MAX(event_time) FROM product.eventsORDER BY last_updated; -- oldest source firstRead oldest-first, this lists each source next to the last time it changed. A table that should refresh nightly but last moved a week ago is a finding you can act on straight away — and a cheap one.
What good looks like
You do not need a finished data platform to be in good shape. You need a clear head about what to do next. After a diagnostic, that comes down to four things.
- A scored shortlist. Five to ten findings, each with an impact score, an effort score and a one-line note on why it matters. Anyone can read it and follow the reasoning.
- An agreed sequence. The findings are ordered, and the order is deliberate: foundational fixes first, surface fixes after the foundations they depend on. Everyone has seen the sequence, so no one is quietly working on item seven.
- A named owner for each item. Not a team — a person, accountable for the fix landing and staying landed.
- A first fix that unlocks the rest. The top of the list is not the loudest complaint; it is the change that makes the next few cheaper. Often that is a single agreed definition, or one reliable customer identifier.
When the first fix is done, the next problems should look smaller than they did — which is exactly the sign you sequenced it right.
Common ways this goes wrong
The failure modes are predictable, and each one feels productive at the time.
- Buying a tool first. A new dashboard, warehouse or catalogue does not decide what your numbers mean. Bought before the diagnostic, it becomes an expensive way to display the same distrusted figures.
- Fixing the loudest complaint. The problem someone shouts about is rarely the root cause. Fix the symptom and it returns, because the cause upstream is untouched.
- Trying to fix everything at once. Effort spreads across ten fronts, nothing finishes, and the team burns out with little to show. Sequence beats ambition.
- Leaving no owner. A fix with no named owner drifts back to broken within weeks. “The data team” is not an owner; a person is.
- Rebuilding dashboards on weak foundations. Polishing the reporting layer while the definitions and identity beneath it are still wrong only produces prettier disagreements.
When to bring in help
Much of a diagnostic is work you can and should do yourself. You know your business better than any outsider. Running the inventory in-house is valuable even if you never bring anyone in, because it forces the questions into the open. But there is a point where the honest answer is that this has outgrown a spare-time effort. It is usually less about any single problem and more about scope, recurrence and ownership: the issues cross too many systems to hold in one head, the same faults keep returning, and no one has the time or the specific skills to fix them and keep them fixed.
A decision guide
When you are unsure what to do with a finding, place it on the grid and read across the row.
| Quadrant | Impact | Effort | Typical example | What to do |
|---|---|---|---|---|
| Quick wins | High | Low | One agreed definition; a single reliable customer identifier | Start here: this is your first fix |
| Major projects | High | High | A warehouse; a full identity-resolution system | Plan and sequence; do after the quick wins |
| Fill-ins | Low | Low | A relabelled chart; a small tidy-up | Do when you have spare capacity |
| Thankless | Low | High | Perfecting a report almost no one reads | Leave it: the cost outweighs the value |
The order that falls out of this is nearly always the same: fix the foundations that others depend on, take the quick wins that build confidence, and only then decide whether the major projects (a warehouse, a permanent team) are genuinely warranted. Start with the change that makes the next three easier, and the messy setup stops feeling like one impossible problem and starts behaving like a short, ordered list.