Getting Started with BI is Simpler Than You Think - Part 2

This piece is a continuation of this one (Part 1).

Q: It’s important to finish strong in the “last mile” of the analytics process to uncover insights that will inform business decisions. What are the key considerations around creating compelling dashboards and telling stories around data?

CJ: If we think about dashboards in the same way that we might think about a car, we may like what we see in terms of flashiness and look and feel of the car - but it won’t work unless everything that it’s created from inside it is correct and of high quality. The engine, the body, etc. In a way, dashboards follow the same idea.

Another analogy is like a painting on an easel. You’re presenting a painting but it needs to be held up by the easel. So, we need to make sure the easel foundation is solid by setting the right goals and will help us remove the right problems, achievable through data.

Once you know what you’re trying to achieve, it’s a very simple 3-step process when developing the dashboard or story.

Start with a summary. Offer a quick-glance view of data that you’re trying to show, whether that be for managers, or for end users, or at the individual level - something they can log into and see the most important data at the click of their fingers. This will remove the time to market in the decision-making process.

Provide the ability to understand what drives the data in the summary. So if we’re talking about a top-level revenue summary, what are these numbers made up of, and what are all the income streams? If you’re a YouTuber, for example, you might have 5 different channels through which your revenue comes in. The top summary will be the top-line revenue, and what drives it is the different channel splits.

Go a step further and deeper. What drives those channel splits that make up your revenue? What might explain the bigger picture? This could include the different demographics and times of people watching, etc. So it’s about having a “data pyramid” that you’re looking at that you can drill down further into, where you can open up the next level of detail.

This way, you’re looking at the data in small meaningful chunks, rather than looking at everything all together which you would normally do in Excel.

Each individual dashboard or even table needs to have its own individual purpose. If we take every semi-related report that’s created and throw everything on one dashboard, that’s going to make it much harder to actually analyze it, or get insights, trends, or patterns from it.

It’s easy to feel inclined to do this - but I would wholeheartedly suggest breaking your data down into meaningful chunks, creating multiple different individual reports that sit under one tree, that you can easily flick over to compare and contrast. From there, you can do interesting things like separate the data to show your most important KPIs at the top of the page, and what drives that, in a single view.

For example, you should take the most important piece of data and just put that in a single box at the top left, so that captures your attention immediately. If you want to see your lead generation, you could track the leads, the opportunities you create, and the opportunities that you close. And those could immediately be the top 3 blocks on a report. It then breaks down into drill-downs of each. Just remember, main summary and KPIs at the top. The goal is to solve a purpose at the end of the day. If you’ve set your purpose and you can tell the story, it’s like providing evidence to that purpose.

Q: Do you have any suggestions for boosting data adoption across the company, beyond the data team?

CJ: You couldn’t have asked a better question because the biggest blocker is trying to sell something to someone who doesn’t understand what they’re buying into. They have no idea how it works and why it’s important.

So, I always come to projects by telling people that working in BI and embracing data isn’t going to change what they do, but it will enhance what they already do. A lot of people don’t like change. Change can mean difficulty, and it can also mean greatness, but there’s uncertainty either way. So if we’re coming up to a group of people and saying, “here’s what we can do to enhance what you already do and make your lives easier”, rather than, “here’s what data can do to change what you do for the better,” you’re going to get a lot quicker adoption.

This is super important because the end user is the one driving the decision-making process, but you need to guide them. They’re the bowling ball, and you’re the guard rails. You give them the lane and let them travel down it, and you can help guide them this way or that, but they need to make their own decisions. Otherwise, they won’t ever agree or align with you. And that’s how you get a company to adopt data - allowing some room for individuality in the process.

The first impressions are huge and you will get good first impressions if you are giving the client or individual what they want, at a first glance. Getting that first impression right, doing it the way they want you to, but also enforcing restrictions on how they “travel” through the process, is the best thing you can do.

Q: What about streamlining collaboration between business users and data teams?

CJ: This is an incredibly common problem. For every piece of work that I do, I categorize it either as 1) ad-hoc (no need to involve the business) 2) larger scale project (do need to involve others in the business).

If it’s a larger project, it’s important to detail the responsibilities and the accountabilities of people that could be part of the team, and create the team. For example, at my previous role, one of the big things I worked on was Finance reporting and ARR. In this team, I included our Revenue Operations Manager, as someone who understands data and is close to the Revenue side, and our CFO as the key stakeholder.

Then, I would only really deal with the Revenue Operations Manager who understood the data, and relied on him to bring it to the revenue teams in the way they would best understand, as the one that’s closest to them. Over time, the Revenue teams would learn and adopt the data through him.

It’s important to choose these 1-2 “representatives” from each team, who can be data champions or advocates across other teams, empowering them to get through to their teams in the way that resonates best. I would then meet with these “specialists” or “super users” with whom I can have an ongoing conversation, as opposed to chasing down all internal team members. The Revenue Operations Manager was basically my trusted “voice” from the revenue teams. This creates a more seamless and frictionless collaboration that saves time by channeling it through one data-savvy person.

Trust and simplicity is everything with adoption, so try not to “scare” anyone with a data team barreling in and acting like they’re going to change everything. Instead of telling a constructor that they should be building their house differently, just give them nicer tools to build the house with. That’s much less daunting.

At the end of the project, enablement and training on self-service is incredibly important. Otherwise, you’ll have bottlenecks from the start. Writing up your documentation so you can keep a view of what work has occurred, but then you also need to impart the knowledge to super-users, who will advocate and educate the rest of the team on the data project. The super-user can deliver their own trainings to the team, but it’s key to enable those 1-2 people. They can then serve as the voice of reason for their team.

Eventually, you get to the point where every team has “the BI person”, as opposed to one person in the center. You can then scale data up team by team as opposed to going through the centralized, bottlenecked “BI guy.”

Q: What advice do you have for people starting out in BI?

CJ: Don’t be intimidated! It can be really, really simple and easy. Just start on a small set of data, and make sure that once you set your requirements and objectives, don’t move your goal posts. Projects often take a lot longer and can become difficult and annoying to deal with if requirements chop and change throughout the project.

Test your requirements with the data sets that you put through in a very small, controlled environment initially and ensure that you’re reaching towards a fixed goal. Get to the end with your first approach, and then you can expand it out to the rest of the company’s data.

Questions or comments for Connor? Reach out to him on LinkedIn here!

Whaly is a self-service business intelligence platform that can simplify your BI projects by offering tools that empower both data analysts and non-technical business users to work with data. Sign up for a 14-day free trial here!