From Business Intelligence Analyst’s experience
Whether you are Data Analysts, Business Intelligence Analysts, admit or not, I guess you have been underwhelmed with Stakeholders and their data requests at least once in your data life. Those requests were ad-hoc with tight deadlines, no context, no clear purpose and they also didn’t know what outcomes looked like. Doing those things day over day makes you frustrated and confused about the value of data positions in your organization.
I feel you and now, I’m here to share my tips to help you have an easier working life.
Ask The Right Question to recognize the true problems
When receiving data requests or business questions, asking Stakeholders some questions to gain a better and deeper understanding of the problem. Our task is to learn the domain knowledge from Stakeholders and combine our technical knowledge with data to come up with a solution to drive business values.
Asking the right question Is not easy and it is both an art and a science. It depends greatly on the outcomes you are trying to obtain and the details of your data and subject matter. In return, asking the right questions and defining exact problems is one of the most important steps in the data analytics process, helping you solve problems straightforwardly.
Examples
Most of the time, Stakeholders will just give us a question: I have this “question”, can you help me solve this?
Our task is to approach and solve their problems with data. Some kinds of questions you should ask Stakeholders:
- What is the objective of this data request? What do you want to obtain from the data?
- What is your (business) context? What are the products and services you need to focus on?
- What are your assumptions or hypotheses about your problems?
- What timeframe do you want to get data?
- What is calculation logic? Or, how to calculate those numbers? (if you don’t know and aren’t sure)
- What does the data analytics result look like?
This is important to ensure you and Stakeholders are on the same page and you totally understand their expectations.
Sometimes, Stakeholders have not thought deeply enough about their problems, they don’t know what exactly they want till they answer your questions and discuss the purpose of data requests. You need to have empathy and respect for their problems to move on to the next stage.
Choose suitable solutions to solve ad-hoc requests
Dashboard
Ad-hoc questions that begin with Who, What, Where, and When are better answered by a report than an analyst. If you are spending all your time on questions like these, you should think about building a dashboard that is updated frequently to answer those questions. Build an interactive dashboard, it will be more cost effective and much more fulfilling for you.
Queries
Nowadays, many companies invest in databases and grant access for non-tech people to get data. Data team often receives ad-hoc questions that are considered as SQL queries. Basically, non-tech people just want to ask how to write a query to get data themselves, instead of waiting for the results. To optimize your company’s use of queries, consider to leave queries to junior and entry-level analysts with senior oversight. In addition, any query that you were asked more than twice should be documented and shared with Stakeholders.
Analysis
If you receive a “Why” question, you need to spend more time and deliver a deep and meaningful analysis. Some of it will still be ad-hoc, but may require further exploration and hypothesis, advanced data processing technique to solve.
Your Business Stakeholders usually ask “Why”, I’m sure :) — the only thing you need to do: ask the right questions to recognize the true problems and manage their expectations on your outputs.
Data Analytical Work Documentation
“What does this metric mean?”
“Why are our revenue numbers different in the finance and marketing reports?”
“Who can explain our marketing campaign analysis?”
Messages like these sound familiar? — Welcome to the life of every data analytics person in the world.
To save your time on answering those questions, a data documentation process should be implemented to help the Data team run better, build a stronger data culture around the principles of self-service and transparency.
Data team should have a framework to do data documentation.
Here is an example:
WHAT: What is the data asset about?
This could be defined by several attributes such as:
- Descriptions (for tables or columns)
- Keywords or tags
- Themes or categories
WHY: Why does the data asset exist?
- Data source
- Lineage (tracing the data asset)
- Impact analysis (what dashboards or projects does this data asset power?)
WHERE: Where is the data asset from?
- Spatial coverage
- Language
- Business domains
WHO: Who is responsible for the data asset?
- Creator or owner
- Contributors or experts
- Point of contact
WHEN: When was the data asset created and updated?
- Creation date
- Last updated or modified date
- Update frequency
- Time frame
HOW: How can the data asset be used?
- License
- Classification
- Use cases
Final Thoughts
Ultimately, our final goals are to utilize Data team resources by formulating better questions, finding better data analytical approaches to solve business questions, generate business insights and drive actionable plans.
To do that, we need a better way to deal with ad-hoc questions. There are my some tips:
- Change your perspective on ad-hoc data requests by: Asking right questions to recognize the true problems or root causes need be answered by data, learnings from ad-hoc request not only business mindsets but also the smarter ways to do it
- Set principles to deal with ad-hoc request more effectively: SLA, priority, output expectations
- Choose suitable solutions to solve ad-hoc requests as effortless as possible
- Data Documentation culture
