When a previous data project failed, the instinct is usually to ask what tool was wrong or which vendor underdelivered. Sometimes that matters. More often the deeper issue is simpler: the project was too broad, too abstract, or too far from the operational decision it was supposed to improve.
That is why second attempts go wrong too. Companies restart with another big programme, another vague brief, and another promise to fix the whole estate. The shape changes. The failure pattern stays familiar.
Failure mode 1: scope without foundation
A lot of projects start at the impressive end of the stack: dashboards, automation, AI layers, unified views across everything. But if the underlying data is undefined, disconnected, or untrusted, the output becomes harder to use rather than easier. The project looks ambitious and lands as shelfware.
This is usually a scoping problem disguised as a technical one. The business asked for something large before proving one narrow use case end to end.
Failure mode 2: people and process were ignored
Projects also fail when the build assumes the data issue is purely technical. Different teams define metrics differently. Nobody agrees who owns exceptions. The workflow around the new output is unclear. So even if the system works technically, the organisation does not absorb it.
If the people using the output do not trust it, cannot review it, or do not know how it fits the operating rhythm, the project has not really shipped.
Failure mode 3: vendor or platform mismatch
Some teams bought a platform when what they needed was a working use case. Others bought consulting theatre when what they needed was a builder. The mismatch is not philosophical. It is commercial. You paid for general capability when the real requirement was one concrete output on real data.
That is why broad transformation language often sounds impressive and delivers very little. The problem definition was vague, so the delivery stayed vague too.
What to do differently now
Do not restart with another broad programme. Restart with one decision that still hurts. One disputed revenue view. One monthly reporting bottleneck. One duplicate-customer problem affecting account ownership. One use case where a working output would immediately change the conversation.
That is the Lucendata model: one use case, real data, fixed scope, working output, and a production path if the proof is there. Mini PoW first. Core build next if it works. Intelligence later when the foundation deserves it.
The anti-big-bang move is simple: do not fund another abstract clean-up. Fund one Mini PoW on the decision that still causes pain, and use that proof to decide whether a larger build is worth it.
If your last data project failed, the safest next step is not more theory. It is one fixed-scope proof on the operational output you still need.