The Real Challenges and How to Overcome Them

Fraser and Steve break down the real challenges behind successful software and data deployments—why they happen, how to avoid them, and what teams can do to build a strong foundation. They cover the essentials: getting early buy‑in, cleaning and standardizing data, defining meaningful KPIs, integrating systems properly, and building trust through training and transparency. As Fraser notes, “we won’t get it right the first time,” so iteration and feedback loops are critical. The episode closes with a look ahead to Fraser’s upcoming Tableau presentation and the next topic: What Good Looks Like.

Learn more about Steve’s work with eCMS Cloud Construction ERP Software at  Computer Guidance Corporation or Fraser’s work transforming construction data into actionable insights at Onware.

Transcript

Fraser Gallop 0:00

Welcome to Hard Hats and Data Chats. This is our fifth episode, The Real Challenges and How to Overcome Them. So I am Fraser Gallop, and I'm here today with Steve Gross. Good morning, Steve. How's it going? Quite well. Good morning to you. What's new and exciting? Any new uh bike gadgets to tell us about this week?

Steve Gross 0:19

Well, no new gadgets, but some new plans. So I'm going to be doing a gravel race in Steamboat Springs, Colorado next month. And I'm trying to decide if I'm going to fly and put my bike in a case or if I'm going to drive. So that's my big uh debate that I'm going through right now is how I get my myself and my bike there so that uh I can participate in this race. So anyway.

Fraser Gallop 0:47

You see these guys traveling with bike cases. Um I see them at least in the airport from time to time. And I'm always like on their behalf, I'm a little bit nervous, like knowing that the way that those guys handle our baggage and like just like throw it, right? And then you got this like crazy fancy bike, and and you're you're trusting these airline guys. So I can identify there.

Steve Gross 1:09

There's definitely risk involved. So I've had to do I've done other races where I've flown in and one time in uh it's another part of Colorado, and I had to do some last-minute wrenching to get the bike put together properly. So hopefully that won't happen this time. I have a better case now.

Fraser Gallop 1:26

So okay. What about you? I'm actually leaving tomorrow morning. I'm going to Paris. What? Uh for for a bit of a family vacation.

Steve Gross 1:36

Oh my gosh.

Fraser Gallop 1:37

Yeah. So it was uh I I was on the fence for a long time, and and my wife is like, you know, let's go, let's go. And so I I kind of I finally caved. But it requires a lot of uh kind of pre-planning uh these days uh for go for going to these cities that have like all the different tourist attractions. The the last time we went, we we tried to go to you know many of the the tourist stuff like Eiffel Tower and the Louvre and Notre Dame, and and every place had these huge lineups, and you couldn't actually go the day of. You have to pre-purchase your tickets ahead of time. This makes me think of like when I was a lot younger, I would like plan a vacation and say, um, this morning I'm going here, this afternoon I'm going here. But in recent years, I'm just like, ah, I'm on vacation, I'll figure it out as I go. And now I have to go back to this mode of kind of thinking ahead of time. And, you know, you got to buy the tickets ahead. Um, I feel like this is like a holdover from COVID and you know, these time entry windows where they just kind of put these precautions in place and now they've kept them. You have to really plan ahead when you go on these trips if you want to do the tourist type stuff.

Steve Gross 2:49

Good luck with that. That sounds fantastic. I hope it all collides together.

Fraser Gallop 2:52

I I have I have little appetite for lines, so we'll see how the live works out. So today we we wanted to chat about um real challenges and how to overcome them. Subtext, the theme here is, you know, kind of building the foundation for doing software deployments and and data deployments and working with data. And the first kind of thing that we wanted to kind of talk about was this idea of getting buy-in from teams. In the ERP space, maybe you could kind of tell us a little bit about how you go in there and set up uh the deployments.

Steve Gross 3:22

Yeah, you know, it's the worst thing you can do is uh decide you're gonna do something at the executive level and not involve teams in it. And uh so we we try and avoid that at all costs. We we pull in as many of the team leads as possible as early as possible. And I think one of the secrets is assigning ownership to certain sections of the project. So in this, in this example, I mean, if if you have multiple dashboards are going to be rolling out, you might identify an individual that will own that dashboard and be a QA and support vantage point for the rest of the organization. Just early on, establish who those people are. And then secondly, you know, the vision, the corporate vision that's driving this, everybody, this team that you're assembling, they need to be disciples of that. They need to totally embrace that idea and and believe in it, you know. So, so just activities all surrounding getting them on board with that kind of an approach is really well worth it. Time invested is well worth it.

