Power BI Change Management - The Part Of Adoption Nobody Wants To Pay For

Most of the Power BI projects I've watched go sideways didn't fail because the data model was wrong. They failed because nobody told the people who were meant to use the reports that the reports existed, or what to do with them, or why the old spreadsheet they'd been emailing around for nine years was about to stop being maintained.

Change management is the part of the adoption roadmap that everybody nods at in the kickoff and quietly defunds by month two. It's a shame, because it's the work that decides whether the platform actually gets used or whether you end up with a $400k Fabric tenant that two people in finance look at once a week.

I want to walk through how we approach change management on Power BI rollouts, what the Microsoft adoption roadmap gets right, and the bits we've had to add ourselves to make it stick in Australian organisations. There's a fair bit of ground to cover so I'll try and keep it concrete.

What "change management" actually means in a BI context

People hear change management and they picture a slide deck with butterflies on it. That's not what it is. In a Power BI rollout it's the work that gets done between "we have a working report" and "the people who need this report are using it daily, trusting the numbers, and changing their decisions because of what they see."

That gap is wider than most sponsors think. We did a rollout for a logistics business in Brisbane last year where the data model was clean, the reports were sharp, and the workspace governance was sensible. Six weeks after go-live, fewer than 10% of the intended users had opened a single report. We had to go back in, run a fresh round of workshops, rebuild three reports to match how the operations team actually thought about their work, and run a series of short training sessions in the warehouse rather than over Teams. Adoption went from 10% to about 70% in two months. Nothing about the technology changed.

That's change management. It's the work of moving an organisation from "we have BI" to "we use BI to run the business."

The Microsoft adoption roadmap and what it covers

Microsoft published a chunk of guidance on Power BI change management as part of their Fabric adoption roadmap. It's worth a read if you're a sponsor or a program lead. The original article is here: Power BI change management guidance.

The framing they use is pretty sensible. They break change management into a few categories. Changes to the data culture itself (which is a multi-year effort). Changes to specific business processes (how a team makes a decision now versus how they made it before). Changes to the analytics solutions people use day to day. And changes to people's skills.

What I like about the Microsoft framing is that it separates organisational change from individual change. You can have an executive sponsor pushing top-down cultural change, while a department lead is dealing with the very different problem of three people on their team who refuse to stop using Excel. Both are change management, but the playbooks are different.

What I think the roadmap glosses over is the political work. Most organisations have somebody, usually senior, who has built their authority on owning the numbers. When you put self-service BI in front of the broader business, that authority gets diluted. That person is often not happy about it, even if they say all the right things in the steering committee. A surprising number of Power BI rollouts stall because nobody dealt with that person directly. The roadmap mentions resistance but doesn't really tell you what to do about it.

The patterns we see work

Here's what we've actually seen move the needle, across maybe 40 or 50 Power BI engagements over the last few years.

Start with a specific decision, not a dashboard

The fastest way to get a team using a report is to identify a decision they make weekly or monthly, and build the report around that decision. Not the data, the decision. "We need to decide every Wednesday morning which routes to prioritise for the next week." That's a usable starting point. "We need a dashboard for operations" is not.

The reason this works is that you've now got a defined moment where the report has to be opened. Once that habit is built, you can expand the report's usefulness. But without that anchor moment, the report becomes one more tab nobody clicks.

Run training in person if you can

Teams training works for refresher sessions and for technical audiences. For frontline users it's nowhere near as effective as standing in front of them with a laptop. We've run sessions in factory canteens, hospital meeting rooms, council chambers. The conversion rate from training to actual usage is dramatically higher in person. Don't ask me why, it just is.

If you can't do it in person, do small group sessions of five or six rather than the big webinar. The big webinar gives you a record of who attended. It doesn't give you anyone who's confident enough to open the report on Monday.

Build a champions network early

Pick two or three people from each team that will use the reports. Give them earlier access, listen to their feedback, change things based on what they say. Make sure they get credit for the changes when the report rolls out to the wider team. They become the first line of support for their colleagues, and the soft authority they bring carries the rollout further than any official comms can.

We do this on almost every engagement now. It costs you about two hours of those champions' time per week for the duration of the project, and it returns far more than that in adoption.

Kill the old thing

This sounds obvious but it's the bit most organisations chicken out on. If you've replaced the Tuesday email spreadsheet with a Power BI report, stop sending the spreadsheet. If you don't, people will keep using the spreadsheet, because they always have.

I've watched executives nod along to this in the project sponsor meeting, then quietly keep emailing the spreadsheet for another six months. The new platform never takes hold.

Where it falls down

A few places I've seen change management efforts collapse, even when the technical work was good.

The biggest is when the data isn't trusted. If a senior person opens the report and sees a number that doesn't match their gut, and there's nobody around to explain the difference, they'll dismiss the whole platform. You need a fast feedback loop in the first few weeks where users can flag "this number looks wrong" and get an answer within a day. If you don't have that, you'll lose them.

The second is when the report is built for the executive but rolled out to the operations team. The executive wants a strategic overview. The operations team wants today's bookings, today's exceptions, today's call queue. Same data, very different reports. We see organisations skip the operational layer because the strategic dashboard "looks more impressive in the steering committee." That's a great way to spend a lot of money on a report nobody uses.

The third is when sponsorship goes quiet. The launch is well-supported, then three months later the sponsor moves to a new role, the new sponsor doesn't care, and the platform drifts. We try to bake in a sustained sponsorship plan as part of the engagement so this is less likely. Doesn't always work.

What this looks like in practice

When we run a Power BI engagement, we usually carve out 20 to 30 percent of the budget for what's loosely called change management. That covers stakeholder workshops, the champions program, training, comms, and the early-life support window. The clients who push back on that allocation are usually the same clients who come back six months later asking why nobody is using the reports.

For larger organisations we'll often pair the Power BI rollout with a broader data and AI strategy piece that addresses the data culture question head-on. If the organisation has historically punished people for reporting bad numbers, no amount of beautiful dashboards will change that behaviour. That's a leadership conversation, not a tech one.

For sponsors and program leads working through this stuff for the first time, we run a short AI and data leadership program that covers the strategic side of getting an analytics platform actually used inside an organisation. It's the kind of thing that's helpful to do before the rollout rather than after.

A few honest things to remember

Change management on a BI rollout is unglamorous. It's the part that doesn't get written up in the case study. It's the part where the project manager has to email the same team three times to get them to attend training. It's the part where the sponsor has to publicly stop using their old spreadsheet so everyone else feels safe doing the same.

If you treat it as the unimportant bit, you'll get the standard 10 percent adoption rate that most organisations get from their BI investments. If you treat it as the actual product, you'll get adoption rates closer to 70 or 80 percent. The technology cost is the same either way.

That's the whole point.

If you're thinking through a Power BI rollout, talk to us. We've done this enough times to know where the political landmines tend to sit and how to step around them. Our contact page is the place to start, or you can read more about how we approach Power BI consulting work.

Reference: Power BI change management guidance, Microsoft Learn.