Where Things Go Wrong

In Episode 4 of Hard Hats & Data Chats, Fraser Gallop and Steve Gross dive into the real reasons data initiatives fail in construction — and why it’s almost never the technology. Drawing from real project stories, they unpack issues like data silos, inconsistent definitions, user‑created workarounds that break reporting, and the cultural gaps that undermine even the best systems. This episode highlights the importance of governance, stewardship, and cross‑team communication in building a trustworthy data foundation. If you’ve ever wondered why your dashboards don’t match your spreadsheets, this one hits home.

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

Steve Gross 0:00

Hi.

Fraser Gallop 0:01

Welcome to Hard Hats and Data Chats. I'm here at Fraser Gallop with Steve Gross. And today our topic is where things go wrong. We want to talk about the truth about why data initiatives can fail in construction. So, Steve, we're on episode four now. You know, it's been a couple of days since we chatted last. What's new with you?

Steve Gross 0:22

Well, I just took delivery of a new bike. I'm a cyclist and uh I'm I've been marveling and tinkering with all the technology on this new bike. It's got a couple of things that are pretty interesting. Uh for one, it's got uh the the rims, the wheels, have uh tire pressure monitoring TPMS system. Oh, nice. That you can connect to your computer and you so you I can get readouts of my tire pressure on my Garmin computer. And uh the other thing, I've got uh the uh back, a taillight strobe that's also got a radar in it and uh uh another product put out by this same company, and it also syncs with the the Garmin computer. So on my Garmin computer, it will show me a little like bogies of oncoming.

Fraser Gallop 1:13

Oh wow.

Steve Gross 1:14

And if there are two cars, I'll see two bogies, you know, and it's in a it shows approximate distance and all that, so and it flashes into red when it's getting close. So, you know, just warnings of traffic behind you.

Fraser Gallop 1:25

So this is this is all technology that we have in cars, but you you've got it in the bike now.

Steve Gross 1:30

Yeah, it's just crazy. And so so I'm you know, none of these things make me any faster, but it's kind of fun to play with and configured.

Fraser Gallop 1:38

So for sure. Well, and and you then you get all this data that is like accumulating, right? Uh yeah. It's it's not just I got some exercise. I went this many kilometers at this average speed and gained so much elevation, like it's it's uh this many w watts of power output, it's got a power meter in it too.

Steve Gross 1:58

So you know, nice. Anyway.

Fraser Gallop 2:02

So we've in our office here, we we have these big Lego sets and we do the team building activities where we all kind of build the big Lego set together, you know, like 8,000 pieces. And we actually had a fire in the office uh just over a year ago. And so uh we we did lose some Lego, it turned into puddles of plastic, but some of the the larger sets, they just they just smoke and soot on them from the fire, and not all of them are still made. So we we decided we're gonna clean the Lego, we're gonna rebuild the Lego. So we we actually found out that the the best way to clean fire damaged Lego is in an ultrasonic cleaner. Uh we ended up getting a big like 20-liter ultrasonic cleaner through the Lego in there with some cleaning solution, and we're able to clean up the Lego, and it's all back in the office now. So that's something that's been been around with us for for many years, and now it's back in place. So that's uh a bit of a calming restorative thing after the disruption of the fire event.

Steve Gross 3:00

Wow, yeah. I'll bet so hey, did you see where the a Norwegian ambassador as a gift gave, I don't know, some dignitary country of Egypt, the president or the premier or something, a uh a Lego set of a pyramid. That's kind of cute, I thought.

Fraser Gallop 3:17

There's a whole aftermarket too for resale, and they have the free gifts that they'll give sometimes in the stores, and those things are actually the most valuable. So you can see they were a free gift and then they're they're worth hundreds of dollars on on the resale sites. So it's uh it's yeah, it's interesting how that's uh just evolved over the years. Absolutely is. Yeah. All right. Let's talk about our topic where things go wrong. I think we've both been doing this for a while. Uh, so we've seen lots of examples. I said in today's episode, we're gonna have lots of examples of where things go wrong, not necessarily um because things are going wrong all the time, but also because that's usually when they bring in consultants and experts is when things go wrong. So I, you know, one of the ones that we've seen a few times is this idea of uh data silos where people are doing their own thing with the same data and having their own interpretation of the same data. One of the examples that I went through was uh actually it was to do with safety reporting. And so part of the safety reporting and safety metrics is you had to show the number of instants based on uh, you know, how many man hours have been have been worked. So the the challenge was coming up with the number of man hours. If you went to the CEO and asked about man hours, he actually went to the safety report to get his number for man hours. He didn't go to HR, he didn't go to operations. It was always off the safety report that he would get that number. So we went and we talked to the safety report people and said, Where do you get this number from? And they said, Oh, well, we run this report here. And so we documented and said, okay, that's fine. And then we went to the accounting people and said, So how do you get the number for the number of hours? They detailed their process, was which was slightly different. Um, and so okay, let's let's go talk to the jobs and see how they count hours and yet another variation, right? They're just using the job cost and the hours that are getting posted to their jobs. Then the fourth one was HR. So again, just another example of they had a different calculation. So within this one company, four different uh numbers were being reported for the number of hours that that they had been working.

