The dashboard was live. Dayforce, Workday, and our real-time fleet reservation data - all unified in one view, updated automatically, accessible from any browser. I'd eliminated the 7am manual exports. I'd removed three separate Excel files that two people had been maintaining by hand every week for years.
I was proud of it. Then I walked past the operations director's office three weeks into the rollout.
He was in Excel.
I stopped and asked him about it. He said the dashboard was great - he just wasn't sure he trusted the Dayforce numbers since they'd looked a little off that first week. Just once. One number that didn't match what he expected. That was enough.
I'd spent months on the technical work and about two hours on the adoption plan. That ratio was the problem.
BI implementations fail at a rate that should embarrass the industry. Research consistently shows that a significant portion of BI and analytics projects deliver far below their expected value - not because the technology failed, but because nobody figured out how to change organizational behavior around the technology.
The conventional diagnosis is usually "data quality issues" or "poor requirements gathering." Those are real problems, but they're not the primary failure mode I've seen in practice. The primary failure mode is simpler: organizations treat BI rollout as a technology project when it's actually a change management initiative.
A technology project has a finish line. You build the thing, you deploy it, you declare success. A change management initiative has a finish line that looks completely different: the moment a leader stops reaching for their old habit and reaches for the new tool instead. That moment doesn't happen on launch day. It doesn't happen after a training session. It happens after weeks of deliberate reinforcement - and it requires a plan that most BI projects never write.
At the $89M fleet operation where I built this dashboard, we had genuinely good data, a clean data model, and a well-designed interface. The failure wasn't technical. It was that I shipped a solution to a problem I'd defined from the data side, not from the decision side.
This distinction is the most important thing I've learned in eight-plus years of building operational analytics.
A report tells you what happened. It answers "how did we do?" It's backwards-looking, and its primary audience is someone who needs to understand past performance - whether for accountability, documentation, or historical trend analysis. Reports are valuable. But they are not decision-making tools.
Decision-making infrastructure answers a different question: what should I do next? It's designed around a specific decision that a specific person needs to make at a specific moment in the week. It gives them the exact information required to act - nothing more, nothing less.
The difference isn't in the technology. You can build both with Power BI. The difference is in the design intent, and it changes everything about how you scope the project.
When I built the initial dashboard at Enterprise Mobility, I designed it from the data out. I had Dayforce for workforce data, Workday for HR, and a proprietary reservation system for fleet utilization. What could I connect? What could I show in a single view? The result was comprehensive - and overwhelming. I'd given leadership access to everything we tracked, which turns out to be not particularly useful.
When I redesigned it six weeks later, I started from a different question: what decision does our operations director make every Monday morning, and what does he need to make it well? The answer was specific - utilization rates by location, overtime flags for the coming week, staffing gaps versus projected demand. That's it. The dashboard shrank by two-thirds. Usage went from twice a week to every single workday.
The operations director's Excel moment forced me to stop and diagnose what had actually gone wrong. I identified three specific failures in my rollout approach and fixed each one.
I stopped waiting on data trust and started actively building it. The Dayforce inconsistency in week one should have triggered a full stop. Instead, I kept building features while leadership quietly formed their opinion about whether the data was reliable. Trust in a data source is built in the first two weeks or not at all. If a leader sees one number that doesn't match their mental model, they'll never fully trust the dashboard - not without a deliberate effort to explain the discrepancy and demonstrate consistency over time. When I integrated Dayforce and Workday into a unified view, I should have spent the first two weeks doing nothing but reconciliation - proving that the dashboard agreed with what they already knew before introducing anything new.
I embedded the dashboard into existing decision moments before asking anyone to self-serve. Sending a link and scheduling a training call is not an adoption plan. People have existing habits and existing meetings where decisions get made. If the new tool isn't in those meetings, it won't get used. I started bringing the dashboard up in the Monday ops review myself - walking through it with leadership rather than waiting for them to open it independently. Over about three weeks, it became the standard reference point. Then, and only then, did people start opening it on their own.
I rebuilt the dashboard around decisions, not data availability. The comprehensive view went away. In its place, I created separate dashboards for separate decision moments: a Monday staffing view, a weekly utilization report, a monthly P&L-adjacent cost analysis. Each one answered one set of questions for one audience. The irony is that scoping down the dashboard made it dramatically more useful - because now it was solving a real problem rather than displaying a data catalog.
The specific steps I took were tuned to our operation, but the underlying pattern is universal.
Before you build anything, identify the decision. Not the report. The actual choice a specific person needs to make - and when they make it. Every design decision flows from there: what data do you need, what's the right cadence, who's the audience, what does the interface need to look like to be self-evident in a two-minute meeting review?
Before you launch, establish trust in the numbers. Run the dashboard in parallel with existing reports for two to four weeks. When the numbers match, say so explicitly. When they don't, explain why. The goal is for leadership to have already decided they trust the data before the old process is retired - not after.
Before you celebrate usage, check what kind of usage you have. Passive views in a weekly email blast are not the same as active interrogation during decision moments. The measure of BI success isn't whether people opened the dashboard - it's whether the dashboard changed what they decided.
If you're in a nonprofit context, this matters even more. The resources that go into a BI implementation are often grant-funded and difficult to replace. A $15K investment in Tableau or Power BI that sits unused isn't just a technical failure - it's a missed opportunity to measure and communicate program impact, which is the thing every nonprofit board and funders want to see. The change management cost is usually zero dollars, just time. It's always the piece that gets cut.
I spent three months building something that took me three weeks to recover from deploying badly.
The technical work mattered. The data modeling, the API integrations, the performance optimization - all of that was real and necessary. But none of it determined whether the project succeeded. What determined success was whether I understood how leaders actually made decisions, and whether I built the adoption process that moved them from their old habits to the new infrastructure.
BI done right doesn't look like a technology project. It looks like a quiet organizational transformation where, six months in, nobody can remember how they made decisions before the dashboard existed.
That's the goal. Start there and work backwards.