There are several factors that come into play to contribute to delivering a successful Microsoft Power BI analytics project to ensure high user adoption and an optimal Power BI environment to deliver useful insight to the business. Unfortunately, certain aspects of the project if not done well can lead to reduced performance, higher costs, a frustrated user base, longer delivery timeframes and reliability and performance issues. Each Power BI engagement is different, but here we identify four key factors or pitfalls that if you encounter, should be ringing alarm bells.
1. Datasets, Reports & BI Skills
One of the first components that should be looked at carefully is the availability and construction of the datasets to use as the basis of the Power BI reports. For example, look closely at how many reports are being used per dataset. Before you start building a new Power BI dataset, particularly one that imports data from sources, you should at least confirm that a dataset/data model doesn’t already exist with the required data and logic, and if a new dataset is required, try to think more broadly about how your dataset will support multiple reports. Try to avoid creating a new dataset for each new report as the more datasets created need to be maintained and can cause issues with memory and data refreshes, especially if the dataset is the data model itself. While also keep in mind that the specialists working on your Power BI engagement should have proficiency in not only DAX, but also other languages like Power Query (M) and/or SQL and possibly others, to ensure the value of your solutions aren’t limited.
2. User Access & Identities
Don’t exclusively rely on Power BI app access for user permissions. The underlying dataset(s) within the workspace published as an app don’t implement row-level security and therefore the app permission list is the only access layer, which means it’s then the responsibility of a few users in the workspace to regularly add or remove users from the app which can be cumbersome or overlooked. Identify the team responsible for identity management and/or Azure Active Directory in your business and work with them on the creation of management groups to support Power BI and consider requiring row-level security roles in datasets.
3. Monitor Overall Power BI Usage & Environments
It’s important to have a view of the bigger picture of overall Power BI adoption, usage, and resource utilisation for the organisation, outside of the specific project you’re working on. If you don’t have a basic monitoring solution in place, or any known Power BI admin to help you, or any idea on the resources (e.g. pro licenses, premium v-cores) available, you might want to pause your Power BI development activities until you do. The Power BI Premium Metrics app, the Power BI activity log and having a Power BI Admin role should ensure you understand available resources in place. Power BI and resource activity can change quickly so an active approach to administration of your Power BI environment is critical to not only check for bottlenecks or issues but to also interact with users and Power BI teams to understand the issues they’re encountering, their plans for future projects, and to share what you and/or the BI team are planning or working on such as data models, revised governance policies and other areas.
4. Beware of Project Silos
In many scenarios a project is often created around a particular team or key stakeholders’ needs/requirements and the team or developer assigned to the project is focused on working to these. However, there’s a high chance that some of the requirements for Project A, such as financial analytics, overlap with the requirements for Project B and several future projects. There can be real version control problems and inefficiencies with different project teams independently developing their own BI artifacts to cater to the specific wishes of a single project or project sponsor. You could have many different DAX metrics with slightly different names but similar or slightly different logic which can create confusion as to which data model or set of DAX metrics (if any) should be used going forward. It’s a good idea to use the same analytics team or analytics partner working on your environment to span multiple data and analytics projects to overcome duplication of effort.
These are just four Power BI pitfalls that businesses can succumb to, but as mentioned there are several factors that come into play to contribute to delivering a successful Power BI analytics project. Hopefully you find some of these tips useful and of course if you need expert assistance with Microsoft Power BI or building the underlying data foundation, BoomData are well equipped to assist.