Fraser Gallop 4:27

Well, especially when you're doing an ERP type deployment, it's not like if it fails, you can necessarily go back to the old way of things. You're preparing the whole organization for this shift to happen. Right. And if there's a goaline date, it's gonna happen on that date. Um, so you you kind of have to get all the ducks in order and stuff to be able to make that happen, right?

Steve Gross 4:49

Yeah, where this can be this is a little more difficult in that it it whether or not you use the product we're describing here at dashboard, some may view that as optional, you know, and and it uh it's not as cut and dry. There, I would think there would be a much more importance and in that upfront effort to get everybody bought in and and sold on the idea.

Fraser Gallop 5:11

Yeah. When we when we started working with Tableau many years ago, they were still in kind of startup mode as a company. And their thing that they like to say was land and expand, where they would just sell one license to an analyst, rely on that analyst to get other people on board and expand within the organization. But it it's harder to do that because that analyst is not necessarily a decision maker for the entire organization. We still think that the better way to go is to get the executive and the C-suite engaged and on board with these projects at the start, because they're going to basically be the sponsors, be the key people that are going to push the rest of the organization to kind of follow through and be part of the process. So getting the teams on board was the first piece. The second piece that I think for building that strong foundation is cleaning and standardizing the data. There's a lot of different kind of questions that you ask. I think they're the same questions when you're deploying an ERP, when you're setting up a data warehouse, you may have years and years of history in in existing systems, and you don't necessarily want to bring that with you as you go. What are some of the things that you guys ask in in the questions that kind of you would go through when you're doing a migration from one system to another and questions about the data that you would want to ask and establish before you kind of go down that path?

Steve Gross 6:27

Well, one of the obvious ones is duplication, duplicate vendors, duplicate customers, just whatever your database is that you're talking about is is some something represented multiple times. Getting that cleaned up. Because like in ER ERP implementations, you know, this kind of a project, if your data is not in good shape, it's going to show up pretty, pretty predominantly when you uh view it in some sort of a graphic or a some sort of a report. You want you want the data to be cleaned up so that it's you can get the impact that you're looking for and the results that you're looking for. So another, you know, basic step that's well worth the effort is the cleanup involved to get your data in good shape.

Fraser Gallop 7:13

Yeah, the one that we get and we see quite often is that this idea of who are my top customers? And executives know who their top customers are, but you go and you connect up to data, and lots of times you won't see the customer that you expect as the top customer because it's actually split into maybe five different companies, because they have different locations, they want you to bill slightly differently, but it's actually all the same customer. So one of the tasks is sometimes identifying those hierarchical hierarchical, if I can say that properly, relationships. So like all those customers tie together under one line, it does reflect that they are my best customer because you know, we've actually got it split out into different places. And you can do that drill down and see how that distribution works, but identifying those relationships is kind of key. One of the other ones that we get when we're looking at setting up data warehouses also how many, how many years of data do you want to have? Uh that's a good one too. Like what do you kind of typically migrate if you're doing a migration? Do you only look at five years of data? Is there a rule of thumb or is it different every time?

Steve Gross 8:15

Well, that's a good question. Because, you know, it it actually adds some difficulty in migrating data if you're filtering out past a certain date. I mean, there's just more to that. But it's also a very good consideration because older data tends to be less organized. You know, this whole what we were talking about a minute ago, if you go back 10 years, you know, there may have been some bad practices in play at that point that makes that data less useful. So, I mean, it uh that's very astute. You know, you need to really zero in and understand the history of how that customer got there, that client got there, and the changes they've gone through in their in their capture of data and their record keeping, and you know, really zero in on what's relevant that will help the readers of this output in making decisions and so on. If it's garbage, it's it's not going to help that much. It'll just skew things. So that's a really good point in terms of the age of the data, what makes sense there.

Fraser Gallop 9:09

