There is a version of this meeting happening somewhere in the UK right now. A leadership team approves a reporting project, a dashboard, maybe a whole analytics platform. Budget agreed, team assigned, timeline set. Everyone leaves feeling like progress has been made.
And in a worrying number of cases, the project has already failed. Nobody knows it yet, the failure just hasn’t been built.
I have spent years working on business intelligence projects across organisations of all sizes, and the pattern is remarkably consistent. When a BI project fails, the cause is rarely found in the build. It is found in the decisions made, or skipped, before the build was approved. The data was not broken. The tool was fine. The foundations were never there.
Here is what I keep seeing go wrong upstream, and what I would want any leader to check before signing off the next one.
Nobody can name the business question
The most common gap is also the most basic. The project has a deliverable, a sales dashboard, a finance pack, but no actual question it exists to answer.
Ask the sponsor what the report is for and you get a description of the report. Ask what decision it should improve, whose decision, and what changes when a number moves, and the room goes quiet. That silence is the project’s real status.
Before committing serious time and budget, the test I use is blunt. Does this help us increase revenue, reduce cost, mitigate risk, stay compliant or work more efficiently? Something! It does not need to change the world, even a simple report should be tied to a real outcome and a named audience. If it cannot be, you are about to fund something that looks great and delivers very little.
Someone once asked me whether digging into purpose this hard was against my own interests. What if you realise the report is not needed, is that not less work for you? It made me laugh, but honestly… if that is the outcome, value has already been delivered. No report is better than a pointless one. The time, the spend and the attention go somewhere that matters instead.
The technology becomes the star of the show
The second upstream failure is treating the tech as the goal rather than the enabler.
I do get it. New tools, new features, the latest capability in the Microsoft stack, it is all genuinely exciting, and right now AI has made this worse rather than better. I see projects being scoped today where “add AI” is doing the job that a business case used to do. The purpose question gets skipped faster than ever because the technology feels like the purpose. It is not. An AI feature on top of a report nobody needed is still a report nobody needed, it just cost more.
The contrast shows up in how requirements are gathered. The tech-first version asks users what they want to see and how they want to see it, then builds exactly that, and the business looks at the result and asks how it helps them hit their objectives. The business-first version starts with different questions entirely. Where are you trying to go? How do you know if you are moving towards it? If a figure turns red, what is the likely cause, and what action can you take? Notice, no tech talk. The technology choices come later, and they are easier, because by then everyone knows what the solution is for.
The wrong people were in the room
Then there is the question of who actually shaped the project. In my experience this is one of the biggest reasons reporting projects fall apart, and it is decided entirely before build.
Requirements often come from people speaking on behalf of the end users. The reasons sound sensible, the users are too busy, too junior, too hard to schedule. But the people acting as proxies usually do not live the day to day, so the solution gets built on a high-level view of work rather than the work itself.
And it costs more than accuracy. It costs trust. I have lost count of the conversations where someone tells me their users do not trust the data or the tool, and when I dig in, the users were never brought into the process. I remember one UK organisation where a new reporting platform faced huge pushback, and everyone had decided the users were simply wedded to the old tool. When I actually sat with them, the real issue surfaced, they believed the new platform could not do what their old one could. It could. The conversation just had not been had.
This is also, frankly, where outside help earns its keep or does not. When organisations bring in a Power BI consultancy UK businesses should expect diagnosis before delivery, someone who insists on meeting the real audience, asks why the report is needed and is comfortable challenging the initial request. A partner who takes the brief at face value and starts building is not saving you time. They are laminating the upstream failure.
Nobody planned for the day after go-live
The last pre-build failure is the one that shows up latest. The project plan runs to launch and stops. Publish the report, tick the box, move on.
But adoption does not happen automatically, it has to be planned like any other part of the initiative, and the planning belongs at the start. Who supports users after launch? Who owns the content, the definitions, the answers when questions come in? Microsoft’s own guidance on content ownership and management treats this as a core adoption decision, not an afterthought, and I would go further. If nobody can tell you who owns the solution twelve months after go-live, the go-live is the end of the project, not the start of the value.
The organisations that get this right make launch a moment, walk users through what support looks like, and carve out actual time for training rather than expecting people to figure it out around their day jobs. None of that is expensive compared to the build. All of it is decided before the build begins.
Summary
It is easy to read a failed BI project as a technical story, wrong tool, bad data, weak dashboards. Sometimes it is. But far more often the failure was upstream, no clear question, technology (and increasingly AI) treated as the purpose, the real users never in the room, and no plan for the day after launch.
The uncomfortable part for leaders is that every one of those failures happens in meetings they sit in. The encouraging part is the same thing. The cheapest moment to rescue a BI project is before anyone builds anything. Ask what question it answers, who will use it and who owns it afterwards. If those answers come easily, build with confidence. If they do not, the pause is not a delay. It is the project working.