The Dashboard Effect

Expect Iterations on Your BI Projects

January 25, 2023 Brick Thompson, Jon Thompson, Caleb Ochs Episode 63
The Dashboard Effect
Expect Iterations on Your BI Projects
Show Notes Transcript

Click here to watch this episode on our YouTube channel.

In this episode, Brick and Caleb discuss the likelihood and value of iterating your BI solutions. You should expect and embrace it.

Blue Margin helps private equity owned and mid-market companies organize their data into dashboards to execute on strategy and create a culture of accountability. We call it The Dashboard Effect, the title of our book and podcast

 Visit Blue Margin's library of additional BI resources here.

For a free, downloadable copy of our book, The Dashboard Effect, click here, or buy a hardcopy or Kindle version on Amazon.

#BI #businessintelligence #adoption #PowerBI #Azure #Synapse

Brick Thompson:

Welcome to The Dashboard Effect Podcast. How are you doing, Caleb?

Caleb Ochs:

Good. How are you, Brick?

Brick Thompson:

I'm doing well, thanks.

Caleb Ochs:

Great.

Brick Thompson:

So today we're going to be talking about why it makes sense often, almost always, to use an iterative approach when you're doing BI projects.

Caleb Ochs:

Yeah, I mean, not much more to say than that, right? That's what you should be doing.

Brick Thompson:

So, we talked about this beforehand, and some of the reasons that were clear, really were, if you don't plan on doing an iterative approach, the lack of flexibility can really come back to bite you. So when you're creating reports, especially, but even when you're doing data architecture, you often have an idea of where you need to go. A pretty good idea. In fact, you may be positive you know exactly what the report should be. But what we find over and over is that once users actually start using dashboards and reports and data, their eyes open up. They start getting ideas. And if you're not planning upfront to come back and iterate those reports, it can be kind of a bummer. You can end up with something that's just suboptimal and not meeting the goals the way the users would like.

Caleb Ochs:

Right. You have to plan on that happening. I don't know how long we have been using our own reports. For years. Me, myself, I've been doing this stuff and looking at these types of reports ever since they came out and really started gaining popularity. Seven, eight, nine years ago. And I still have that, "Ah, let's do this." And then it gets on the page and I am like, "Ah, no, we need to change that, and this needs to be here," or "This wasn't worthwhile at all." And, you know, it just happens, and you're better off just embracing it.

Brick Thompson:

Yeah, I think that's right. And it's funny, as you said, even us. I mean, we're good at this, we do this for our clients all the time and for ourselves. And sometimes you just don't anticipate the ideas that are going to come once you finally start seeing the data on a page.

Caleb Ochs:

Yeah, right. And by the time you see a report anyway, you've probably advanced your thinking a little bit since the inception of the idea.

Brick Thompson:

Yeah.

Caleb Ochs:

So you've got new stuff, and those things are going to happen. And even when you have a good report and you've dialed it in, in a few months you're gonna want to tweak it and change it. And if you're lucky, it's a few months. Probably in a couple of weeks.

Brick Thompson:

Yeah. Well, businesses change and how people think about things change, and what problems they're dealing with in the business change. And so, I would say, just anybody who's contemplating a BI project, just sort of know upfront, have an expectation, that iteration is going to be critical.

Caleb Ochs:

Right, exactly.

Brick Thompson:

I think one of the problems too, and I've seen this happen, if you go into a project thinking we're one and done, you're almost shutting off feedback from users. So they're giving you recommendations up front, and you're doing your best to do a design, let's say you're the IT department or the BI guy. If there's not an expectation, though, that it's going to iterate, the users may disengage, and actually not adopt very well. And so I think it's even important for users to understand, "Hey, this is an iterative process. We're gonna do our best to implement exactly what you've described that you need, to answer the questions that you need to answer, make the decisions that you're hoping to make with this. But we have an expectation that we're going to be able to make it even better once you start using it and realize exactly how to dial it in."

Caleb Ochs:

Right. I mean, that makes me think of the flip side of this too, which is you would do a ton of upfront work to try and dial in the right thing, and then ultimately give it to the end user. Even when you do that, you still fall back into this. So you're right, like you said, to set the expectation that this is how this is going to work is really important. And not fighting it. There is a kind of a balance though. You want to make sure that you're getting good information up front, and you're getting to, "What questions are you trying to answer here?" Not just, "Oh, you told me you needed a pie chart, so I'm going to build you a pie chart." It's "No, why? What's that going to do for your business?" So once you can get to those areas, then you can start that iterative process and make sure that the expectation is set with the user, that this is not going to be a one and done thing.

Brick Thompson:

Yeah. And no pie charts by the way. Ever. Also, I think if you're taking a viewpoint that this is one and done, you sort of squelch collaboration. So again, let's say you're having your IT department do your BI. And so they're engaging with business users and gathering requirements and then building out reports and dashboards. If the underlying understanding is,"Hey, we're just gonna get this nailed the first time," you're less likely to get the collaboration to actually get it to be good. And sometimes, it's just the littlest change, a 10% change, that takes a report from being, "Yeah, this is useful information," to "Oh, this is transformative. This is actually driving what we do day to day and making our business better."

Caleb Ochs:

Right. Yeah, a good, good way to dial in on those things is to get a version one out there. Watch somebody use it or let them use it, and then, a lot of times what people will do, is dump that data out to excel and do something else with it. If you can see that, and watch them do that, and say,"Alright, what else are you using this data for?" You can build that into your reports, and people don't have to do that anymore. It just gets that much better.

Brick Thompson:

Yeah, exactly. So what are some of the things that happen after you deploy a report that causes the realization that some iteration is going to be necessary to get it really dialed in?