Yeah. So cleaning, cleaning and standardizing data is a must-task to build, again, back to building the foundation. The other thing that we usually talk about a little bit when we get started is what are your KPIs the organization uses? Building kind of data projects, and you know, if we think about like the first project is going to be our executive dashboard. The executives have a one-stop shop, they can kind of see everything on their executive dashboard. It's not necessarily just regurgitating the income statement and the balance sheet and giving you that. You've got to go a little bit further. So when we talk about training, you know, data analysts, the thing that we tell them to do is to always ask what questions are you trying to answer with this data? Don't tell me which columns and rows you're looking for in the report. Tell me what kind of questions you're trying to answer. So you're trying to calculate DSO and DPO from the accounts receivable data. We don't need to know what rows and columns you're interested in. We need to know what that end goal is. Because oftentimes you'll see where people build a report that just has stuff from your income statement, your balance sheet, and then they just export that into Excel and then they do those manipulations over and over again every month. If we can capture what are you doing in Excel after you export the data, that's how we can provide the best value because we can just give you those numbers directly. We can automate the piece of exporting and calculating these things over and over, doing those pivot tables so we can give you that end result directly. So your KPI is actually that end result, not all the work that you had to do to get there. What are some of the other things that you might do when looking at KPIs and trying to identify that?

Steve Gross 10:44

Well, earlier we were talking about the importance of getting the right buy-in, but there's another side to that, and that is getting the right person that understands the business and where the exposure is. Uh, and to help you with what those KPIs are, you know, within construction, the different vertical markets, the different types of contractors, that can change drastically. Like, for example, a mechanical contractor, very labor-intense. What I've learned from some customers in that niche that I've dealt with is that the name of the game is understanding how much labor you need. Not only from the perspective of being able to carry out the projects that you've won, but also in terms of keeping your talented team busy. What is that benchmark you need to reach to keep your workforce out there productive? And at the same time, don't overcommit, don't sell so much work that you don't have the resources available and you have to start hiring temporary contractors, which eats up your marger quicker than anything. So a lot of forecasting into labor requirements. And then if you're in heavy highway, it's material requirements, equipment requirements, that sort of thing. You need some guru to help grow the business, help you identify what those KPIs are. And you know, if you can do that, then the dashboards really are wonderful.

Fraser Gallop 12:07

You know, they make a that domain expert that has the years of experience and trying to tap into that. Exactly. Use that. Yeah.

Steve Gross 12:14

It may or may not be somebody in the finance team. They may have come in from another industry. You know, you need that, you know, that person that grew the business that understands, you know, where the exposure really is.

Fraser Gallop 12:26

Before they retire, right? Yes. Yeah. The next thing I wanted to mention on here, too, getting into this idea of integrating systems effectively, what are you doing in Excel after you export the data? There may be a systems impact there because they're doing some manipulation of the data to get the result that they want. That's where like we can look at that and we can say, well, maybe you need to use a custom field in your database to capture this at the source rather than applying it in Excel after you've done the export every time. Well, our paths have crossed many times in the past. And I don't know if it was you on a call or somebody else, but we were talking about custom fields, and they actually showed us how there actually wasn't a limit on the custom field. You could use more and more custom fields, and there was a way to accomplish that that was part of the database. And so we were just amazed and we thought, that's great. Now we can start putting all of this into the source database. We can use that in the reporting. You just have to change the process a little bit, but then everything's gonna flow a lot more smoothly because we've got the data in the right systems, we've got that integrated nicely.

Steve Gross 13:41

Developing that attribute, you know, and making it available in the reporting is so important. And the good news is usually you can do that.

Fraser Gallop 13:48

That's usually not a, I mean, as long as you identify it's and it's yeah, it's really it's not that hard. It's just getting everyone aligned, getting the right teams, getting them aligned. In terms of integrating systems, we we talk a lot more these days about setting up data warehouses and setting up semantic layers. The reason that we're doing that, especially today, it is to kind of get the data ready for AI. Because one of the things that we're not doing a podcast about AI, we're doing a podcast about data. But the idea is that if your data is nice and clean and you've kind of built this data warehouse, you've gone to the troubles that cut it up nicely, you're going to be a lot more ready for an AI deployment. Taking raw database table names and column names that are not human readable, gibberish most of the times, and translating that to something that the AI can understand so that it has more meaning. One of the great examples that I've recently been playing with is this idea of pulse metrics. So you have a data source that has data coming into it every day. You know, it could be like time cards, for example, and you can hook up these pulse metrics and get the daily report to see how you're tracking this month versus last month, what the forecasted number of hours are going to be to month end. Those tools are getting way better than they were just a couple of years ago. And uh what I saw is the one that I use it now has an AI connection. So I can just ask the LLM questions about the data in natural language. And I can say things like, I don't have to say username. That's the, you know, it the field in the data set is username, but I can say which person or you know which team member. And then the AI can make that connection for me to say, oh, I'm actually talking about username and give me information about the user. A time saver. Yeah, it's it's huge. And because the data was kind of set up correctly in the first place, once those AI features got turned on, I could just use them. I didn't have to do any additional setup. Um so that's um a lot of this is setting up things, thinking to the future, and and we're trying to get it right so that we don't have to do rework uh later on.