Steve Gross 5:20

Oh my gosh.

Fraser Gallop 5:20

Um yeah. So the the the what the challenge and the outcome was is that we got all these guys together and we were able to decide this is how we count hours. This is what we exclude, this is what we include. The way that their system worked was things they had incentives for the employees. If they were on that pay cycle, like a travel incentive and things like that, it actually came through one hour on on their time cards. So that was inflating the number of hours, and so we had to exclude all of that to get kind of a true number. And we were able to come out at the end of it with a trusted number that everybody was on the same page. Yeah.

Steve Gross 5:55

So you know, another example of something like that that I've come across is where a user, a group of users will customize a system to make it do something that it's not designed to do. And sometimes this is because of a lack of understanding of what the design is or related things, but they they do these short-sighted, I would call them, changes to how something runs to achieve some short-term goal, but then it totally takes away from the system's ability to provide the main report. We have a customer that does a lot of time and material billing, they do a lot of cost plus work, and they have some rules about markups, and so they bypassed our main system, not knowing about some of the markup capabilities it had built in, and they built their own markup table and their own report that ran from that, and it was a very restrictive result. User issues can break reporting, and in this case, it's needless customization or customization where they're not really understanding what the rest of the system is doing.

Fraser Gallop 7:00

That's I it was last week or the week before we we had a similar conversation uh in regards to forecasting, and the company had their forecasting process that was manual. And I was I was with another colleague, and he's like, You well, you know your system does do forecasting for you. And they said, No, no, no, it doesn't. Yeah, yeah, it does. We can show you in the menu where the forecasting tools are. You don't have to, you can actually make use of that. You didn't have to invent something on your own necessarily, like budgets. Uh budgets was another one too, where people they'll do their budgets in Excel like as they do. And we've said there's a budget module, you can load all that information back into your database and then report alongside your GL transactions. So, oh really? Yeah, there's there's you should use it. Yeah. So I totally get that. Yeah. And another one that I was kind of working with uh was this idea of inconsistent definitions um potentially between systems. We were doing a BI project, and part of doing the BI projects is we're you're trying to get some trust with the users because it's a new system, they're looking at their data in a different way. So we were working with uh COO, and he wanted to do some analysis on um like the rates when they do their budgets, they have the per hour rate is gonna be. He was trying to do an analysis on that and say, what were our our budget rates and then what were our actual rates that we're getting on the job? We built the the reports and things to show that, and things were just off. And he's like, is there something wrong with the BI? Is it not refreshing properly? Are you not bringing in the transactions properly? We had to go and dig deep and try to figure out what was going on here. And no, everything's refreshing properly. Transactions are coming through just fine and it all looked good. So we ended up tracing this down to an Excel spreadsheet that they used in estimating had fuel coded with with the wrong cost type. So the fuel was actually such as man hours or something. And so when the fuel was coming in, it was just throwing all the numbers off because different orders of magnitude from the rest of it, and that's what it was. But it got traced back to inconsistent definitions and how many jobs were they using that template where they had to go back and you know fix the cost types on on stuff.

Steve Gross 9:17

So inflating their cost per man or per unit complete.

Fraser Gallop 9:22

Exactly.

Steve Gross 9:24

Well, that'll do that if you include fuel in uh in a production.

Fraser Gallop 9:27

Exactly. Yeah. So just making sure that everything is defined consistently throughout the cost types are the same cost types in your different systems, those are key things.

Steve Gross 9:40

Yeah, I I you know I have an example like that too, where one of our customers that does a lot of negotiated work, they wanted to be able to bill the folks running the job at a billing rate or costed at a billing rate. That's right. Costed at a billing rate. They didn't tell the accounting folks they were doing that. And uh so when it came time to recognize revenue, all of a sudden their margin had gone gone down the toilet because all of a sudden they were they were including a higher rate for these highly compensated people that were running the job. And uh so their supervision margin was way lower than than they had originally started with. So there's another example where the left hand has to be talking to the right hand about what they're doing in terms of costing you the job.

Fraser Gallop 10:20

Yeah, exactly.

Steve Gross 10:22

Yeah, so that's interesting.

Fraser Gallop 10:24

Yeah. Uh what else do we have as good examples of where things can go wrong?

Steve Gross 10:30

Well, you know, a lot of it, I think, also comes down to how you're managing your team, don't you?

Fraser Gallop 10:35

Yeah, it was actually interesting. Yesterday we were on a call, we were talking about departments, and and we had IT director and one of the controller roles, and something wasn't lining up with departments, and uh the the IT director was a little bit annoyed because people are going creating new departments, but they're not following the process to create a new department. And so the naming is different than the convention that they came up with and agreed to as a team, and it's not just uh that the system allows you to create the new department, you shouldn't necessarily go and create the new department. There are lots of times you you have to have coordination on these things, and there are conventions that the company follows, and it's not necessarily in the system what those conventions are, but having that open dialogue with your teammates so that you can set things up properly for success.

