Why Your Data Project Stalled (And What to Ask For Instead)

Quick answer

Why Your Data Project Stalled (And What to Ask For Instead) explains what the change means for UK SMEs and how to turn it into a practical next step. The process is to identify the business decision, connect the data, then automate only the parts that improve speed or reliability.

You signed off a data project. Maybe it was a cleanup, a new reporting layer, a governance initiative, or the data groundwork ahead of an AI push.

Months later, you're not sure what you got for the money.

The reports look tidier. Someone showed you a dashboard. But inventory hasn't moved, the forecast is still wrong often enough to hurt, and the thing you actually wanted, the business running better, hasn't happened.

You're not imagining it, and it probably wasn't bad luck. It's how most data projects are sold.

The foundations problem

Think about a house extension.

You buy a bigger kitchen. The island, the bifold doors, the space the family actually lives in. That's what you're paying for and that's what you can see.

The builder knows the real work is somewhere else. Foundations, drainage, steelwork, load calculations. None of it shows up in the photos. You never asked for foundations. But get them wrong and the kitchen cracks, floods, or falls down.

Data works the same way. The trouble starts when the project gets sold to you as foundations.

Nobody should be selling you "data quality"

If a data project was pitched to you on the strength of data quality, governance, master data, golden records, lineage, that was the first warning sign.

Not because those things don't matter. They're the foundations, and they're essential. But they're the mechanism, not the point. Leading with them is like a builder selling you drainage instead of a kitchen.

What you actually wanted was some combination of:

• Faster service
• Lower inventory
• Less downtime
• Better forecasting
• Higher sales
• Reporting you can trust
• AI that actually works

When a project is organised around data quality for its own sake, it drifts toward cleaning everything to a standard nobody needs. You end up with a beautifully accurate dataset that doesn't move a single number that matters. That's why it stalled. The work was never anchored to an outcome you cared about.

What good looks like instead

The fix isn't more rigour on the foundations. It's starting from the other end.

A project that's going to pay back starts with a number. "Cut inventory by 10%." "Halve the time it takes to close the month." "Get the forecast reliable enough to plan production around."

That outcome tells everyone exactly which data has to be trusted, to what standard, and crucially where good-enough is genuinely good enough. You fix the foundations under the extension, not under the whole garden.

The builder doesn't pour concrete under the entire plot. They pour it where the kitchen is going. Your data work should be exactly that targeted.

What to ask for

If you're about to commission data work, or you're trying to work out why the last lot didn't land, these are the questions that cut through it:

• What business number will this move, and by how much? If the answer is about data rather than the business, stop there.
• How will we know it worked? There should be a before and an after you can actually see in the operation, not just in a dashboard.
• What are we deliberately not fixing? A good answer here is a sign someone is being targeted rather than boiling the ocean.
• What's the shortest path to the first visible result? You want momentum in weeks, not a twelve-month foundations project with a reveal at the end.

If whoever's pitching can answer those clearly, you're in good hands. If every answer routes back to data quality as the goal, you're buying drainage and hoping a kitchen appears.

The short version

You don't want data quality. You never did. You want the business to run better, and data quality is just one of the foundations that makes that possible.

Buy the kitchen. Make sure someone competent is quietly handling the foundations underneath. And judge the result by whether the business actually changed, not by how clean the data looks.