5 Reasons Your Power BI Deployment is in Trouble

In some ways, this challenge is not specific to Power BI and could apply to any deployment of BI and analytics capabilities at your organization. However, we have seen this challenge impact quite a few Power BI deployments. Perhaps this is related to the fact that many organizations are rolling out Power BI as part of an existing BI and analytics system or focusing on departmental BI initially. The latter typically meaning that it’s not given the level of strategy and planning that an enterprise-wide rollout might entail.

Regardless of the scope of deployment, it’s important to start with some level of governance that will help avoid larger headaches later on as adoption grows.

A good place to start is defining the delivery approach, user groups, and ownership of key components. Microsoft provides some pretty good guidance for this in this whitepaper.

There are quite a few elements to consider and plan for related to your governance framework including organizational structure and operating model, delivery structure, roadmap/portfolio, intake/backlog management, change management, communications, and much more.

For Power BI specifically, some key elements include:

2. Overlooking Workspace Design, Apps Approach, Themes and Templates, and Development Standards

Sometimes it’s the small things that can make a big difference. That is definitely the case with this challenge. We have seen several organizations that have deployed Power BI without thinking through the workspace design, styles templates, and development standards. All of these items can cause problems if not established, with at least some baseline, before rolling out Power BI to more than just a couple of users. We could explore each of these as a topic on their own but for purposes of this post, we will hit on a couple of pertinent items for each.

Workspaces and Apps

For workspaces and apps, one key item to be aware of is that Microsoft just recently released a revamped experience for Power BI workspaces. You can read more detail about that new experience here. In addition to that, one of the common practices we apply to workspace design is designing workspaces across two parameters: staging environment and user group/subject area. For example, for the sales user group, you might end up with Sales [Development], Sales [Test], and a Sales [Production] workspace. One of the primary reasons behind this practice is security and staging (although this may change in the future when Power BI enables object-level security within a workspace).

Themes and Templates

Themes and templates can also go a long way in driving consistency and acceleration of your Power BI content, although they serve different purposes. A report theme allows you to apply consistent colors, icons, etc. to a Power BI report. When you apply a report theme, all visuals in your report use the colors and formatting from the theme. This has obvious benefits to creating a consistent look and feel across your Power BI content. When you create a consistent user experience you lower the friction or ramp-up required for end-users and drive faster adoption.

A template is a Power BI file that contains all the metadata required for an analysis but doesn’t contain the data itself. Templates are a great way to having a starting point for a particular type of analysis or subject area so a user is not starting from scratch. It also is a great way to provide guidelines for dashboards and analysis standards for users.

Beyond these items, it will also help to define development or implementation standards upfront for all users. You don’t have to define everything, and it doesn’t take a long time to start with the basics. Then, as your content grows you can add to the standards as you encounter different usage patterns. This small step can go a long way in driving adoption.

3. Getting the Product, Licensing, and Capacity Mix Wrong

A big part of the initial planning and deployment of any BI tool is determining the right products, licensing, and capacity. Additionally, this has to be monitored as adoption grows and usually you will come to a point of needing to re-evaluate quicker than you think. You can start by understanding the Power BI product portfolio (see diagram below) and plan how each product will be used for the type of deployment and various user groups at your organization.

From Microsoft’s Power BI Deployment Guide

A very common question that we get when working with Power BI at client organizations is regarding the need for Power BI Pro vs Power BI Premium licensing (and when you might need to graduate from Pro to Premium). Below is a high-level matrix from Microsoft that summarizes the capabilities by product.

From Microsoft

It’s typical that organizations start with Pro licenses, but usually there are a couple of key triggers that drive the need to bring in Premium capacity. Those include:

There are some more nuances involved in evaluating the right mix, but it’s important to understand the products and capabilities and evaluate as you evolve. The Power BI and Azure ecosystem itself is constantly changing so this is not a static exercise.

4. Not Organizing for Effective Development Lifecycle and Release Management

This is an area that has traditionally been lacking in Power BI, but recently they have made some strides in resolving with deployment pipelines. The deployment pipelines tool enables BI creators to manage the release lifecycle of Power BI content. Deployment pipelines enable authors to develop and test Power BI content in the Power BI service before the content is released to end users. The content types include reports, paginated reports, dashboards, and datasets.

Deployment Pipelines Demo

The deployment pipelines are only available with Premium licensing, but even without Premium you should consider the development lifecycle and how you will handle releases. Depending on your deployment model this could be very simple and there may not be a need to overcomplicate it.

5. Data Preparation and Models Growing Out Of Control

This is one of the biggest pain points that we encounter, especially with business-led Power BI deployments. Part of the problem stems from the fact that, although Power BI has data preparation and modeling capabilities targeted to end-users, it’s still easy for the data layer to be the first to experience issues when being driven by users with little knowledge or expertise on the data architecture and modeling discipline.

As a best practice datasets or models need to be separated from the reports. By following this, architecture development and security can be handled easier. To achieve this approach, architects/developers need to use a feature called “Shared Dataset”. This dataset can be used as a data source for multiple reports and even across multiple apps.

Smartbridge Provides Microsoft Power BI Consulting Services

Once you create a “Shared Dataset” you can endorse it; telling your users/audience that the dataset is ready for consumption. Datasets can be:

Parameters are another way to keep datasets under control, they give you the flexibility to dynamically change the output of your queries depending on their value and can be used for:

Depending on where your data is located is how a dataset will refresh. If your data is on a cloud provider (Azure, SharePoint, etc) you won’t need to worry as Power BI can communicate directly with these services. For on-premise data sources, you will need to install a gateway on a device inside your network. This device will act as a bridge between your database and Power BI service.