Usually when clients approach me, the situation is pretty much the same. Let’s imagine a request that goes something like this.

“We need to provide information for better decision making and to gain insights. So, here’s this report we want. We need data from these systems and the report needs to include this and that calculation. Ou, I almost forgot, we need it done by yesterday.”

Does it sound familiar?

I get the urgency, but there’s also a better approach. I believe in doing things right the first time and rushing is usually a bad idea.

How I work

First, I will let you rant your thoughts for 10-15 minutes, but then I will suggest that we take a step backward. To provide you with the best solution, I need to be able to understand the why, not just the what.

The Background

To help me understand, I will ask you simple sounding questions that I have found out to be vital for the project to be successful.

1. Who (which role) will be using the report? What are their responsibilities?
2. What are the key questions that these people have for the data?
3. What is decided based on the information? Or what kind of action is taken?

First, we need to make sure we are building the report for someone who is actually going to use it. It’s best to always have an actual use case, before building something. If there’s uncertainty about the use case, then a proof of concept is a great mindset for building the initial version.

Second, I need to understand, that what kind of insights the are users looking from the reports. I might have some experience from your domain, but you will inevitably have more. The key thing is, that we work together and combine our knowledge.

Third, every report that I build, must lead to action (with few exceptions). Usually it makes no sense to build a report that does not lead to either making a decision or taking some other kind of action. Nice to know is usually needless to know.

Bonus: Sometimes new ideas arise when doing this kind of background check with a person without preconceptions from your business. The effect is similar to rubberducking, but you do get a more versatile conversation.

Into the Details

After the background is clear, we can dive into details.

1. What kind of KPI’s / measures are needed?
2. From which perspectives (dimensions) do you wish to view the measures?
3. How would you like to make comparisons?
4. Where does the data come from?
5. Are you an expert on the data level e.g., with the database structure?

Let’s do a quick example. One measure could be the revenue. You might want to see it by business unit and by time. Then you might wish to make comparisons to budget or previous year. Data is coming from your ERP, CMS or some other It-system.

So far pretty simple.

The last bit needed in order to get great results is, that we need to get really deep into the details of where the data is coming from. It’s best if you have someone in your organization who knows the ins and outs of the system in place. Even better, if they can understand the data structures under the hood.

Simple systems up to 30 tables are usually quite easy to reverse engineer, but if a system has hundreds of tables, then expertise can really help move project smoothly along.

Stop

At this point it is good to stop and evaluate. I mean Power BI is awesome and one of my favourite tools, but it’s possible that there’s not enough power in Power BI. Sometimes a more robust data architecture is needed.

But that is a story for another day.

End

The Point: Focus on the why instead of what. The better I can understand you, the better the end results will be.