There is a familiar pattern to data projects that do not make it. The kickoff is energetic. A data scientist produces a promising notebook within a fortnight. Everyone is encouraged. Then the project spends the next eight months not shipping, and eventually stops being mentioned in status meetings.
The model was never the problem. In almost every case, the failure was decided before any modelling began.
Nobody agreed what the number means
Ask four departments to define "active customer" and you will get four answers. Sales counts anyone who has ever transacted. Finance counts anyone billed this quarter. Support counts anyone with an open ticket. Marketing has a definition involving email engagement that nobody else has heard of.
None of them are wrong. But until one definition is written down and owned, every report will disagree with every other report, and the organisation will spend its meetings arguing about whose number is right rather than what to do about it.
Fix this first, before any pipeline is built. Write the definitions down, name an owner for each metric, and put them somewhere visible. It is unglamorous work that saves months.
The data was never as available as promised
The discovery workshop establishes that the required data "exists in the CRM". It does. It also exists in three CSV exports, a legacy system nobody has credentials for, and — for anything before 2022 — only in a spreadsheet maintained by someone who left last year.
Before committing to a modelling timeline, get actual read access to actual data and look at it. Not a sample someone prepared. The real thing, with the nulls, the duplicate records, the free-text field where a dropdown should have been, and the eighteen-month gap where the export job was silently failing.
We build a one-week data readiness assessment into the front of every engagement for exactly this reason. It has changed the scope of more projects than any other single activity, and always in the direction of realism.
The pipeline was treated as plumbing
Data engineering is consistently under-resourced because it is invisible when it works. So the ingestion is built quickly, without tests, without idempotency, without monitoring — and then it becomes the thing that breaks every second week.
Pipelines need the same engineering discipline as any other production system: tests on the transformations, freshness contracts that alert when data stops arriving, idempotent processing so a re-run is safe, and lineage so that when a number looks wrong you can trace exactly where it came from.
A team that can answer "where did this figure come from" in two minutes rather than two days moves at a completely different speed.
No one owned the decision the model was meant to inform
This is the quiet killer. A model gets built, validated, and deployed, and then nothing changes — because no process was ever redesigned around its output.
A churn model that identifies at-risk customers is worth precisely nothing if no team has the mandate, the capacity or the playbook to act on the list. The modelling was the easy 20%. The organisational change was the other 80%, and it was never scoped.
Before a project starts, we ask a simple question: when this system produces its output, who does what differently? If nobody can answer with a specific person and a specific action, the project is not ready — no matter how clean the data is.
What we do differently now
Four things, applied to every data engagement:
- Define the decision first. Start from the action the business will take, then work backwards to the data required. Not the other way around.
- Assess data readiness before estimating. One week, real access, honest findings — even when the finding is that the project is not currently feasible.
- Build the pipeline as a product. Tested, monitored, documented, with a named owner.
- Ship the smallest useful thing. A well-defined dashboard that three people genuinely use every morning beats a sophisticated model nobody has integrated into a workflow.
None of this is technically difficult. It is mostly a matter of resisting the pull toward the interesting part of the problem before the boring parts are solid.
Planning a data or AI initiative? Talk to our data team about a readiness assessment before you commit to a delivery timeline.