Steve Gross 11:25

Yeah, absolutely. I think the other aspect of that that's worth mentioning is that uh the way you collect data and the accuracy of that data, the timeliness of it, all of those things are very important in certain kinds of reporting, cyclical reporting, which is virtually all of it is in construction. You know, it's weekly, it's monthly, the more timely the better many times. But if if the data is not clean, if you're not following the right parameters of getting the data entered, if it's not been given the proper priority, if you're just doing a excuse my language, a shitty job of getting your time entered, your units, your forecasts inner, they don't really reflect accurate reasoning. All those things are gonna affect the end result of your reporting. And and I think everybody's gotta be on the on the bandwagon. We all have to be following the same drummer, the same orders as it were in terms of how you do things on a weekly basis and what's important and all that, or the results are just not gonna bear out when when you view the dashboard or view the end result.

Fraser Gallop 12:27

Yeah, that's for sure. Like the idea that leadership needs to be involved is really key. It also relates to this idea of data governance that we're starting to hear a lot more now. The idea of appointing data stewards to different areas and different systems. So the idea with a data steward is that's the kind of the person that's responsible for their area. So maybe it's job cost, maybe it's HR data. They're the ones that take the responsibility within the organization to make sure stuff is filled out properly and entered like they expect. A great example of that is is with HR data. Uh, you collect information about demographics and some of it's optional, but we've generated employee statistics reports and seen a lot of non-NA null, you know, in there. And that's where having a data steward is really important so that they're the ones that kind of will take that on and say, okay, we do need to make an effort to clean this data up and make sure that we don't have a bunch of null values and we are getting real values so that we're able to provide valuable reporting around things.

Steve Gross 13:30

Yeah, absolutely. And field validations help there too. But when I first started my career in construction software, I started out in the implementation role, helping customers implement a product. And I found that same approach, having appointing people to be responsible for certain parts of the system and how clean the migrated data was was really important. You know, somebody had to own that because there's lots of detail to that, keeping it clean and making sure it's being done properly. That's really true on it with a reporting project, too. Somebody's got to own it and be checking it and make sure once it's been kicked off that it rules are being followed and it's it's been implemented cleanly, or or you're just not going to see accurate results.

Fraser Gallop 14:10

Mm-hmm. I'll I'll give you another great example that that I encountered one time. We were doing job cost dashboards and showing original budget, revised budget, cost of completion, those kind of things. One of the views was kind of comparing what the actual cost was with the revised budget. You looked at the job and it was like this this PM was just like he was he was rocking. He was like every every single uh cost code, it's his actual cost was right on his budget. It looked almost too good to be true, right? And so people questioned the data and you know, we went and you know, what's going on? Let's let's go look into this. So it turns out what what he did is as he got further into the job and some of the the tasks and things were finishing, he had money left in his cost codes. What he was doing is his budget adjustments to move that extra money in those cost codes over to the other cost codes that were maybe not doing so well. So if that basically fueled his result of, you know, I I'm I'm broke breaking even on all of my cost codes is is uh you moved the budget around so that he broke even on all the cost codes. I don't know what the follow-on discussions were with his managers and how that landed, but um, I can just hear that discussion.

Steve Gross 15:19

We're looking for resourcefulness, but not this kind of resourcefulness.

Fraser Gallop 15:22

Yeah, exactly. You know we we've talked about a few good examples where things go wrong, but really it the failures and where things go wrong are not typically going to be system-related or technical type failures. They're more cultural, structural, process-related things. Having good uh collaboration between team members, how they're approaching things, and making sure there's consistent process is really the key to having successful data culture, data governance.

Steve Gross 15:51

Absolutely. You know, just because you have the data out there doesn't mean that it's going to be used efficiently or in a way that will provide an advantage or an improvement to the bottom line, to margin on a job, or keeping to schedule. I mean, you just have to do the whole picture. You have to have to manage the processes as well.

Fraser Gallop 16:12

Oh, great. It was uh good talking to you again this week. Uh, I think that uh we're into May now and spring has finally sprung. So it's uh at least here uh we're we're people are out uh got landscapers going and cleaning up and everything like that. So it's nice uh that we're uh you know finally getting past winter. Now you're down in Arizona, obviously, so you don't have the same seasonal changes, I guess, as the rest of the year. That's true.

Steve Gross 16:38

There are changes, but they're pretty quick. Yeah. You if you don't, if you don't aren't really paying attention, you'll miss them. So you know.

Fraser Gallop 16:47

All right. Well, if you if you haven't subscribed, please subscribe to to our podcast. Uh, we're gonna be back again in a couple weeks' time. Uh next episode is gonna talk about the real challenges and and how to overcome them. Oh, I can't wait. So looking forward to speaking to you again soon, uh Steve, and we'll talk again. Thank you. Thank you, Fraser. Bye. Bye bye, I think.