For any BI project, knowing what kind of stories to deliver in the end is what you want to be crystal clear of from the very beginning.
The requirement for storylines can vary. You might be given clear instructions from the clients on what metrics are needed. For example, an online company wants you to help them understand how COVID-19 impacts their online sales, new customer acquisition, existing customer retention rates, etc.
The requirement can sometimes be vague. Some businesses might not know what kinds of insights they can generate from the data. For example, the same online company comes to you with their sales data and ask why their business increased drastically in the 1st half of 2020. You may not be given a clear guideline on what the final product should look like but the final goal is to tell end-users what they need to know. The way you approach the final story can vary based on what is available to you when the project kicks off.
You might also build many small stories before you deliver the final story. However, keeping the final goal in mind allows you to always move forward in the right direction.
a. Audience: Know who the end-users are and their role as a consumer of the dashboard . There could user access and security concerns as well, so get this addressed at the beginning.
b. Frequency: Understand the frequency of refresh required and the level of detail in the dataset
c. Delivery Method: Although many BI needs are done in interactive tools such as Power BI and Tableau, deliverables to leadership teams are still in the form of PowerPoint, Excel, or images through email. Thus, delivery method will have an impact on dashboard design.
d. Actual Project Scope: Be prepared to have multiple conversations with the project stakeholders to know the scope related to the data preparation, dashboard design, onboarding process, and so on. Understanding the actual project scope is critical for setting up a proper timeline that both sides agree on.
a. Granularity: Most of the time, I prefer to build a dashboard on the most granular level data than an aggregated dataset. It can be very painful to switch to a more granular data set after you have built visualizations out of an aggregated data set. Thus, I spend a decent amount of time studying the granularity of the data sets and decide the level of detail of my dashboard prior to the actual visualization development.
b. Flexibility and simplicity to switch and refresh data: For any BI project, the most ideal scenario is when you can directly connect your workbook to the company database or BI server data source. This is the best set-up for any timely dashboard refresh. However, you might also encounter projects where you had to link your workbook with offline data such as excel files. If the project will be dealing with manual refresh using offline data, you will want to get familiar with the process of the manual data pulling and keep the data structure fixed. If offline data is offered at the early stage of the project but will be switched to database connection later, you want to make sure you understand the relationship between the offline files and live connection structure. Keeping those two dimensions in mind will help you find the most sustainable data structure to begin with and save you time towards the end of the project.
Most of the BI developers I know have their own design preferences and styles. However, when it comes to client work, we need to find a balance between our personal design preference and the client’s preference. Thus, whenever you start a BI project, ask your clients if they have any company logo, icon, color theme, font style handy to use. You should also take any existing dashboards as a reference point to get a sense of what the clients prefer to see. As an example, I have a friend who prefers building dashboards using dark background (his preference) and later was told to switch back to a white background because the clients want to print out the dashboard on paper and doesn’t want to waste ink. Thus, getting aligned with your clients on the dashboard design routine is something you should think about at the early stage of your project to avoid more changes at the later stage of the project.
Above are just some of my humble opinions and examples on how to bring BI project engagement to the next level with your clients based on my experience.
For any BI project, knowing what kind of stories to deliver in the end is what you want to be crystal clear of from the very beginning.
The requirement for storylines can vary. You might be given clear instructions from the clients on what metrics are needed. For example, an online company wants you to help them understand how COVID-19 impacts their online sales, new customer acquisition, existing customer retention rates, etc.
The requirement can sometimes be vague. Some businesses might not know what kinds of insights they can generate from the data. For example, the same online company comes to you with their sales data and ask why their business increased drastically in the 1st half of 2020. You may not be given a clear guideline on what the final product should look like but the final goal is to tell end-users what they need to know. The way you approach the final story can vary based on what is available to you when the project kicks off.
You might also build many small stories before you deliver the final story. However, keeping the final goal in mind allows you to always move forward in the right direction.
a. Audience: Know who the end-users are and their role as a consumer of the dashboard . There could user access and security concerns as well, so get this addressed at the beginning.
b. Frequency: Understand the frequency of refresh required and the level of detail in the dataset
c. Delivery Method: Although many BI needs are done in interactive tools such as Power BI and Tableau, deliverables to leadership teams are still in the form of PowerPoint, Excel, or images through email. Thus, delivery method will have an impact on dashboard design.
d. Actual Project Scope: Be prepared to have multiple conversations with the project stakeholders to know the scope related to the data preparation, dashboard design, onboarding process, and so on. Understanding the actual project scope is critical for setting up a proper timeline that both sides agree on.
a. Granularity: Most of the time, I prefer to build a dashboard on the most granular level data than an aggregated dataset. It can be very painful to switch to a more granular data set after you have built visualizations out of an aggregated data set. Thus, I spend a decent amount of time studying the granularity of the data sets and decide the level of detail of my dashboard prior to the actual visualization development.
b. Flexibility and simplicity to switch and refresh data: For any BI project, the most ideal scenario is when you can directly connect your workbook to the company database or BI server data source. This is the best set-up for any timely dashboard refresh. However, you might also encounter projects where you had to link your workbook with offline data such as excel files. If the project will be dealing with manual refresh using offline data, you will want to get familiar with the process of the manual data pulling and keep the data structure fixed. If offline data is offered at the early stage of the project but will be switched to database connection later, you want to make sure you understand the relationship between the offline files and live connection structure. Keeping those two dimensions in mind will help you find the most sustainable data structure to begin with and save you time towards the end of the project.
Most of the BI developers I know have their own design preferences and styles. However, when it comes to client work, we need to find a balance between our personal design preference and the client’s preference. Thus, whenever you start a BI project, ask your clients if they have any company logo, icon, color theme, font style handy to use. You should also take any existing dashboards as a reference point to get a sense of what the clients prefer to see. As an example, I have a friend who prefers building dashboards using dark background (his preference) and later was told to switch back to a white background because the clients want to print out the dashboard on paper and doesn’t want to waste ink. Thus, getting aligned with your clients on the dashboard design routine is something you should think about at the early stage of your project to avoid more changes at the later stage of the project.
Above are just some of my humble opinions and examples on how to bring BI project engagement to the next level with your clients based on my experience.
Lorem ipsum dolor sit amet consectetur. Sit sit vel eu sed proin. Arcu bibendum in mauris urna erat magna volutpat eget. Lectus commodo consectetur egestas quis ut lobortis nunc.
.png)
Lorem ipsum dolor sit amet consectetur. Sit sit vel eu sed proin. Arcu bibendum in mauris urna erat magna volutpat eget. Lectus commodo consectetur egestas quis ut lobortis nunc.
.jpeg)