Caleb Ochs:

That's a good question. So, it's interesting actually, to think about how this does play out. Because, you know, you put something in front of somebody, and let's say it's pretty close, like, it's pretty good. They're just not used to having that. Right, you haven't had this information before. That's what made these tools so important, and have kind of spurred the business we're in, is that it enables this new type of data analysis that just wasn't really accessible in the past, where you can click on a data point and the rest of the page filters. And when you're not used to having something like that, you get that put in front of your face, it's like all this information in these doors just open up, and the gears just start turning.

Brick Thompson:

Well, there's definitely that and then there's just the fact that with this information, people will start acting on that information. And that will lead to new areas of inquiry and interest and things that they want to see. And so that'll change what you want to see, a lot of times, on the report or you will need another report to supplement it, or some kind of drill through, that type of thing.

Caleb Ochs:

Yeah, you might find a huge hole in your business process that needs to be filled in before you can go any further. Right? It's like,"Okay, well, now that I've seen this," and it might just be a small, little sliver of the report. The next step might be,"I need a report that shows me where this process is breaking down," right? And so you go do that. And that's kind of that iteration that can make BI and a tool like Power BI, or whatever else you're using, super valuable and making changes in your business to actually see that ROI.

Brick Thompson:

Yeah, the other thing that can happen is once you start using a report, you realize you have data quality issues. And so then you go back and start correcting those data quality issues, start doing some data quality cleanup or master data management, that type of thing. And then once you see the data after it's cleaned up, realize "Oh, okay, now I actually know where this report needs to go."

Caleb Ochs:

Yeah, that's a really important one, because it could change the whole of what the reports telling you if you get your quality cleaned up.

Brick Thompson:

Yeah.

Caleb Ochs:

And getting that done, and then saying, "Oh, okay, I thought the data was this way, it turns out it's that way. Let's make the report look like this."

Brick Thompson:

Yeah. Well, there's also just the effect of having a report out there. Now there's just this flood of information coming in, and all sorts of new discussions and brainstorming and so on will be going on.

Caleb Ochs:

Right. It just enables things you didn't have before. So its like, "All right, let's actually dig in here." And you can start finding interesting new things. And that's when that iteration is so important, because you want to capture and capitalize on that new thinking that you've just enabled yourself to do.

Brick Thompson:

Yeah, and I think the other thing that leads to, or contributes to that, and possibly needing iteration, is just the business getting used to using these reports. So, the business may not have had good visibility into things before, and so now that they're getting it, it may take some time to get used to it. And we've definitely seen that internally. We'll put a new report or dashboard out and we'll use it for three or four months, and it seems like it's really good. But as we're using it, we start to learn things that then drives us in a different direction. And so you just have to sort of be ready for that, I think.

Caleb Ochs:

Yeah. Right. And let's say you solve one of your problems, then you don't really need that report, maybe not in that form anymore. Like the example I'll give you is, I think in our Expert Insight Series, Tanya was talking about how they have an initiative for their CRM hygiene. So, just cleaning up their CRM. So they built some reports to give them good analysis and, "How clean is our CRM." Once you've got that and your business processes are much more solid and you've used the tool, you probably don't need that at a detailed, line level reporting, that you did when you were trying to clean up your CRM. You probably now are able to look at higher level numbers, and you need detailed reporting somewhere else. So those things will shift around. They'll change as your business changes, as you evolve, you get better at things, some areas of your business fall behind, you're gonna need to be flexible there.

Brick Thompson:

Yeah, that's a really good example. It makes me think of another example that we did to ourselves. We talked about this many months ago. But last year, we switched from doing hourly billing for our projects to just doing a fixed price for projects. And it broke a lot of our reporting. In fact, we didn't even know what we needed to know, in order to manage our projects well, until we started doing it. And so we had we had to redo a bunch of stuff for that.

Caleb Ochs:

Still redoing it.

Brick Thompson:

Yeah, as we learn more and figuring out how to approach it better and think about it better. Yeah, it's true.

Caleb Ochs:

Yeah. I mean, just this morning, we thought of almost another metric that might be interesting to look at, like the difference between overall profit and project profit. The difference between those two is an interesting discussion. But those are the types of things, just seeing it on the page you're like, "Oh, well, that one's really high. That one's very different. What's does that mean? Why do those two things correlate?" I mean, we could do that and it would be interesting. But anyway, so that's just an example of the thinking that it can spur.

Brick Thompson:

Yeah. All right. Well, I think we'll wrap up. I think it's important really to re-emphasize that people, as they're going into a BI project, whether it's internally or with a partner, like us, or however they're doing it, just be ready to iterate. And don't put everything into that first draft. I mean, do a good first draft, because you don't want to have adoption issues because you've got data errors, or you've completely missed the mark. But get that first draft out there, start doing user acceptance testing and realize,"Okay, there's gonna be some adjustment that happens in here."

Caleb Ochs:

Right, and you want the organization, not just the end users, as we've just talked about, you want the organization to have a good expectation of what this BI initiative entails. It's not a one month thing, and then we've got BI and we're good to go. It's like, "No, it's going to take a little while and we're going to do multiple projects. And then we're going to have something that's a little bit more encompassing." Even at that point, you're still going to be tweaking, so it's kind of a never ending thing, but it's very, very valuable.

Brick Thompson:

Yeah. And I think even if you love your first draft, which is often the case, because you haven't had reporting, so you get a first draft of something out and everybody's thrilled because they're actually getting some visibility now. There still should be an expectation that you're going to be coming back and making it better.

Caleb Ochs:

Right, right. You want to do that.

Brick Thompson:

All right. Well, I think that's it. Thanks, Caleb.

Caleb Ochs:

Thank you.