Steve Gross 15:48

That's a really that's a really neat insight. I mean, it it's kind of that's just the next level of cleaning up your data, really, is making sure it lives within these parameters so that machine language can run with it later on, you know. I mean, that's that's kind of probably the essence of learning to work with AI, you know, is understanding that.

Fraser Gallop 16:07

Yeah. Um, and so talking about AI, that's another great uh segue here. Because then the next thing that I wanted to talk about was this idea of building trust in the data. We are gonna build something, we're gonna deploy something. Training is definitely part of that and getting the teams on board to use them, but uh it's also building trust. How do you guys typically approach rollout plans when you're doing appointments?

Steve Gross 16:35

We make uh put a lot of emphasis in uh in a sandbox approach, uh allowing them to do the proper testing. They're they're not really testing software, they're testing the process and and their workflow and to make sure they're that we've accounted for the exceptions, you know, and and also it's familiarization. Half of training is familiarization. You can go through a bunch of classes, but if you don't actually sit down and use it, you know, day one, go live is going to be scary for you. So it's to you know, alleviate that stress of the newness of a of a new system and a new workflow. Well, you know, in that same vein, this kind of a project lends itself to that as well. I mean, to be able to understand the drill downs and just conceptually what you're looking at, if you can mock that up in advance using some historical data and use that as a training tool, wow. Those people are going to be, number one, much more likely to use the thing and number two to understand what they see.

Fraser Gallop 17:38

So yeah. Well, and you have to have that go through the basics, right? Like how do you connect? And I kind of feel I'll just assume people know how to go on the web and log into this tool and access these things. And that's not always the case, right? There's such a wide variety of skill levels and experiences that that are out there. You do have to have that rollout plan and kind of go through it. Um one of the examples that I had about building trust in the data is having a place where you can explain what are the data, where's the data coming from? What are what are some of the calculations and the formulas that are in use? A new user doesn't need to see that every day, but they need to have like a reference material in terms of things like data refreshes. The traditional thing that we would have is date stamp. If we were going to PDF a report and start distributing that to people, we would want to have date stamp on there to say, when was this report generated? Um it's the same thing in in dashboards, right? Like you want to have when was this data refreshed? When when is this data coming? Where did it come from?

Steve Gross 18:35

Very important in construction. I mean, it's such a timely business. You know, it's it's a it's a business where the, you know, it's it's you have to be able to react quick enough to fix stuff before it's too late.

Fraser Gallop 18:46

Yeah. And if you're looking at last month's export, you're probably too late already. The other one that we did was we we had a an executive dashboard that we were building that had maybe five different data sources that that were kind of coming into it, like all these different data feeds. And the challenge that we had was that they they just want to know is the is the data good or is there a potential problem? And it it actually becomes, you know, a difficult question when you have a bunch of systems that you're consolidating together. What if your your your job cost data is correct, but then your payroll data is behind? So we actually made just a little indicator. Um, it was just a green and yellow indicator. So if all the data had refreshed like we expected, we gave it a little green dot on the dashboard. But if one of those data sources was not, we we would show it as yellow. And then they could click through to see what was successful, what was unsuccessful, and kind of make that decision on the data. Um trying to distill it to just that little indicator in the corner so it's not overwhelming, it's not in your face where you're trying to get your data, but you have that little assurance that you can trust that everything's working like it should be.

Steve Gross 19:54

I bet that really helped.

Fraser Gallop 19:56

Yeah.

Steve Gross 19:57

