The pattern is remarkably consistent. A business intelligence project gets signed off. A team is assembled — or a consultant is hired. Over several weeks or months, dashboards are built, data is connected, a launch date is set. The presentation to leadership goes well. The dashboard looks good. The numbers are right.
Six months later, nobody opens it.
This isn't a rare outcome. It's the most common one. And the failure is almost never technical. The data was connected correctly. The dashboards rendered properly. The platform worked exactly as designed.
The problem was somewhere else — usually somewhere much earlier in the process than anyone wants to admit.
The question that doesn't get asked
Most BI projects start with a tool selection. The business decides it needs Power BI, or Tableau, or Looker, or some other platform. The conversation is about licensing, about IT requirements, about which team will own it. It's a procurement conversation masquerading as a strategy conversation.
The question that rarely gets asked — or gets asked too late — is: what decision are we trying to make better? Not "what data do we want to see?" Not "what reports do we currently run?" But: what choice, made by which person, on what cadence, would be meaningfully improved if they had better information?
That's a harder question. It requires talking to the people who will actually use the output. It requires understanding how decisions get made in the organisation, not just how data gets generated. It's slower to answer than "which tool should we buy?" And because it's slower, it often gets skipped.
The three patterns we see most often
Built for the requester, not the user. The dashboard was designed based on what someone in IT or analytics thought the business needed. The people who were supposed to use it were consulted briefly, or not at all. The result looks comprehensive but doesn't match how anyone actually works. The sales team wanted to see pipeline by rep. They got pipeline by product. Close.
Too many metrics, too little signal. The fear of leaving something out produces dashboards with 40 KPIs on a single page. Nobody knows where to look. The important numbers are buried next to the unimportant ones. Over time, people stop looking at the dashboard and go back to asking the analyst directly — which defeats the entire purpose.
No ownership after launch. The project team disbands. The consultant leaves. The dashboard is handed over to an IT team that knows how to keep the lights on but doesn't know what the business does with the output. When something breaks, nobody knows who to call. When the business changes and the dashboard needs to change with it, the process for doing that is unclear. Slowly, the dashboard becomes out of date. Then it becomes wrong. Then it becomes unused.
What actually works
The BI projects that stick share a few things in common. They're built around a specific decision — not a general need for "visibility." They're designed with the end user in front of you, not the project sponsor. And they're small enough to be done well before they grow.
The best BI projects we've been involved with started with a single question: what's the one thing you wish you knew every Monday morning? Build that. Get it right. Let people use it, trust it, build habits around it. Then ask what's next.
This sounds obvious, but it runs against the instinct of most organisations, which want to solve everything at once. The comprehensive data platform, the single source of truth for the entire business — these are good long-term goals. They're terrible starting points. They take too long, cost too much, and by the time they're done, the business has changed and the requirements have shifted.
The role of adoption
Adoption is treated as an afterthought in most BI projects. A training session gets scheduled. A guide gets written. An announcement goes out. Then the expectation is that people will use the thing.
They won't, unless using it is easier than not using it. Unless the dashboard is where they're already looking. Unless the numbers it shows are the same numbers they use in their weekly meeting. Unless the person who runs that meeting asks questions that can only be answered by looking at the dashboard.
Adoption is designed, not assumed. The most successful BI implementations we've seen are the ones where someone — a leader, a data champion, an enthusiastic finance manager — makes the dashboard part of how the team works. Not by mandating it, but by using it themselves, visibly and consistently, until it becomes the default.
A better way to start
If you're about to start a BI project, or restart one that's stalled, the most useful thing you can do is not pick a tool. It's spend a day with the people who will use the output and ask them: what do you decide, how do you decide it, and what information would make you more confident in that decision?
The answers will probably surprise you. And they'll give you a much clearer brief than anything that comes out of a requirements workshop.
Starting a BI project and want to get it right?
We start with the question, not the tool. Book a free 30-minute call to talk through your data challenge.