Why every attempt to fix it fails (and why the problem comes back)

If you read the previous article in this series, you know that mismatched numbers across teams usually come from three sources: no shared IDs across systems, no agreed definitions, and no record of who changed what.

Most companies know something is wrong. Most have tried to fix it. A new report gets built. A cleanup project runs. A new system gets bought. The numbers look better. Leadership stops arguing in meetings. Then, gradually, the drift returns. Within a year, sometimes within months, the same meeting is happening again.

I've watched this cycle repeat enough times to recognize its stages. Here's what's actually going on.

flowchart LR
    P["🔴 Numbers\ndon't match"]

    P --> A["Buy a dashboard"]
    A --> B["Looks better\nfor a while"]
    B --> C["Teams argue\nwith dashboard\ninstead of each other"]
    C --> P

    P --> D["Run a cleanup\nsprint"]
    D --> E["Data is cleaner"]
    E --> F["New dirty data\nflows in weekly"]
    F --> P

    P --> G["Big migration\nproject"]
    G --> H["New system\nlaunched"]
    H --> I["Same habits\nsame definitions\nnew tool"]
    I --> P

The dashboard trap

The most common first response to mismatched numbers is to build a better dashboard. Buy a BI tool, hire someone to set it up, point it at the existing data sources. For a while, this seems to work. Everyone looks at the same screen, there's a shared reference point, the arguments in meetings have less room to escalate.

The problem is that a dashboard is downstream of everything. It reads from the same systems where the real problems live. If sales and finance are measuring headcount differently in those systems, the dashboard picks one definition and displays it. Whichever team's definition wasn't chosen now argues with the dashboard instead of with each other.

Worse, when the dashboard shows a number that doesn't match what a team was reporting before, they lose trust in it. The dashboard gets labeled as inaccurate. Teams go back to their own reports. The shared reference point stops being shared.

A dashboard built on disagreed-upon sources doesn't resolve the disagreement. It just makes it visible on a bigger screen.

The cleanup project that doesn't stick

The second common response is a data cleanup project. Someone in operations or IT spends weeks deduplicating records, standardizing field names, removing obvious errors. At the end, the data is measurably cleaner. The reports look better. There's a genuine sense of progress.

Six months later, it's dirty again.

This happens because cleanup treats the output without touching the input. The processes that created the dirty data are still running. The form fields that let people type client names however they want are still there. The manual handoff between systems is still happening by copy-paste. The new records coming in every week are following the old patterns.

Every week of normal business operations adds new imperfect data to a dataset that was cleaned last quarter. The cleanup has a half-life.

The definitions conversation that never happened

One thing I notice consistently when I start working with a company is that the core definitions were never formally agreed upon. What does "active client" mean? What counts as revenue? When does a placement become official? Each team has assumed that everyone else means the same thing they mean. They don't.

When someone proposes a fix, that conversation still often doesn't happen, because it's uncomfortable. It surfaces real disagreements. Sales doesn't want to give up counting signed seats as their headline number, because that's what they're measured on. Finance insists on billed revenue because that's what affects the books. Getting everyone to agree on a single definition for "revenue" means someone has to accept that their number changes, and usually not upward.

So the fix gets implemented without resolving the definitions. The new dashboard, the new system, the new report inherits the ambiguity. Within a few months, the same teams are producing the same different numbers and pointing at the new tool as the problem.

The big-bang project

Every few years, there's a moment where leadership decides to solve this once and for all: a full CRM migration, a data warehouse build, a company-wide BI rollout. These projects are usually well-intentioned and often technically sound.

They also rarely solve the problem they were meant to solve.

The reason is time and momentum. A six-month project has six months of organizational energy. After it launches, the team moves on to other priorities. The consultants who built it leave. The internal champion who drove the project gets promoted or changes roles. The new system was scoped based on how the company worked at kickoff, not how it works at launch after six months of normal growth and change.

And the new system was populated by the same people with the same habits. If the definitions work wasn't done first, the new tool reproduces the old patterns. Within a year, the new CRM has the same inconsistencies the old one had. The data warehouse has clean infrastructure and confused metrics.

Nobody owns the handoffs

There's a structural gap that almost every company has and almost nobody has named. The CRM has an owner. The ATS has an owner. The payroll system has an owner. But the record that connects a client in the CRM to a placement in the ATS to a row in the payroll system lives in the handoff between systems, and handoffs don't have owners.

When something goes wrong in a handoff, each team checks their own system, confirms their data is correct, and points at the next team. Each team is right about their own system. The problem lives in between them, and no one's job description includes fixing it.

This isn't a failure of individual responsibility. It's a structural gap: no one was ever assigned to own the connection. A fix that doesn't include assigning those owners will drift back to the same state.

Why it drains the organization more than people realize

There's a cost to data problems that rarely appears on any report. Every time a number doesn't match, someone has to investigate. Usually several people, from several teams, spending time they didn't plan to spend. They pull exports, compare spreadsheets, trace back through version history. Sometimes they find an explanation. Sometimes they don't, and the meeting ends with a number that everyone silently treats as approximate.

Multiply that by every weekly review, every planning cycle, every board update, every client report. The hours are real. But because the cost is spread across many people doing small annoying tasks, an extra hour here, a reconciliation effort there, it never appears as a line item. It's invisible until someone actually counts it up.

The other cost is trust. Over months and years, leadership stops trusting internal reports and starts asking people directly for numbers. The person asked asks someone else. Eventually someone builds a new spreadsheet to track the thing the dashboard doesn't get right. The spreadsheet becomes the source of truth. The cycle starts again from the beginning.

Why the problem comes back even after genuine fixes

The deepest reason the problem is so persistent is that the business keeps changing, and definitions have a shelf life.

A company that agreed on "active client" in year two means something different by year four, because the product changed, the sales motion changed, the client mix changed. A definition that was precise and correct when it was written becomes ambiguous as the business evolves around it. If nobody is responsible for maintaining and updating definitions, they silently go stale.

A one-time fix produces correct data for the business as it was when the fix was implemented, not for the business as it is now. Six months later, the definition has drifted from the reality, and the numbers start to diverge again.

This is why data consistency feels unfinishable to most companies. It's not a project with a completion date. It's an ongoing practice that has to keep pace with how the business changes. Most companies treat it like a project and are frustrated when the results don't last.

The last article in this series is about what the practice actually looks like, and the honest answer to what "good enough" means.