Who are you and how’d you get here?
When I first started looking into Masters programs I didn’t know what I was looking for. All I knew was that I wanted to work with data as either a data scientist or data analyst. Thankfully I didn’t limit myself to programs which focused on these titles exclusively. If I had I never would have found the UC Davis Masters of Science in Business Analytics program.
A key component of this program is the practicum project. A practicum project as defined on the UC Davis MSBA website is about creating a learning experience by bringing company partners and MSBA student teams, with faculty advisors, together to solve real-world projects. This got me interested in the program and for the past 9 months I’ve been working with a company partner on their analytics project.
My practicum team has been working with an esports team to build out their analytics pipeline. We’ve worked with people at various levels of the company from the President, with the business plans/ideas, to the analysts who are diving deep into the data finding the key insights needed for the games the team is competing in.
For me this has been completely new. Most of my analytics experience has been in school working on homework and assigned projects. While these are great for learning and trying to better understand the analytics concepts they don’t reflect what it is like to work on an industry project.
The practicum project has opened my eyes to this in multiple ways. For this article I’ll focus on two interrelated concepts I haven’t had to deal with in the past. The two concepts are: defining a problem and documentation is king.
Are you ready to dive in?
Whenever I’ve worked on a homework or a class project I’ve always had clear instructions. Classwork might occasionally have a somewhat ambiguous question or two. It’s easy to ask the professor for clarification or if they aren’t available I can determine the question from the context.
With business problems, there is no professor to answer your question about the assignment. You need to do your own research and work with other people in your team/company to define what needs to be done. The practicum project has been great in helping me learn more about how to define a business problem and why it is important.
When my project first started I was excited to get started working with esports data and the API where we would pull the data from. I immediately wrote a script and started to pull data to try and work with. I knew I would have to deal with this data eventually and wanted to get started early. However, I had failed to consider the necessity of focusing my efforts towards an end goal. My eagerness to dive into the project and get going ended up being wasted effort as what I accomplished with the initial exploration of the data didn’t make a huge impact on the final project.
My practicum group didn’t know what the esports team needed from us. Had I taken the time to consider what was needed for the project I could have better focused my efforts towards reaching the end goal.
Initially my practicum group failed to realize we were on a different path from where our project needed to go. We believed we understood our project based on the initial prospectus we received. However, as we started getting further into the project and we spoke more with the coaches and analysts who were going to use the dashboards we were designing, we realized our approach and understanding of the dashboards was not what the coaches wanted or needed from the project.
Once we started to interacting with the end users and the key stakeholders we learned the way we had been approaching the end goal was not what they needed. With this insight we began discussing in more detail about what they needed and wanted from the end product.
“Principle 8: Try honestly to see things from the other person’s point of view” — Dale Carnegie, How to Win Friends and Influence People
This quote from How to Win Friends and Influence People perfectly describes how we needed to start looking at our project from the end users perspective. Not as something we can jump into and quickly complete but more as something which we need to build for others to use and adopt in their daily lives.
This experience showed me how the first idea you might have relating to a project isn’t always the best or even what the project needs to achieve success.
Tie stakeholder goals to questions and key performance indicators. — MIT Sloan
This quote from the MIT Sloan publication describes what is needed to get the buy in for the people who will be using the project in the long term. If you don’t ask stakeholders questions about what they need then they won’t care about what you’re building. As a result, the work you’ve put in to build the project is not going to satisfy the needs of the stakeholders.
Where was that written?
reaching a clear understanding across all of those different backgrounds and roles is a particularly difficult goal to achieve. Good documentation is the major tool we have to meet that challenge — Analytics Body of Knowledge
Without documentation where would our knowledge be today?
Many find it painful to record what they’ve completed so others can build off it. There are many different excuses they might come up with for why they don’t need to document something. None of these excuses are valid.
I have a few quick questions for you to consider: How is knowledge generally passed on to the next person? What is something we have all likely used at some point in our schooling? What media has been around for more than several centuries, even millennia, and were prized possessions of the rich and wealthy?
My answer to the first question is: written word. When you do a search online you’re usually going to try and find an article, document, book, or Wikipedia page to read and learn more about the topic you searched. All of these pages, except maybe YouTube and similar sites, have been written by someone to pass on their knowledge to someone new.
In the second question I am referring to textbooks. I know I’ve had a lot of textbooks over the years. These tomes are filled with knowledge that people have learned over generations of research, study, experimentation, and failure. These books are a perfect example of how without documentation knowledge could forever be lost.
My answer to the third question is: books. Before the printing press was invented books were hand written on expensive materials. Other than these rare books, available only to the wealthy, information was passed on by word of mouth. After the printing press knowledge has been able to spread like wildfire as people increasingly documented and shared what they completed. Without all this documentation we wouldn’t have been able to build the kinds of technology we have now.
In the case of our practicum project I am thankful the tools we used have had many people working on and perfecting the documentation. When we started this project none of us had dealt with any cloud infrastructure before and we relied on the documentation companies like Google and Tableau provided for their services. These companies have done their best to make the documentation for their products accessible, easy to understand, and complete.
Defining the business problem and documentation are interrelated. It is important to define the business problem and what you know to start with, how you got there, and why you made the decisions you did. This is where documentation is key as documentation of what you have completed will help others expand on what you have developed.