The good news about Power BI is that it’s an incredibly powerful platform. It changes the way your organization interacts with data and understands what is happening within your business. There is, however, an uncomfortable reality.
Microsoft won’t focus on this (nor should they, it’s not really on them). But what’s more important than the reporting platform your organization chooses is the implementation of that platform.
Said simply…
A good implementation of a mediocre tool is better than a poor implementation of a great tool.
Choosing the best tool alone will not, on its own, lead to a successful story for your organization. I don’t think this is really news to anybody, but it’s worth saying aloud. The next tricky bit is that every organization is different so it’s difficult to have a pre-made out-of-the-box implementation strategy that actually works.
Power BI implementations require a lot of planning, a lot of thinking—and they are still almost always a bit messy. That said, implementations are still worth the effort. They will certainly be better than simply hitting the “on” switch and hoping for the best.
Today’s blog isn’t a full guide to implementing a Power BI deployment—this 2-hour Power BI User Group video, What You Need to Know to Administer Power BI, with presenter Melissa Coates is the droid you are looking for. This is, by contrast, a brief overview of the kinds of challenges I see people out in the wild facing when getting their organization on Power BI.
So, without additional pomp and circumstance, here’s what I’m seeing out in the world of Power BI implementations. Hopefully, these insights will help you know what to expect when you’re expecting a Power BI rollout.
Escaping Excel Hell Only to Land in Power BI Purgatory
The first big problem most organizations face when they finally hit the “on” switch and enable Power BI for their organization is that, well, no one uses it. After a year or two of meticulously comparing products, an organization will finally have a great unveiling, and the response of the people in the organization is the sound of crickets chirping.
For several months, there will be (at most) a tiny trickle of people into Power BI. They will look around, see that no one else is using it, then head back out to the warm comfy blanket of Outlook and Excel.
Some of this can be attributed to the fact that people don’t know how to use Power BI. But the bigger issue is that most people are so heads-down in the operation of their job that the costs of spending valuable time learning about a new tool are simply prohibitive…they have things to do.
This is particularly true when their ventures into Power BI service make it look like no one else is using it. Three years ago, this was a topic that I could go on further about. But the reality is that this isn’t actually something organizations should worry too much about anymore.
Because at some point you’ll go to bed with 12 active Power BI users. When you wake up in the morning, suddenly you’ll have 12,000 users. A tipping point will occur and Power BI will start to get very, very, very rapid adoption.
What’s meaningful here is that for a long time most organizations, when rolling out the tool, will get so concerned about people not adopting the tool that they will either never implement or tear down any rules or policies that might sour people from adoption.
- Creating new Workspaces? Sure, anyone can do that.
- Roles? Make everyone an admin.
- Distribution? That’s what the Share button is for.
This can make sense—if you never reach that tipping point, you don’t have to worry about other problems because your implementation is a flop. However, once you are past the tipping point, these produce big problems.
Organizations would quickly find that they had hundreds of workspaces with no rhyme or reason to them. Reports would number in the thousand with tons of duplicates that are throwing away the benefits that something like Power BI is supposed to give you.
In the commercials, Power BI service resembles a well-oiled, well-organized machine. On the ground, it just looks like another network drive full of random documents. In short: they’ve escaped Excel Hell and landed in Power BI Purgatory.
This is where most organizations hit the pause button as fast as they can to try and get the stampede under control. Those with a Power BI implementation plan in place can do this without too much headache—those without a plan are in for an unpleasant scramble.
The Biggest Problem You’ll Face with Power BI Deployment
One of the biggest problems facing a Power BI deployment is that even though the tool allows for a great workflow, this workflow is foreign to most of the people using it. Since the dawn of civilization (Visicalc 1.0 – 1979) report developers have been building reports in the same way:
- Important person needs a report.
- Analyst builds the report.
- Important person reads the report.
Often these reports will be extremely similar to reports that have already been built, commonly starting their life as a copy of an earlier version. But each report is understood to be its own unique “one-off” report that covers one topic for one block of time.
For example, “2012 Q2 Sales” is a separate document from “2012 Q1 Sales,” even if the former began its life as a copy of the latter with minimal changes.
We often nowadays describe these “one-off” reports as “disposable” because they get used heavily for about a week, then get filed away in a network drive never to be used again (except as a seed for the next version).
This workflow did (and does) have its advantages: Each report could be fully customized to the peculiarities of “that months” or “that departments” data. “Are we rolling out a new product line this year? Then alter the visuals and calculations to focus on these new products.”
However, offsetting these benefits brings some titanic costs. Building these one-off (disposable) reports, even when based on a copy, was very labor-intensive. People’s entire jobs revolved around copying last month’s Excel workbook, updating the source data, and doing some tweaks to the formulas and resulting display pages.
The flexibility around them also meant that they were often very inconsistent. The same business question was calculated using a different formula in February than it was in January. Maybe the new version was better, but it meant looking at the two side by side would result in spurious conclusions.
Further, all these armies of reports in the network drives started to resemble a flotilla of trash, hundreds of miles in diameter floating somewhere in the middle of the Pacific.
Introducing: The Durable Power BI Report
At its simplest, Power BI was created to address these problems by introducing the new concept of a “durable” report.
- One report is built one time.
- It’s able to refresh itself every month.
- It leverages slicers to allow a single report to show accurate information for a range of departments or product categories.
It used to be that 32 months of reports over 10 product categories would be 320 separate Excel Workbooks. Now a single Power BI report could take its place.
Durable reports have been around for a long time, and can even be done in Excel. This is just the first time your average analysts have been made to think about creating one as Excel’s incredible flexibility invites the opposite style.
The problem is…report authors have been practicing the other way of working their entire professional lives AND the important decision-makers have spent an equal amount of time getting used to the idea of requesting reports in this disposable format.
When busy decision-makers and report developers land in Power BI, they use the workflow they understand. The result is an army of “one-off” reports clogging up your Power BI service workspaces making it impossible for anyone to find anything.
This is not to say that the concept of a disposable Power BI report is an oxymoron. It is actually still quite valid to use Power BI to create one-off reports, but these should make up 5-20% of your reports.
What’s needed is a training effort at both the Report Author and Decision Maker level to convey that the organization can reap huge benefits when working primarily with the “Durable Reports” workflow. Disposable reports should not be dismissed but should be understood as an expensive option that should be avoided when possible.
If you’re smart, when you roll out a Power BI deployment, you will include as part of your training a focus on why durable reports are preferable in most cases and how to go about building/distributing them.
While most of this training will be focused on report developers, you will want to have at least some effort put into helping report consumers understand why this is better and why they should focus on these kinds of reports.
1,000 Centralized Report Repositories = 0 Centralized Report Repositories
Not the same problem, but of the same flavor, all Power BI reports are stored in what’s called a Workspace (or to be more formal, an “App Workspace”). These can be thought of very vaguely as a network drive folder where individual reports live.
The tricky bit here is that again, in a bid to get folks using the tool, lots of organizations allowed anyone to create as many Workspaces as they wanted without any plan or approval process. You can already see where this is going.
Pretty quickly organizations would find they had 500 different workspaces and there didn’t seem to be any rhyme or reason to them. Not unlike a network drive, if anyone can create a folder, soon you will have so many that no one can find anything.
The problem isn’t that a given Report doesn’t have a workspace that makes sense for it to be in, but that there are 22 entirely valid workspaces that a report could belong to. Suddenly finding anything involves a lot of memorization and searching.
As a rule of thumb, if more than 20% of reports are found by doing a search then you probably have too many or they are too disorganized.
To get around this, organizations start locking down the creation of workspaces and creating understandable rules for what can and cannot be created. They still have to figure out how to merge/delete the cavalcade of Workspaces that exist. But at least they can begin to bring some order to the whole system.
One Way to Actually Plan Your Workspaces
A common approach for planning the Workspaces that you should have present versus those that should be created by request is having a grid with workspace types on the X-axis and organizational unit types on the Y-axis:
The organization as a whole (usually managed by either IT or BI teams) has the most official Workspaces and all 8 flavors of them handle all the work that goes into having the most official reports.
Departments have fewer Workspaces automatically provisioned but can request some of the less common ones as needed. When you get to teams, you can choose to not allow certain types to keep their workflow from getting too complicated.
This may seem like a lot of workspaces (use APIs and PowerShell to help with this), but this allows for rules to be easily understood without a lot of weird exceptions and corner cases confusing everyone.
Importantly, when we say “auto,” part of what we mean is that these are in place on day one of your Power BI rollout. This way, when people look at what workspace is available, it’s clear there is an existing structure based on the org structure and that they should try to stick with what’s already there.
By tying these to organizational units, it also helps emphasize that the workspace a report belongs to and indicates who is standing behind these numbers (just one team vs the entire org).
And, Don’t Forget to Purge Your Reports
Especially when you’re first getting your structure in place, but even when things are running like a Swiss watch, it will become important to have a purging mechanism to clear out unused reports—either by deleting them or moving them to an Archives workspace.
It’s not uncommon to open up a workspace and find one-off reports from years ago that people may not have looked at more than once. These reports clutter up your workspaces and make it hard to keep things organized.
Often you will get pushback around this purging, as it seems unfair to delete or even archive things. But the reality of the situation can be summed up with the following mantra:
“Storage is cheap, but disorganization is expensive.”
Usage reports can help you identify what is and isn’t being used. But rather than relying on conversations and requests like “please remove reports that aren’t being used,” it can be valuable to schedule a half-day each year for a spring cleaning, where people go through and clear out the workspaces as a team.
While you can use PowerShell and APIs to automate some of this process, having the people who manage the workspaces take the time to make these decisions both improve outcomes and reinforces just how much nicer durable reports are to live with.
_______________
The big lesson here is that the implementation of a tool is even more important than the tool you choose. So think hard about it, because it’s absolutely worth it in the end.
These organizations all chose the best tool (ahem, obviously Power BI), and still had road bumps…because that’s how life works. Before we can move on to more hopeful pastures though, we must explore how Truth is understood within these organizations.
If you have questions about your Power BI implementation, make sure to reach out to our team. Skypoint CSG is always here to help!
