A BI project can succeed technically and still fail in practice. Dashboards refresh on time, yet the business continues to rely on Excel because users do not trust the central system.
In my experience, this happens when BI is treated as a reporting project instead of a broader organisational change. Shared metric definitions are necessary, but they are rarely enough. Successful adoption may also require redesigning processes, revising KPIs, reallocating ownership, and changing the organisational structure.
I see this most clearly in commercial organisations, where reporting expands faster than the organisation’s data culture and operating model can adapt. In one B2B company of more than 70 people, reporting was spread across more than 50 spreadsheets.
The CRM was not a reliable source because the surrounding processes and ways of working were inconsistent across the organisation. Until those differences were resolved, no BI system could produce a figure that everyone trusted.
Start with definitions, not dashboards
When reporting is inconsistent, I begin by tracing each important metric back to a business decision. I ask what the metric represents and when it should be recorded. I also identify who owns the definition. This exposes disagreements before they become technical requirements.
A company may appear to have a reporting problem when it has a decision problem. Some managers may count a deal as a sale when the invoice is issued, while others wait until payment reaches the bank account.
That difference affects reported performance and may change bonus calculations. A dashboard cannot resolve the conflict by choosing one formula without business rules defined.
Before anything is built in Power BI, I work with the relevant owners to define and document the data rules. The group establishes a shared methodology for metrics and data handling.
This may cover how a figure is calculated and when incoming data is complete enough to be finalised. It can also set rules for resolving discrepancies between systems. Once a definition enters the BI model, I treat it as an operational rule.
Understand why users stay in Excel
Resistance to BI is often rational. A spreadsheet gives its owner control because the structure is familiar and every formula can be checked. It also allows exceptions to be inserted by hand. A central dashboard removes some of that freedom, which can feel like a loss of control.
When users reject a BI figure, I do not assume that they are resisting change. Sometimes they cannot trace the calculation and need more transparency. In other cases, they disagree with the rule behind the number. These problems require different responses, so I identify the source of the objection before making changes to the report.
If the concern is traceability, I make the calculation path visible. If the disagreement concerns the metric itself, I return the issue to the relevant owner. This prevents a technical discussion from hiding an unresolved business conflict. It also gives users a clearer reason to rely on the system.
Build dashboards around decisions
A dashboard should support a management question or an operational action. I reject reports that display information without helping someone decide what to do next. This keeps the project focused on business use. Without a defined use case, a dashboard becomes a static archive.
In one programme, the reporting system covers ten sales and marketing funnels. It also includes KPI calculations and marketing ROI. Each report has a defined purpose before development begins. I ask who will use it and what decision it should support.
This approach prevents the BI backlog from filling with low-value requests. A visually polished report can still make no difference to how the business operates. I prefer a smaller set of dashboards that people use in recurring decisions. That gives the system a clear role inside the operating model.
Move reporting knowledge closer to the business
Hiring more BI developers does not always remove the real bottleneck. A developer who supports several business units cannot build a deep understanding of each one. Requests from different teams also split their attention, while the business has to spend significant time preparing detailed specifications.
Even then, the report may go through repeated revisions as new requirements emerge, creating a loop with no clear endpoint. This consumes significant time from both BI developers and business stakeholders. When BI developers do not challenge requests or clarify whether a report is truly needed, companies can end up spending more on reporting while producing outputs that deliver limited business value.
I often find that routine reporting is better handled by analysts embedded in commercial teams, such as sales or marketing analysts. Here, the term does not refer to IT business analysts who work with developers. An analyst embedded in a given area already understands its products and potential data problems.
Teaching that person BI is often easier than teaching the full commercial model to every BI developer. With all the business context, an analyst will identify a data problem earlier and trace an incorrect number back to its underlying process.
This changes how the BA and BI functions work together. Analysts handle reporting that depends on business context, while BI developers focus on architecture and platform scalability. In my experience, this is a more efficient and economically viable model because it reduces the time spent on each report and, as a result, lowers the company’s overall reporting costs.
A prerequisite for this model to work effectively is giving the analytics team sufficient authority within the reporting process. In my work, I own the commercial reporting process end to end.
This allows me to use data to recommend broader organisational changes, including updates to business rules, processes, KPIs and team structure. The finding does not remain in an escalation queue while the reporting issue continues. I can bring the relevant owners together and carry the change through.
Build trust through visible decisions
A technically correct report is not automatically trusted. When BI figures differ from legacy spreadsheets, users often defend the files they already know. I investigate each discrepancy instead of treating it as user error. Some differences reveal incorrect CRM usage, while others expose a defect in the BI model.
Admitting a defect can strengthen trust more than defending the system. I make the calculation logic visible and explain how the definition was approved. When a rule changes, I document the decision and apply it through the agreed process. Users then understand that the system is governed.
Management behaviour has the same effect. If leaders continue accepting figures from private spreadsheets, the central system remains optional.
Trust in BI grows when dashboards are used consistently in meetings at every level of the organisation. This requires a clear rule that separate Excel files or privately maintained figures cannot be used as an alternative data source. Consistent use gives employees a reason to stop maintaining parallel calculations.
Measure changes in how the business works
I do not evaluate a BI transformation only by reporting speed. I look at how the system changes decisions and the work around them. Faster delivery has value, but it does not show whether the business trusts the output. The stronger evidence is a visible change in how people use data.
In one programme, 12 manual reports were replaced by three integrated dashboards. Centralised salary calculations saved 35 hours of preparation work and eliminated disputes.
Decisions that had taken days could be made within hours. Team leaders also identified potential problems earlier because shifts in performance became visible during the month.
The operating model changed as well. Managers began correcting CRM issues before month-end instead of waiting for a reporting dispute. Analysts spent less time copying numbers and more time investigating performance changes and growth opportunities. Redesigning the BA and BI functions reduced their costs by 20 percent.
Around 70 people now use the dashboards regularly. Sales managers and team leaders rely on them, while the CEO uses the same system for management decisions. Finance receives fewer urgent requests to reconstruct sales results. Meetings focus more on causes and corrective action than on whose spreadsheet is correct.
This experience shapes how I approach BI work. A company often needs agreement on definitions before it needs another dashboard. It also needs clear ownership behind every important metric. Once those foundations are in place, the technology can support a shared view of the business, not merely adding another layer of reporting.
