Change Management for Analytics (Without the Theater)

You can run a launch week, a town hall, and a badge on the intranet, and on Tuesday the plant controller still opens last month’s workbook. That is not a people problem. It is a change design that never named what stops.

Adoption is not a communications campaign

Most Power BI “change programs” are a calendar of awareness: kickoff, demo, optional training, a PDF of click paths. Then comes go-live, which means a link in an email.

Awareness does not move a close. Operators change when the new path is faster than the old file, the number matches finance, and a leader stops accepting the old file. If any of those three is missing, the deck was theater.

This is a different problem from why nobody opens the dashboard. That piece is about the product: grain, speed, and trust. This one is about the operating change: who stops, who owns, and what the default is on Monday. We covered programs that stall on scope and owners in analytics programs fail in delivery. Here the stall comes after the ship, when the work still lives in the twin.

Hands-on sequencing and adoption is the job Alluvium scopes as data project management and change leadership. Strategy still matters, too: if the report is not tied to a decision, no amount of coaching will make it a habit.

What practical change actually is

Practical change has a named owner for the new way of working, someone with authority, not a “champion network” without any.

It has a default. The Monday pack is the app, the meeting agenda uses the app, and email attachments of the old file get sent back instead of praised.

It has a retire list with dates covering twin workbooks, twin reports, and twin extracts. If you cannot name what dies, you did not change anything. You added inventory.

It has a first-week desk for access, grain, and “where did my tab go.” If that desk is an IT ticket, the workbook wins by lunch.

And it depends on leadership behavior. If the CFO still asks for the file by name, the organization heard the real instruction.

The costs of theater

1. The twin never dies. You paid for a model and kept the close on a shared drive. Now there are two truths and two refreshes, and the meeting argues about which file is live. Change that does not retire anything is a duplicate cost, not a transition.

2. Training teaches a product nobody will use. Hours of click paths on a page that is slower than Excel, or that disagrees with the controller, teach one lesson: stay on the spreadsheet. You burned calendar and did not change the work.

3. Local heroes become the bottleneck. One analyst who “gets Power BI” fields every ping, and when they are out, the plant reverts. That is not adoption. It is a single point of failure dressed as a success story.

4. Leaders keep two stacks. They nod in the steering meeting and still request the old pack, and the floor copies the leader. You cannot train your way past an executive who will not switch.

5. Shadow process goes quiet instead of going away. People stop arguing in the channel and keep a private file instead. Adoption looks “green” because ticket volume dropped, while the decision still runs on a copy.

6. The next launch is already discounted. After two theatrical go-lives, the plant will sit through the third demo and change nothing. You spent the program’s trust on slides.

If last Tuesday’s meeting still used a workbook the program claimed to replace, you already have the bill.

What not to do

Do not schedule change after go-live. If adoption is “phase two,” phase two never gets staffed.

Do not measure success by training attendance. Measure files retired, meetings that run from the app, and questions that go to the steward instead of the hero.

Do not keep the old file “just for this cycle.” That sentence is how twins become permanent.

How to fix it

1. Name the stop. Write down the workbook, extract, or email pack this release replaces, with an owner, a date, and what happens if someone still sends it. If you cannot name the stop, you are launching a hobby.

2. Make one app the default. Viewers should not hunt through workspaces, so the Monday pack lives in one place. Personal bookmarks are fine. Personal published twins are not.

3. Put change tasks on the same board as build. Decide who loses the file, who gets trained, who covers week one, and who tells leadership the old pack is closed, and assign names. If it is not on the board, it will lose to a visual polish ticket.

4. Change the meeting, not the inbox. In the first live week, the agenda owner opens the app in the room, and questions that used to be “send me the file” become filters. If the meeting still needs a paste, either the product is wrong or the chair is not on board. Fix that before you schedule more training.

5. Staff a first-week desk, then taper it. Name a person for access, grain, and “where did my tab go,” and time-box the role. Capture the repeat questions as model or app fixes. Do not let the desk turn into a permanent report factory, or you will recreate the IT wait inside the change program.

6. Leaders go first, in public. The CFO, plant lead, or VP who asked for the program uses the app in the first meeting they chair and refuses the twin. That is the only communication that scales.

Start with one meeting and one file, and prove the stop. A Power BI Quickstart can stand up the product. Change is whether it replaces the work. If you lack someone who can own sequence, stakeholders, and the stop, that is the change leadership job. A borrowed lead for a quarter beats a laminated comms plan.

What good looks like

The old file has a tombstone date. People still remember it, but they do not open it.

The Monday agenda assumes the app, and exceptions are a filter instead of a side workbook. Questions go to the measure steward, not to whoever built the first page.

Training is short and comes late, after the page is faster than the spreadsheet and agrees with finance, never as a substitute for either.

FAQ

Do we need a change-management methodology? No. You need a stop list, a default, and a leader who will not take the old file. Frameworks without those three are theater with better branding.

What if the new report is worse than the spreadsheet? Then do not force the switch. Fix grain, refresh, and trust first, because change cannot rescue a bad product. That problem belongs to nobody opens the dashboard, not this post.

Get started

Stop scheduling another launch week. Write down the file that dies, the app that replaces it, and the person who will refuse the twin.

Want to know why the dashboard shipped and the workbook still runs Tuesday? Book a session. We will map one meeting, one stop, and the first-week desk, not another training deck. Or start with a free Model Health check.