How to build effective business context for solving Data Analytical problems!

BDMS System — Business Context, Data Garage, Modeling and Storytelling

In the last blog, I analyzed all the analytics projects that I had undertaken and delivered till date and built parallels to define a system which I use to solve any problem. I called this system BDMS — Business Context, Data Garage, Modeling, and Storytelling. The important part here is that Storytelling is not just something that one does at the end of the project but instead some of the best projects are built on a factor of storytelling all through the process. But we’ll talk about storytelling in one of the later posts. I intend to focus this blog post on the workflow of solving an analytical problem and the tools that I use to navigate through the business context section of the BDMS system.

As I had mentioned in the last blog post solving an analytics problem is a sequential process and the more streamlined the workflow to solve any problem, the better the results. I had a chance to build this workflow with our MSBA Industry Partner. When I showcased the first version of this workflow, he sat me down and we talked through how we could make the process better. The transformed workflow looks like this:

The workflow that I use to solve any analytical problem

In essence, the workflow consists of 5 components:

1. Structuring the Problem — A rubric to structure the problem at hand
2. Define Hypotheses — Identifying, defining and testing Hypotheses
3. Describe and Transform Data — Data collection and transformation
4. Model Building — Choosing and fitting models (Link to Dashboard)
5. Presentation — Presenting the analyses to the end user

Today, we would be looking at doing a deeper dive into the first two parts, which are structuring the problem and defining hypotheses. I believe that these two parts are highly related to each other and most good problems are structured iteratively by building and proving/ disproving hypotheses.

I structure a problem using a simple rubric and a number of tools. An effective problem structuring involves asking core questions about the perceived problem. I always ask these questions before starting on working on a problem:

1. What is the problem statement that I have received? — It is important to note here that the problem statement that you receive isn’t always the real problem statement. One of the important responsibilities of a business/ data analyst is to tease the real problem out of the business owners
2. What is the exhaustive list of all stakeholders involved with the problem? — Is it just say the product manager or strategy team or the client experience team? The reason this information is important because different stakeholders have different needs and it is important that one looks at all these factors
3. What are the scope limits? — Essentially, what is in the purview of this analysis and what is off the scope. This is important in order to focus on the important parts of the analysis
4. What are the criteria for success? — This defines what success means to the party that you are doing the analysis for and this often helps you measure the effectiveness of the analysis. Success could be “I want to save $100K by targeting advertisements to people” or it could be “I want to have a dashboard with these 12 metrics that showcases the state of my business” — this is our success metric for the practicum project
5. What are the key constraints? — Most people overlook this point when they start working on a project. The constraints like the scope keep your analysis in check. More importantly, the constraints actually mimic the real world conditions and hence help with reducing model/ analysis iteration time when you deploy it in production

The results of all these questions can be synthesized into a business requirement document (BRD) which broadly mentions all the answers for the questions asked above but also does a deeper dive into the exact requirements. These requirements could be metrics and dimensions if you are building a dashboard or information about specific models that are needed to be enforced to solve this problem or the details about the test and train data sets for the problem. I have been in trouble number of times before when my BRD was not robust enough. If you ask my practicum team, they will tell you that the one thing that I keep reiterating is that “For the scope of the project, the BRD is our bible, it is set in stone and if there is any conflict, open the BRD and answer the questions you want”. That is how much I believe in using the BRD. This complete process however is very iterative as seen in the image below:

Iterative process that helps effectively set a business context and define the business requirements

One of the blocks in the above figure is that of building hypotheses. I had spoken about this in the analytical problem-solving workflow too. I believe that what separates the good analysts from the best analysts is how they can structure and build hypotheses. Frankly, if there is a creative requirement from an analyst, it is here. The process of building and verifying hypotheses involves the following:

1. Creating an exhaustive list of all possible hypotheses. The first set of hypotheses can be built by talking to people who are SMEs in the field that you are currently doing an analysis for.
2. Identifying the data requirements to test the hypotheses. More often than not, you will find that the data required to prove or disprove the hypotheses will be difficult to acquire and hence you’ll have to let go of the trail of thinking
3. After acquiring the data one can test the hypotheses both statistically and practically
4. Finally, you use these preliminary hypotheses in order to refine the scope of the analysis.

The statistical process to prove/ disprove an hypotheses

In addition to using the statistical tests, I prove/ disprove the hypotheses by using Tableau. I feel like visualizing questions is a very effective way to get a strong hold on the data while testing your hypotheses.

The above mentioned tools and frameworks have been effective for me. I would urge each one of you to recognize what works for you and double down on that framework. Over the next couple of blog posts I will be talking about how I work on Exploratory Data Analysis and Modeling. Stay tuned!

About the Author: I have spent the last 5 years building a platform for student careers in India. I am currently studying the Master of Science in Business Analytics program at UC Davis to augment my business understanding with data expertise. I aim tograduate in August 2018 and I am currently building skills and knowledge to impact more than a billion people over the next 5 years. Feel free to write to me on sjpra@ucdavis.edu or connect with me on LinkedIn.