© 2017 by QS2 Point

  • Facebook - Black Circle
  • Twitter - Black Circle
  • LinkedIn - Black Circle

September 18, 2019

Please reload

Recent Posts

Translating Requirements to Work Packages

September 18, 2017

1/5
Please reload

Featured Posts

Structuring a Power BI Library for Project Managers

April 18, 2019

 

I’ve recently started really digging into the power platform offered by Microsoft. I’ve begun writing my own workflows using Flow, building kick-butt reports and dashboards using Power BI and am looking forward to completing the trifecta by getting into Power Apps next. This week I’m going to talk a little bit about how to share the knowledge with your fellow project managers when it comes to building out Power BI reports.

 

Build your Dataset

With any BI tool, your dataset is the key. At my current workplace we use a tool called LiquidPlanner that has a great API to make just about any piece of data accessible. Do not kid yourself – no matter how great the API is to pull data down from your PSA system, you need to structure your datasets properly. Ensure a good level of normalization while maintaining a level of usability for someone without a wealth of database experience. Here’s a tip – start simple – bring in your projects, your tasks and your timesheets. Those three elements account for a large amount of data that you as a project manager will be interested in. As you get more comfortable with building out datasets and relationships you can get more advanced with the data you are bringing across.

 

Determine the Right Workspace & Deployment Model

Power BI is a relatively young BI tool and still has some growing to do. A limitation (somewhat big in my opinion) is that when authoring a report in Power BI, you are limited to the datasets in the workspace where your report lives (i.e. you cannot connect a report in Workspace A to a dataset in Workspace B). This is a reason for pause when determining how you would like to deploy your dataset to make it available to your colleagues. Keep in mind that if you are using Power BI online for report authoring you are limited to the workspace location issue I just mentioned – if your colleagues are using Power BI desktop to connect to the data set, you are less limited by where you publish it. Just remember that if you ever have a problem with your dataset and for some reason need to delete it from Power BI online – any report (in Power BI online) connected to that dataset will be deleted also.

 

Govern Report Numbers and Names

One of the great things of Power BI is the slicer – the built-in report filter. When building a project status report, you are more than likely going to want the same information displayed in the same manner across all projects. So no need to build one report per project, right? Most of the time. As we all know, each project has its unique flavour and areas of interest that you may want to key on that your ‘standard’ project report may not have, and that you may not want to add into that report. This would necessitate a one-off report, which is fine. Just remember that when you have a team of 10 project manager colleagues building reports for each of their projects, the workspace will get a little crowded (assuming Power BI online). This is ok – Power BI can handle it but what it doesn’t do a particularly great job of is making a pleasant user interface for the list of reports. It’s basically one gigantic list that’s sortable by report name.

 

One alternative is to ‘favorite’ your reports so that you can see a quick view of reports that you are interested in but this still can get a little messy if not looked after properly. Encourage your project managers to create one-offs only when needed and to use a consistent naming convention that everyone can understand.

 

Share on Facebook
Share on Twitter
Please reload

Please reload

Archive