So, you want to implement Power BI. That’s not too surprising; it is a fantastic tool. It’s also no surprise that there are countless other organizations thinking of doing the same thing. And, like so many of those other organizations, you probably want to make the implementation as painful and horrifying as possible.
Well, you're in luck. We’ve seen enough successful Power BI implementations to know exactly what it takes to botch one. Read on.
1. Pack as Many Visuals on Every Report Page as Possible
Power BI can be a very quick and powerful tool. The biggest problem with having a fast, powerful tool is that people may adopt it or even like it. To avoid that headache, you should pack as many visuals on every report page as possible.
Visuals in a report are loaded when someone clicks into a report page. By having TONS of visuals on each page, you ensure that TONS of queries run at the same time. This can recreate the ever-loading experience we’ve all come to cherish. Users will complain, but as you and I know, they should love long load times because the “extra time” it gives them. They can now snag a sandwich or catch up with their moms, things they may not have time to do otherwise.
Bonus Tip: you should always sync your slicers across the pages of your report. With that on, each time a user lands on a page, all the queries of all the visuals on all the pages with a synced slicer run simultaneously. And that’s extra awesome if they need the extra time. And they do.
2. Make Your Data Models with the Maximum Number of Squiggly, Criss-Crossing Lines
Power BI utilizes relational data models. If you were to use star schemas within your data models (or snowflakes when stars aren’t possible), Power BI’s impressive engine would run at its optimal speed and function in a predictable way—providing a great user and developer experience—which is exactly what you want to avoid.
A data model is to a report, what a plumbing system is to a house. Sure, plumbing systems can be made using best practices, but that makes life too predictable. By avoiding best practices, plumbing systems can successfully drive users to the brink of madness: cold water when expecting hot water, drips when expecting solid streams, rotting joists that you may never notice—until it’s too late. Doesn’t get any better than that.
A poorly designed data model can provide similar pain. Some or no data when expecting a full table. Data that looks right—but are actually very wrong—but you won’t notice until the CEO calls it out in front of all your colleagues.
To really botch your implementation, a bad data model can go a long way.
3. Do the Implementation Without the Guidance of an Expert
One particularly nefarious way to botch a Power BI implementation is to just start creating reports and datasets before learning Power BI. This is the equivalent of building a house without first laying a foundation; it’s a recipe for a long, delayed collapse—or at least an early, expensive remodel.
If the architecture of a Power BI environment is done incorrectly before building reports, re-hauling the environments and each report in turn would be akin to nails on a chalkboard. For days on end.
The DAX language is also problematic with this approach. DAX is most often used for creating measures, which produce data within visuals on a page. Measures allow numbers to be sliced on the fly within visuals (by time, segments, etc.), providing an incredibly satisfying and dynamic report experience.
However, validating measures can be difficult because of all the potential contexts in which measures can be placed. And to make matters worse (or better if you have a deeper understanding of DAX), a developer can use DAX to manipulate contexts. Again, this can be incredibly helpful, but this can also hide bad numbers then reveal them at the least opportune time.
Hiring someone like JourneyTEAM to walk you and your developers through the implementation would, of course, hedge your bets. You may also sign up for JourneyTEAM University or other training resources. But, alas, both of those options would ruin your chances for botching the implementation. So, be leery of such things.
4. Avoid License Fees AT ALL COSTS
License fees are the worst right? So why not drive your project to the ground (our ultimate goal here) to save a few hundred bucks a month? Admittedly, $10 per user per month undercuts the competition significantly, but licensing fees are still the worst.
With no license fees at all, someone in your organization could develop reports using Power BI Desktop then publish the reports directly to the web. You could then snag the URL and embed the report into your sites, where every employee or site visitor can see them. Amazing, right?
The only draw back here is that by publishing to the web, the report becomes available to EVERYONE online. But is that really a drawback? I mean, who doesn’t need to know your organization’s financial health? In the name of transparency and saving those pesky licensing fees, this is the obvious way forward. Now, if your legal or compliance teams find out about this approach, they could kibosh the project—but again—that’s the point here, right?
5. Do All Your Data Transformations Within Power BI Desktop
Power BI can perform essentially any data transformation your data may need prior to visualization. For example, it can pivot, append (UNION), merge (JOIN), concatenate, split, etc. And it can do all this from the comfort of a straightforward UI, no code knowledge necessary. However, transformations do require computing power and sometimes quite a bit of it.
To gift your developers with some “extra time”, be sure to perform these transformations within Power BI Desktop files. By doing that, you will make it so every time a developer refreshes the file or accesses certain tables in Power Query, the refresh times will be extended, bogged down by each of those computing-intensive transformations. Your developers will thank you later.
Now, there are dataflows available within app.powerbi.com that can perform the computing intensive transformations in the cloud (i.e., not on your computer), but that would take the gift of extra time away from your developers. So, avoid those whenever possible.
6. Publish a New Dataset with Every New Report
Effectively organizing datasets, dataflows, reports, and dashboards in a Power BI workspace can admittedly be pretty difficult. Thankfully, there is a way to make it even more difficult.
Each time a developer publishes a report to a Power BI workspace, unless it’s referencing a previously published dataset, they create a new dataset in the workspace. If you and your developers make a habit of this, rather than creating datasets and referencing them within reports, you could eventually have dozens and dozens of datasets littering your workspace. The best part is that each of those datasets are likely to be very similar to the other datasets. Duplication is awesome, am I right? And sifting through lists of datasets to get to the one that actually matters is just an added bonus.
Another bonus, by creating datasets each time you publish a report, you miss on the ability to create and maintain measures in one place. This means your developers will need to recreate measures in each new report. Everyone loves re-doing work whenever possible.
CONCLUSION
Power BI is an exceptional tool. It’s powerful enough to establish a data-driven culture in any organization, no matter how old school. However, botching a Power BI implementation can be surprisingly easy. That is especially true if you take to heart the suggestions provided.
All the best! Contact JourneyTEAM to learn more.