You know, another thing on on training, going back to that, I was thinking of that I think would really be valuable is you have to, I think, once you roll roll something like this out, it has to become integral to the review process within your company. You know, and so like if if I'm managing work for a company, projects, inevitably I'm gonna be sitting in some sort of review meeting on a monthly basis going through my jobs. Why not, you know, and a lot of our customers they have some key report that they use to drive that meeting. They're reviewing this report. Why not make it the dashboard? Start with the dashboard, use that as a segue or a drill point into the details of the project and make the people use it. Make those users, you know, explain things that you see on the on the dashboard. And that that is what makes it what's the word I want to use? It's it's just it's it's commonplace to use that tool.

Fraser Gallop 20:56

It's a it's a generally accepted tool when you're as a focal point for for the like the meetings and the discussions, yeah. Yeah. Even internally, we try to practice what we preach, right? And so when we have review meetings, I have one coming up here in in a couple hours, like a monthly review. It's actually bring up dashboards and go through the dashboards. We're not necessarily going and running the reports ahead of time during the meeting. We can just come and review the dashboard, see how things are going, point out the problem items and discuss them. So yeah, you're you're a hundred percent there. Um the other thing about overcoming challenges and moving forward is this idea that we won't get it right the first time. So it's it's gonna take more than one shot. We're gonna have to iterate to get it right. If you're having those regular meetings and whoever's working on dashboards and reports as part of those meetings, they can hear from the users to say, This is working really well for me. Um, this is not so much. Can we swap this out and put something else here that would be more useful? Take that communication to know whether you're getting it right or not. I like to say if we're not. Hearing from the end users, then that means we we've either got it 100%, everything is working great, or they're not using it at all. Right. And it's like, how do you how do you know the difference between the two? We can go and look at server logs, mine that information and see if if people are clicking on things, but it is really important to have those conversations that are ongoing to say, yeah, you know, what's working well, what's not working well, um, how can we iterate, how can we make it better.

Steve Gross 22:29

Um well, I think that also speaks to the importance of not trying to pull off too much at once and to make it make your project winnable, make make it something that you can really succeed at. You know, you get this much done, they're using it for this reason. Okay, now we're gonna phase in this. You know, it's it's it's a step-by-step process, it really is. And uh otherwise, you know, there's a pretty, pretty high risk of something not clicking right and and or something not being rolled out properly, and that no one uses it. You know, that's and and like like we were saying earlier, you know, it's not uh you know, these things can be optional if if you allow it to be, whether or not they're used or not, can be optional. And that, you know, first of all, you gotta structure it so it's not optional, and secondly, you gotta structure it so that what you do roll out is you know, smash and success and everybody likes it. And you know, that's that's the goal, of course, is to get that get that um readership and that usage level high.

Fraser Gallop 23:29

Yeah, exactly. Get the minimum viable product and then improve upon it. Um requirements later on. Yeah, it's it's that's what I'm trying to say.

Steve Gross 23:39

You know, something achievable, you know, make it don't kid yourself on trying to do too much at once.

Fraser Gallop 23:46

Yeah. So that's the big takeaway from today to overcome challenges and deployments and trying to roll out software and introduce new things, it's coming from aligning people, process, and technology. All three are are equal parts of the puzzle. It's not just buying the technology and putting it out there. Um, it's it's not gonna succeed on its own necessarily. Uh, next time we're gonna talk about what good looks like. I think it's gonna be a bit of a challenge. We titled the episode What Good Looks Like, but of course it's not necessarily a video podcast, it's just a podcast. So we'll have to be very descriptive when we talk about this next time because we won't be able to show and tell necessarily. In the next couple months, we have a user conference. We're gonna see each other in person at that. So we'll look forward to that. The other thing is uh before the next episode lands, I'm also gonna be presenting my Tableau conference session. So earlier this month, I was presenting a session on building KPI dashboards for company leaders. On June 9th, I'll be presenting that to a Team Data Fam Tableau user group. I'll put a link in the show notes if people are interested in seeing that. Otherwise, we will uh meet again in a couple weeks here for what good looks like. So if you haven't subscribed, please subscribe now and we'll talk to you again soon. Uh Steve, enjoy your bike race. I'm I'm interested to see what the results are next time we chat.

Steve Gross 25:04

We have to set the expectations properly. Finishing might be my expectation.

Fraser Gallop 25:10

That's that's if if that's the goal, then then that's the goal, right? As long as and having fun and and you know just getting it done is is is also like big, right? All right. Have a good weekend and we'll we'll talk again soon. See ya.

Steve Gross 25:27

Bye.

Fraser Gallop 25:28

Bye.