<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=612681139262614&amp;ev=PageView&amp;noscript=1">
Skip to content

Need help? Talk to an expert: phone(904) 638-5743

Power BI Worst Practices: Failure to Educate the Users

Power BI Worst Practices: Failure to Educate the Users

Power BI Worst Practices-02 (002)

We hear plenty about best practices and can search and find blogs and videos from industry experts on doing things in the most optimal way possible. I am not one of the Power BI experts; instead I’m a Power user that has a good understanding of the sales data and its sources at our organization. My qualification is only to share my own experiences, many of which can be classified as “Power BI worst practices”.

I feel fortunate to work at Pragmatic Works where I am surrounded by expert Power BI professionals who are highly qualified to provide true best practice advice when it comes to Power BI and business intelligence. However, I am passionate about digging into the data I have available to me so that I can gain new insights and chart my course based on analytics. It would be fair to classify me as something closer to a citizen developer - one who has embraced Power BI and taken plenty of bumps and bruises along the way while using this platform.

In my Power BI worst practices blogs, I’ll share my own Power BI experiences, my goal being to use some of the work I enjoyed doing as examples and, more specifically, shine a light on the mistakes I’ve made while doing it (there are plenty but I’ll keep each post bite sized). I’ll share what may have caused them, as well as steps I’ve taken or should take so that I don’t repeat them. Best case is you learn from the missteps I made and can avoid them altogether in your own environment.

Scenario:

I love getting a good report or dashboard request from a peer! It’s an opportunity to show off Power BI and a chance for me to show off my limited chops using the tool. When I deliver on the request, I may even get a nice shout out or pat on the back from someone else which always makes me feel good.

My experience working with Power BI is in creating dashboards and reports to gain my own insights or intended to meet requests for other individuals and internal groups within my organization. I have more wiggle room and margin for error if I’m just creating dashboards for my own consumption but serving up reports for others certainly requires great care and planning before I put the analysis “out there”.

So, when a colleague in a different department reached out asking for help surfacing info using sales data, I jumped at the opportunity. Most of my time working on the request was spent identifying the correct data to use from our CRM and from there transforming and formatting data before then moving on to putting together a small model with relationships all in Power BI Desktop. Only then was I able to start playing with different visualizations to present the data in a way that made the most sense based on the requestor’s requirements.

What I did:

After creating what I felt was a quality dashboard, I reviewed the user requirements given once again and asked myself, could my colleague easily answer the business questions they had through the solution I developed? Once I could say “yes!”, I shared the dashboard by granting access to the individual. The requestor confirmed via chat that it looked great! I was a happy guy for meeting the request in a timely manner and now I could be on my way…

Fast forward a couple of weeks. I received a call from the manager of the colleague I originally provided the dashboard to. They had seen screenshots of the dashboard I created and were intrigued by the results but had a lot of questions about what the data was showing and what sources were being used.

It turned out that although the reports met the needs of the initial individual’s request, when viewed by others who did not have an understanding of what the report request was or what questions the dashboard was developed to answer, there was room for misinterpretation of the data. This led to questions and confusion among a whole group of folks that ended up seeing parts of the dashboards I produced. I went from feeling kind of proud of myself for the initial work I had done, to feeling really bad about having created something that the eventual audience did not have confidence in.

Steps I should have taken:

1.  Early on, get clarity from the user on what the results will be used for and who else might consume the analytics, in other words, all the stakeholders. Then schedule a time to host a rollout demo solution to all possible known report and dashboard consumers, showing things like how to use slicers and drill down. Don’t skip this even if you feel the dashboard is simple and straightforward; if it is indeed simple, your demo will be a quick and positive one!

2. Document and convey what the original request was and what the delivered report/dashboard is intended for (and not intended for). The data itself and the visualization used may be optimal for one scenario but not for others.

3. Outline where the data comes from and what data sources you are using. Users will, and should, question the actual data and results since most of us have come across dirty data at times. Expect these concerns and get ahead of it by outlining the data sources and any data quality issues you encountered and addressed. Share this with the report consumers. Beautiful visual aside, users want confidence in, and to be sure they can trust, the data.

By executing a process and following steps outlined above, I can greatly reduce the possibility of ending up in another uncomfortable situation and the business avoids making decisions based on data that may not actually be ideal for their specific analysis.

Experienced Power BI architects from Pragmatic Works help organizations establish implementation, delivery and administrative best practices for their Power BI initiatives. We also offer Shared Development where we can give you a developer on-demand at a fraction of what you would pay for a full-time developer. We can set you up with new expert development time, for a week or each month or a year, whatever your need may be, with the same developer plus 8-hours of support on-demand.

If you are interested in learning more about our Power BI Service offerings or Shared Development, contact us—let’s start a conversation and see where we can help to take your business from good to great.

 

Sign-up now and get instant access

Leave a comment

Free Trial

On-demand learning

Most Recent

private training

Hackathons, enterprise training, virtual monitoring