Most data projects do not fail in the first month. They fail quietly in the third, once the interesting technical work is done and the organisation has to change how it behaves.
The pattern is remarkably consistent across sectors, and the cause is almost never the platform.
Month one is a honeymoon
The first few weeks go well because nobodyu2019s habits have been disturbed. A small team scopes the work, gathers requirements, connects a few sources and produces something that looks like progress. Everyone agrees the project is going well.
What is actually happening is that the project has not yet asked anyone to do anything differently.
Month three is where it breaks
By the third month the tooling exists. Now it has to compete with the spreadsheet people already trust, the meeting that already happens on Tuesdays, and the reporting deadline that arrives regardless of whether the new pipeline is ready.
Three failures show up again and again.
No one owns the number. A dashboard goes live with twelve metrics. Nobody is accountable for whether they are right, so when two of them disagree with the finance pack, the dashboard loses its authority in a single afternoon and never gets it back.
The data is technically available and practically unusable. The pipeline runs. But "customer", "revenue" and "active" were never defined, so each team reads the same column differently and the argument moves from the meeting to Slack.
Success was never written down. The project was justified with a vague promise about better decisions. In month three, when someone asks what it delivered, there is nothing to point at — so the budget goes somewhere that can demonstrate a number.
What actually works
Start from the decision, not the data. Before anything is built, name the specific decision the work should improve, who makes it, how often, and what they look at today. If nobody can answer that, you do not have an analytics project yet. You have a research problem, and it is cheaper to solve it in a workshop than in a warehouse.
Assign an owner for every published metric, before launch. Not a data steward — an actual person in the business who will defend the number when it is challenged. This single change prevents more dashboard failures than any tooling decision.
Define the vocabulary in writing. One page. What counts as a customer, what counts as revenue, what "active" means. It will feel like an unnecessary formality for about a week, and then it will save you a quarter.
Ship something small that changes one decision in the first six weeks. Not a pilot of the eventual platform — a finished thing that a named person uses. Momentum comes from a visible win, not from a roadmap.
The uncomfortable part
The reason month three is where projects stall is that it is the point where the work stops being an engineering problem and becomes a management problem. Engineering problems have owners, deadlines and clear completion criteria. Management problems have habits, incentives and meetings that have been running since before you arrived.
The teams that get through it are the ones that planned for that transition rather than discovering it.