Data That Pays: Better Data Without Burdening the Field

To, another HCSS webinar, a June edition, about the HCSS and the utilities market, although it's not strictly about utilities and utilities construction. I'm Frank Baumgartner. I'm a product manager in the utilities space for HTSS. I'm joined by two other folks, Darius Elder, who I'll say more in just a second and let him introduce himself and Emily Nabulsi, who is an HDSS Product Manager. Before I go too much further into kicking this thing off, just some webinar logistics. We have q and a. There's a q and a button where you can ask questions. You can ask them any time. We'll figure out if we're gonna answer them on the spot or kinda queue them up for the end. If you see chat, it's probably disabled. Don't use that. We won't be looking at that if for some reason it's enabled for you. Darius, I'll introduce you. He's a previous customer, which means there's probably some folks on the call that know him, maybe worked with him. So just disclaimer, we did not plant any questions. We don't have any people. No loaded questions, please. I'm just kidding. Ask away. Darius is a colleague and a friend. He is now with PG Partners or I shouldn't say with. It is partly his company. They are an HCSS consulting partner. We could talk more about what that means at some point, but basically, he is somebody that you might work with to help you understand your business and business processes and, for instance, how to use HSS products in alignment with your business. He's a previous customer, like I said, but now he is here to help us learn from his expertise. He has a lot of utility industry experience. So, Darius, rather than me trying to figure out how to explain you, go for it. Tell the folks a little bit about yourself and why they should care about our witty banter today. Sure. I'll try to explain myself. I've been trying to explain myself for a long time. So I gave you a little bit about my background. So I actually started in the field. So I was a welder a long time ago, and I did a little bit of little bit of everything in the welding space, did a little bit of pipeline welding as well. And then I went to work for a utility, did other things, but I ended up working for a utility company. I worked there for almost twenty years, kind of went up and down throughout the utility, worked in the design phases, worked ran construction crews, ran emergency response crews on the gas side of the business. And then I got involved in kind of finance side of the business, really trying to drive process improvement and operating and maintenance and capitalization cost optimization across the utility. So we spent a lot of time looking at business processes and data and and the way that you can use data to drive performance and improve your your kind of overall business both from the field performance and kind of the data that the field would need to collect and what those processes look like. I've, left the utility, about three three years ago and spent, two years before starting PG Partners, working in the third party construction space. So I was in a role where I kinda sat between operations and IT for a little while and then got involved in an HSS implementation at that company and spent the good part of that two years kinda going between multiple divisions across the company and even got involved in a few different companies within the overall holding company umbrella to help with HSS implementations. We focused really on heavy job, but and a lot of what we'll talk about today is in that space and and all around this, you know, idea of the field first, right? And making sure that the that we made sure to consider what the field has to do and how they do it and the outcomes that we're trying to achieve from an accounting perspective but not thinking of it just purely from accounting. So, it was, I've done a lot of different things in the utility space. And so, you know, was very, very fortunate to know the work on both sides, the the contracting side as well as directly in the utility. Oh man, you, you kinda nudged us towards a bunch of interesting topics there. So let's dive into it. I'm gonna show everybody kind of four key takeaways to prime your mind on, what we're gonna be talking about today. And Darius, really you really hit on some of these already, that when these companies are thinking about how to be profitable and they're thinking about it from different angles, from operational angles and IT and finance angles, they can have a lot of different ways that they think about their data and what to go gather. So, one of the challenges that I really learned from working with you as I kind of explored and learned about the utilities market is that the way that some of these contracts work can drive a different way of thinking about their data and the granularity of the data and, like, how practical it is for them to record at this really high detail level. So we're gonna talk a little bit about the granularity of this data and and the idea that that has a cost. Gathering data and owning data, doing stuff with it comes with a cost to the business, to the crews, to the people who have to gather the data in the field. Another takeaway is just how do you balance these metrics between finance and operations? They're they're both trying to achieve, you know, same business goals, but the data that they need to do their job day to day is not necessarily the same. So talk a little bit we'll talk a little bit about how to balance those two and how, you know, operations, for instance, can support the financial metrics that need to be gathered around the business. A third one is just this idea that if you burden your crews, maybe overburden is really the right way to think about it, you can incentivize them to do things that you don't want them to do, like pencil whipping their data and gathering data that's there but not necessarily useful. So we want you to take that away and have some examples in your head of how that could happen and what you might do about it. And that really leads to the last one. Just what are the ways that you could get past the fears of lacking the data that you think you need in order to solve problems? More data seems great, and that's a fear that I think many of us might have, is wanting more data. So how do we get past that? What are some some good ways to deal with that? I'll leave those up just as kind of a way for us to think about this conversation. But let's dive into framing the problem. You hit on some of this. When we talk about utilities work, it's not all short cycle work. It's not all MSA giant contract work, but a lot of it is when you're delivering services to residences and businesses, municipalities. And that style of work comes with a pace and an impact on the planning and the realities of how much data you can gather and expect from a planning perspective and then an actual actuals perspective. Can you dive a little bit into that core problem that you really surfaced to me about like, hey, you can't do everything. The business often wants to gather everything and the field can't do it. Explain that problem a little bit for everybody to kind of connect to. Yeah. Yeah. Yeah. So, probably the easiest way to think about it is like, well, what is, what's the basis of the contract? So, when you, especially in the distribution space. So, if I just put aside like, you know, big transmission projects, pipeline projects, big electric transmission projects, or substation work, or those kind of things and said, hey, if we get down to large numbers of crews that are doing a lot of work within one day and a lot of work being a discrete work order that you get issued from the utility, right? So, you're going to go out and you're going to replace a service and you're going to replace, you know, a dozen services or you know, realistically, you know, five to seven services in a day or you're going to put in, you know, you're going to put in joint trench gas and electric utilities to feed customers and you know, really, the processes that you're going through to do that work is, you know, you're digging a trench and you're, you know, laying pipe in the trench, you're putting conductor in the trench, You may be doing connections up at the meter. You may set a meter. You may put a meter bar in place, and the utility is gonna come at you with the contract and and and everybody on here has probably dealt with these contracts where the units go very, very granular a lot of times. Right? You might have to deal with things like specific materials that you're gonna bill for. You might have to deal with things like, you know, the fusion or the connection back at the T back to the main on the gas side of the business or, you know, the hot work is separate from the not hot work if you're doing, you know, distribution electric work. So the tie in or the energize is is a separate unit. Sometimes those activities are very, very granular, but they have a cost or a billing amount that you're gonna bill back to the utility. So you go through this estimation process and you generate these units that you're gonna bill back to the utility, and you use things like man hours and equipment hours and those kind of data points from historic work to figure out what those bids should be. And the inclination, a lot of times when when it's and I I don't wanna wanna want this sound bad, but when you're thinking of it from purely an accounting perspective, you're looking at it, you're going, okay. Well, I wanna know how much time and equipment cost goes into actually executing that work at that finest granular level of work in the field, whatever I'm billing back to the customer. Right? So, you know, it might just be, like I said, like, the fusion or the tie in. It might be the tap if you're do if you're tapping a main. It might be, you know, actually laying the pipe in the trench or gathering the as built data post construction that are all separate units. And, when your crew's out there in the field and they're actually doing the work, right, they they're doing this, you know, kinda sporadically around throughout the day. Right? So they're going to kinda stage the job, and they're gonna potentially trench, and they're gonna have, you know, two members of the crew up at the meter that are getting ready to set the meter, and they're gonna have, you know, maybe a laborer helping to dig and get ready for where the tie in's gonna be. And and then you got your fuser down in the ditch, and they're actually fusing the pipe. And those might all be separate units, and your foreman's kinda running around between all of them doing the work. Well, the foreman has this burden to collect all this time and equipment and labor and equipment cost makes up the cost of the job, you know, ninety percent of the time plus material. And so if you ask them to go out and collect that information at that finest level of detail down at that specific pay item or billing item level and say, hey. This is how much time it actually took for me to execute this. The burden or the the, the burden to gather that information or the effort for the foreman to try to break up the time between the different crew members and specify this person is doing this and that person's doing that. A lot of times is longer than the amount of time that actually takes to do the work. Right? And so you really don't wanna create this unnecessary burden, but you know that you need to be able to collect cost in a way and revenue, data in a way that'll help you drive performance in the future. So you have to think about it when you're setting up HCSS. You really have to think about kind of the structure of the data inputs and, you know, what level of granularity is important for you to gather that'll get you the outcomes that you need, but not looking at it purely from that accounting perspective, looking at it from both the field and the accounting perspective because that number three is absolutely true, right? If you put too much effort into a process around paperwork, anybody who's been on a job site, you'll hear the crews say, right, like, worst thing of the day is doing the paperwork. Like, it's the, it's the worst part of the day, right? And there's, you know, they do it to get it done, but don't necessarily, right, care about the outcome. So you gotta think about how do you tie the outcomes of what they're doing and the data that they're collecting with some value back to them, like payroll and those kind of things. But also, what is the right mix, right balance that gets you the data that you need to drive performance and change within the crews and be able to compare across crews, right? Performance between foreman and crews, performance between maybe geographic areas or conditions based off what's happening in the field and what type of work's being done or even just the type of work itself, right? But not necessarily down at that minute level where you're going to end up with, you know, that pencil whipping. You know? Somebody's just kinda peanut butter spreading hours across a bunch of units because they really it it's too difficult to try to nail down five minutes on this and ten minutes on that. Right? So that's really kind of the problem. And you have to think about that all the way from the beginning of the work. Right? So when you start to implement any tool to do, you know, field data collection that's around cost and revenue, specifically heavy job. You have to think about that as you kinda structure your datasets and you're looking at how you're gonna ask these crews to do the work and not just think about it, but talk to them and ask them what they think. You mentioned some things, about potentially collecting data based on work type or at the crew level. So that's starting to drill down into some getting closer to some specific examples of how you might organize your data as opposed to just getting down to the individual unit level. What I guess that's kind of the solution side of, hey. What am I asking my field to gather and how might it be organized for them so that when they're sitting there in the truck, they're recording the right stuff and the rest of the crew is not sitting around waiting. But if we go back one step to, okay, they're doing this because somebody in the office running the business, IT, finance, accounting, they have some metrics that they need to track that indicate success. Tell us a little bit about that side. These are the folks perhaps making the first ask, either in coordination or maybe not with operations, which I think is a topic in and of itself. What are what are some of those metrics that they're looking for? And, I guess, give us some some color on, are those the right metrics, and are they practical? Can they be tracked? Yeah. Yeah. Yeah. I mean, well, the biggest thing that I saw was, you know, again, I don't mean this in a bad way. I'm a probably caveat myself throughout this webinar. But, you know, a lot of times, the structure of an organization makes up what you kinda go after when you're doing a software implementation like this. Right? The IT people are out there gonna do the software implementation, and there's not a ton of IT people with, you know, field experience and that kind of field knowledge. And so you really gotta lean in on operations. And then the IT folks typically roll up through the CFO. So you have people from the back office that are trying to manage accounting and people in the implementation team that roll up to them that are thinking about this from a technical perspective. And how do you make the software work? And how do you implement it to the most granular level possible and that all sounds great until you actually try to put it into practice. So, they might be trying to gather things like I said, right, at the most minute pay item and trying to track labor against them, that pay item. But that might not be the best way to think about it. It might be better for you to think about it. You know, I'm I'm going back into that solution, but it might be better for you to think about it from, well, what operational metrics make sense to the folks that are actually overseeing the crudes. Right? The the local VP or the local director or the local ops manager or even superintendents that are trying to oversee a handful of crews within a specific area and they they need they need a metric that'll say, you know, Frank's crew and Emily's crew are doing the same type of work, you know, geographically doing the same they're running into the same conditions in the field. They're actually doing the same, you know, like, type of work, like, service installation versus main installation or, you know, primary stringing primary versus, you know, stringing services or whatever. But you don't want to necessarily say, well, how long crew member in Frank's accrue, how long did it take for you to actually, you know, tie the primary phases to the top of the pole to the to the ridgepins, right? Like, doing a a wire tie is just not a big deal. It's just a step in the process of actually executing the overall work. Right? It sounds really good because that's what you're actually billing back to the customer. So you need to capture quantities for those things, but you might not need to actually understand the distribution of the cost itself against those specific quantities. And and that's what I've seen is that kinda struggle between I'm thinking of this purely from an accounting perspective and an IT perspective versus I'm really trying to think about this from the crews perspective and the fields perspective and I was really, really fortunate to work for a company that in the third party construction that was very much focused on the field first, right? Like, go talk to operations, talk to the crews, spend some time on the job site, and then, as I mentioned, right? I have this background where like I was actually in the ditch at one point and so, you know, I don't I I'm always trying to look for a way to give the least amount of burden on the construction folks because those are the folks actually out there making money for you, right? Those are the folks that, they're the reason that that the business exists. The rest of the people that are around it, IT, finance, my role, right, that's to support those folks that do that work. And so you you really need to make sure that you don't create an unnecessary burden because you're trying to, you know, for lack of a better way of saying it, right, count all the beans. Right? Like, you wanna make sure that you got the right kind of mix of metrics that'll help you drive your business. And we can talk about those too, right, from the operational perspective, what I heard and saw some of those key metrics look like. We definitely should dive into those. And You said something. I remember several projects that I saw with you and some of the things you're saying really resonate because I kind of saw you working that way and trying to steer the business. It wasn't a quick decision about, oh, what do we measure? What do we not measure? And then I've seen some other projects where they clearly were trying to, like you said, count the beans, to really record to the x degree and it was creating a volume of data that even they sometimes struggled with. And I guess we were forecasting that it was going to be a challenge for the crew, but that still brings up the question of, like, but that's what they wanted to do. And so, there's a gap between what somebody was trying to accomplish and what seemed reasonable and valuable. So, there's, like, some misunderstanding there. So, I wonder your viewpoint on, like, what what was missing between those two? I feel like maybe it's just not experiencing the real world examples, like you're saying, of, we said, yeah. They pencil lip. Okay. But what does that mean? You do some out, like, well, I mean, the foreman could be sitting in the truck for an hour recording data while the crew's just sitting there. That's not operationally profitable. So I I guess do you have any thoughts on what are some real impacts that helps somebody out there connect with, like, oh, yeah. I see what I'm doing if I if I ask for things that are unreasonable. Yeah. I mean, first things first. Right? Go out there and watch the work get done. You'll see the form and like, I remember one job site we pulled up on. You were with me when we went out and did a field visit. We pulled up on the job site, and the foreman was actually in the ditch digging the hole with a shovel. When we walk up on the job site or actually cleaning out the hole that was already dug, and the miniax is sitting up to the side, and he's down in the hole, and he's got a shovel with the labor, and they're trying to clear out the hole. We walk up, and these, you know, IT guy IT guys walk up, and they wanna ask him about the work that he's doing, and he's down there doing work. Right? And so, you know, you got, he's trying to solve problems. He's trying to help them figure out what's the the next step. He's trying to keep them busy. He's trying to make sure they're safe, right? They've got all of these things that are on their mind already as a foreman, right? They gotta go through their tailboard in the morning. They gotta make sure they identify all the safety hazards. They have to think about those safety hazards throughout the day. They gotta make sure that their crew stays busy. They got three to four people sometimes that they're directing throughout the day. I mean, they just, they don't have the time to sit in the truck at the end of the day for an hour and fill out the paperwork but if you can make it as easy for them as possible but still get the information you need to bill the customer and manage the crews. That would that's really the key. Right? So, what I would say is first things first, go out in the field and watch watch the work and you'll see the foreman, you know, they they don't have the time. They don't have the time that I I think maybe sometimes we think they do to, make sure that their time sheet is is filled out to the nth degree. Right? It's to that level of detail. So a lot of the things that we tried to do was say, okay. Well, how do I let the data in the background kinda manage that, gather the information that I'm looking for, by adding attributes to, let's say, the employee related to where they are physically or the foreman itself to related to where they are physically or what division they're in or the type of work that they do if they're if you have crews that are dedicated to certain work types. You also wanna think about kind of the link between your ERP system, which is your accounting system, and the actual data that you're collecting within HeavyJob and think everything doesn't have to flow between both. Right? So you could say, you know, I wanna have data that's purely field metric related that lives in heavy job. But then as it synchronizes back into the ERP, I can still understand cost at maybe the ERP job level, which is sufficient for you to, you know, manage all of the corporate metrics that you need to show that your business profitable. So you still need to feed the P and L. So I'm not saying that. I'm just saying that you might not need to feed everything from heavy job back into the to the accounting system, or you might not need to feed everything from the accounting system into HeavyJob, and you wanna make it as easy for the crews to gather the data that you need to execute the work as possible. Right? By the way, everybody, when he mentioned that I was out in the field with him and then he jabbed me for slowing his foreman down, that was real. He told me that on the spot. But it was also a good learning moment because you do realize once you get there, you're like, Oh, that guy does look slightly annoyed that I am slowing him down and I'm clearly wearing a button down shirt. He's like, Man, you don't belong here. Alright. That's very real. So, can we drill into what are some specific metrics? You're illustrating the problems and what the finance and IT and accounting folks want to gather, and you've thrown out some ideas on kind of hazy level of, like, how you might gather this instead. Can we drill in a little further? What what are some specific metrics that are valuable that you can actually gather in the field without being too burdensome? Yeah. What I heard from operations and I'll say that I heard this from the ops leaders. Right? Like, I didn't come up with this. It's not like, you know, I sat in a room and said, these are the things you need to drive performance. But what I heard from the operations leaders is that the kind of key metrics were especially on distribution work. So high volume, short duration, or short cycle work is what I called it. But high volume, short duration work that are work orders where you're going to do more than one a day, typically, right? You're going to do four to five work orders a day. Maybe it's even two or three, but you're going to do more than one. And so now you're talking about work, an entire work package being executed within a portion of a day, right? And you got three or four people that are executing that work and they might be jumping between two or three of these work orders at any given time throughout the day. So what I heard a lot of times from operations was, you know, revenue per man hour and cost per man hour were kinda key metrics. Right? And and normally, they wanted to see that at a at a couple of different from a couple of different viewpoints or filters, right? So, you wanna see that from the crew level. So, the foreman. So, what was your revenue per man hour at the foreman level level and your cost per man hour at the foreman level And how do you gather that data so that it's easy for the foreman to fill that out? You do wanna see cost performance typically at the work order level, but more importantly, it was kind of that type of work that I mentioned. So, you gotta think about like bucketizing the crews into certain types of work and and for anybody who's running crews out there or implementing these type of systems, you kind of already do that naturally, right? Because you sign a contract typically with a a list of units or a scope of work within the contract, that's for a specific type of work. So, you might have a type of work that's joint trench, new construction. You might have just new business, gas, just new business, electric, And that new business gas and electric might be broken up between services and mains. Right? So from the gas side or primary backbone work and, you know, service drops or something like that. And then you may even end up with, you know, even more discrete types of work, like setting the meter, doing a tie in, those kind of things where you have crews that are specific to the type of work. And then within those types of work, you may need to go down, like, one click deeper. And I think some of the structure that we kinda worked on I I'll say it together. I didn't do anything technically, but I kinda, you know, worked with you to think about how to put it together. Was, you can have attribute data at the heavy job job level that maybe captures the work order type. Right? The work order. You could have type of work baked into maybe cost codes, but you may wanna break down your type of work just one level deeper. So if you have services, you may wanna see the difference between, like, short side and long side services because they're gonna take a little bit more work. It'll be a little bit different effort. You may have to bore underneath the road. You may for a long side service versus a short side where it's all open trench. And so the the activities within there may need to be broken down a little bit deeper. But it typically boils down to, like, you know, how would you be managing your p and l? So what's my revenue per man hour? What's my cost per man hour? And then what's my cost versus revenue at some discrete level, right, to make sure that you're tracking margin? If you think about those kind of things and don't try to pass don't try to create so much data that you're trying to feed, you know, actual straight back to your estimation process, but you're thinking about it at a level, you know, at the unit, like I was talking about before. But you're thinking about it at a level that you can drive performance and then still derive through, you know, other means that, you know, cost per unit or maybe the spread per unit against the specific unit, but not trying to use actuals, then you'll get kind of the best of both worlds where you won't have this bad data that's pencil whipped in because it's too granular, but you still have performance level metrics like revenue per man hour at the foreman, revenue per man hour or right. Yeah. Revenue per man hour at the work type and maybe even the work order level. And then I would tack onto that. You may wanna have other pieces of data. I just kinda touched on it second ago, like the location, the geographic location. And you can you can do all of that within the work order data itself or the heavy job job data by putting in address information or even, like I mentioned before, through the crew. Right? The crew, you could say the crew foreman works this area and has an attribute that says this specific geographic area is where they work. And that would tell you things like, are there conditions in the field? Is it a is it sand that they're digging in? Or is it rocky? Or are there other kind of field conditions that may be an explainable way to as to why you're gonna see a revenue per man hour, cost per man hour fluctuation for a given crew type. So you're gonna wanna be able to have those indicators down in the levels of detail, but you're gonna wanna be able to report at a a higher level like that revenue per man hour cost per man hour metric. So you just hit on that, the thing about documentation and and using notes and pictures. I wanna come back to that one because, I know you've you talked about using that as a way to click in without being, like, a burdensome piece of data to gather another number in a spreadsheet. It's more info that you can click into. So we definitely got to put a pin on that one to come back to. I wanted to kind of like recycle some of the things you said just to see if I got them clear myself and for everybody else. One is this idea that, like, a work order is often a a discrete work package that you need to complete and bill for and maybe to a degree report on individually. Although for a four hour work package, maybe that's less valuable to report on that individual one. But that's a clear unit of work. And in, like, heavy job, you might use a job for that. So you have this way of seeing that thing and tracking that thing and labeling it with things like tags so that she can see that that job has that job has a specific type of work that it is. And then you went down a level into cost codes or activities, same thing. And being able to break work apart that way, if those are an activity that are meaningful to track. And even there, just like job tags, can use Costco tags or something like that to figure out the different activities that you want to slice and dice for reporting. And then you went a level deeper, but I think what you're saying is no. Be careful because a level deeper is like a pay item, an individual unit. And there's often a desire to track all the costs for that specific pay item unit. And while that's doable in a heavy job, that seems to be where it can start to get burdensome as you have a high volume of those and a high volume of work orders in a day for a crew. You could even flip that and say, well, what about the hours that an individual spent? What are all the pay items they did for just their hours? Or really, what's all the revenue that they generated for the four hours that they spent? That one can also be burdensome. Again, doable. And that seems to be where you're kind of throwing up a red flag of of now you're really getting into recording a level of detail that is nearing the amount of time that they're actually spending doing the work. Right. Did I kind of capture that right? Yeah. I think you nailed it. So it it like you said, right, in heavy job, you can collect labor and equipment hours against the individual pay items if you want to. Right? You you certainly can do that. What I'm saying is a lot of times, the value that you get out of doing that is lower than the amount of effort that you get for doing that. And and remember, the people that are putting in the effort to do it are the people that are generating the revenue. So you're taking away from revenue generating activities in order to record costs at a pay item level, and that might not be the best way to think about it. It might be perfect for your business, and it might be something that you have to do. You have to record your revenue. So you're gonna need to capture all your pay item quantities, but you might not need to say, okay, try to figure out, did you spend ten minutes on that pay item and then thirty minutes on this other one and an hour on that other one? Even though it's it's possible, it might not be the best use of your field's time. And so you have to figure out what that balance looks like by learning how the crews actually do the work, by understanding how operations sees the problem and how they're gonna manage performance at the crew level. Right? What are the metrics they're looking for within the operations leadership, you know, superintendent general foreman, or even up to the, you know, senior leaders within the business that you need to be able to bubble up reporting on, not lose the granularity that you need to drill in when you see variances in those metrics by using things like tags or photos like you talked about, right, what you touched on. But don't burden the crew with trying to figure out, hey. This is how much time I spent on this widget. Because, I mean, I saw some time sheets that had well, it it was a problem that we brought to you guys. Right? We had over fifty pay items on a job. And so we we came back to HCSS. We were like, look. This time sheet's gonna have over fifty pay items on it, and we had to, you know, ask for some technical assistance at the time. And so if you have fifty pay items and you got a four person crew with four pieces of equipment and the job took four hours, how do you even break the time down? On those fifty ks pipes. I still have to collect the quantities but it it makes zero sense for you to ask the foreman to try to figure out how to spread their time there. So Yeah. What we tried to do was use things like cost codes or tags or those other kind of aggregators that you can build into HeavyJob to gather the data at a level that makes sense for the business to operate and for you to drive performance and figure out where your problems are and look for those outliers and have those outliers show up and ways that you can compare performance between crews, crew types, areas, work types, whatever, without putting that burden on the field. Yeah. I'd forgotten about that. That was, interesting. That's actually very early in us working together where you showed us a time card that had like fifty pay items on it. I can't remember. I think it was like some pretty large number of pay items per work order and then multiple work orders. And so it's just one of those logistics you don't think about is almost like a user experience problem. The time card itself was just big. A lot scrolling and lots of boxes and like, where do I the form is not gonna put seven minutes in each of these boxes. So which one do they put it in? Right? I remember us working through that with you on how do we roll these things up to something simpler and how do we maybe give you some data constructs you can use. It's a good reminder that it's not always just about the business problem. Also, sometimes the app itself you look at and you're like, my foreman's gonna hate doing this data entry unless we get this better. You've always had lot of sympathy for the folks in the field and pointing out they're not going to love you for the things you make them do. I know. I said that a few times. That's for sure. That's right. So you hit on some discrete solutions there, things like you can literally design your cost codes and further slice those by tags. You can design your work orders and your work order types and use those as buckets to roll up data and then record your costs at those levels, and you may have detailed cost actuals, but you don't necessarily report on those detailed Payroll? Sure. But you roll those up to these tags and these cost codes and job tags and etcetera, and the same with the revenue data so that your granularity is a little bit less and a little bit more manageable. Then you juxtapose that with this problem of, okay, so people have a fear of, if I'm not doing that, then I'm not gathering as detailed data and then a problem is found. I've got all this data, I identify a performance problem, and now I want to go say, what's the cause of that? How do I go get data that tells me that's the cause so that I can use that as, info and ammunition to go do something about it. Ammunition sounds aggressive. But, like, how do I use that if I don't have that data? And then you mentioned things like photos. So go further into that one. You this idea of, like, how do I click down one level and get what I need but not go overboard with collecting too much data. Yeah, yeah. I mean, it's, I think that's all part of like your business process and your initial kind of system design, like you said, right? So, you go talk to the crews and you talk about the work that they do and you talk to the superintendents and you talk to the billing team and you figure out how do they need to bill back to the customer, what level of detail do they need? So, you know, are your payout? Do your pay items need to be associated with their work order and those things? What level of reporting do you need to go at? Like I said before, you know, maybe it's revenue per man hour performing. Well, I can do that pretty easily just by filling out a time sheet and making sure that you fill out your pay items But then if there's if I see a report or you have this running report that says, hey, I expect all of my crews on this particular type of work, let's say, you know, new service, new business service installations to be able to perform at x revenue per man or whatever that x is. And you're starting to see these spikes. Right? Somebody's either, you know, killing it and just turning in tons of revenue or they're really the problem that you wanted to look for is where you have crews that are underperforming. So you have some crews that aren't generating as much revenue or their cost is way up. So a lot of the times, what we tried to talk about and suggest and work through is, well, you know, can you use things like photos And when you're filling out and and that's, you know, kudos to HCSS. Right? It's I mean, it's it's easy to capture a photo within HCSS. It's easy to capture a photo on your iPhone and then have it sync back your gallery back to your tablet that you're filling out your time sheet and then just grab that photo and link it to the job. That's an easy step in the process. And it can tell you a lot about what's going on. Right? So like I mentioned before, right, you might have field conditions that are causing lower amount of revenue or not as not as many feet of pipe to be installed in a given day to talk about it in terms of maybe the units but what might have happened is as they're running along, you know, trenching, they hit a bunch of rock and now they gotta break rock for two hours on a four hour job. Well, if they're, if the crew's out there and they're working along and they run into the rock and you take a second to snap a picture of that rock and then link it back to the job. Now, I have some indicator that's tied back to the to the heavy job job or the work order. It's tied to the foreman, right? Because the foreman is the one who has logged in and took the picture and it's when you drill in to that particular foreman on that day at that time which the photos time stamped to on that work order, I'll be able to see evidence of what was going on that caused that dip in productivity for the day as an example. With a minimal amount of burden on the crew. You could get the same thing by spreading hours across those units by asking the foreman to spread time across those units. But you I I don't think, and this is what I kinda saw firsthand was, number one, you're the likelihood of you actually getting accurate information when the foreman's entering it versus a photo of what's happening on the seat in the field, on the job site when they're out there. Right? It's like two different it's two different things. It's apples and oranges. Right? And the second thing is, is I don't need to see that every day, every time. I just need to be able to get it when I need it, which is where those anomalies come in. Because for the most part, the crews wanna do a good job. Right? They wanna go out there and perform. They actually don't wanna do the data collection. They wanna go dig the hole, right? Like, I would have much rather burn rod and and wire for eight hours when I was a welder than spent two hours counting the widgets that I built at the end of the day and then writing it down on a piece of paper at the time on a piece of paper. Right? So, it's it you really are trying to appeal to, like, what's the easiest way to gather the information you need if you need it rather than make all of that data reportable. And that's kind of the key difference, right, that I looked at was what data do I need to have available for reporting and aggregating for reporting to show you where performance indicators, like key performance indicators, show you where those KPIs are out of whack versus what information will I need when I get down in and want to investigate one of those conditions. Right? And those are two different things. So I'm just saying, like, when you're going through your design process, you need to think about that. I like the way you framed that. Do you really need to make it reportable? It's a good it's a good way to think about the the information you're gathering. A lot a lot of information can come through in just notes and photos and tags. Tags are to a degree reportable. That tells you a lot of information about what's going on in the field and the conditions without it being a number that can show up on a spreadsheet. Right. Hey, Emily. Are you there? Can you hear us? And do we have any questions that we should take a moment on? I know I've seen some flow through. Absolutely. The questions have been pretty much on topic, exactly what you're asking about. So, we've one in general about performance standards and metrics, which you've touched on about, you know, rates and things like that. We have something else about getting actuals back to estimating. We talked about maybe things that we don't need to send back to estimating, but maybe we want to discuss what is practical to send back. That seems like a good one. I love that question. All right. Let's hit that. Which of these metrics maybe it's not fair to say which. It could be a lot. What's a way to think about what I want to collect for the sake of estimating, whether it's the next contract or you know, six month, twelve month contract renewals, rate renewals. Do you have any thoughts on how the field contributes to that and the data collection decisions contribute to that? Yeah. I I mean, I think some of that stuff just kinda happens inherently as you're doing the work. And so I don't think that it's the way I think about it anyways, I don't think that it's necessarily discrete labor and equipment on a unit all the time. So I mean, I'll try to explain what I mean. So if I was putting together a dis like a distribution construction MSA to be bid on, I might have, you know, tons of different units. But I know that I'm gonna bid out a specific type of work because I need that work supported. I know that from an actuals or from a bidding perspective, I'm gonna estimate as an estimator. Right? It's gonna take, you know, let's say, to execute the amount of work that I'm gonna put in the MSA, it's gonna take, you know, ten crews and they're all three person crews, right, to execute that work. From an actuals perspective, when the crews are out in the field doing the work, if you end up as an example, right, you're putting a service in the ground and you end up needing to bore that service. Well, now my bore crew needs to go over and work on, work with my other crew. Well, how you gather that data is gonna be important. Right? And so that was one of the things that we always talked through was, does your bore crew get added to the time card of the foreman? Well, if you wanna understand the amount of increased effort that's associated with that particular work order because it required boring, you probably wanna have your board crew's time on your foreman's for, time card or at the very least, you wanna have your board crew be able to enter their time against the same work order. And so that beta will start to kinda come together. In my mind, the the idea that I'm trying to get out here is, like, it doesn't have to necessarily be discrete time against a unit. It could be things like, well, how many crew members and which type of crew members were working on a particular work order, and then what type of work was that particular work order. Right? Was it service installation? Was it main installation? Was it primary? You know, am I setting poles? Was it underground primary? Like, what is the type of work? And a lot of times you can tell that from attributes on the at the job level, at the heavy job job level without getting down to the particular pay items. And then understanding which pay items are associated with which type of work as an actual, you're gonna also get that inherently because you have to collect revenue when you go out and do the work. So you'll be able to figure out, okay. I have a boring pay item that's separate from my trenching pay item. So, I'm gonna add that to the time card and enter a quantity on it but do I really need to understand the cost associated with that trenching or with that boring and that's kind of the the point that I'm trying to make, right? Like, I think those data points are just as critical in figuring out the estimation process because I'll be able to say, how many crew members did I have on that job and then how long did that overall job take and what type of work do those crew members do based off of the units that were collected on the job without spreading labor and equipment cost against the units? I see one of the, a couple other questions came in about this estimating topic, so it's clearly resonating with some folks. And one of the questions makes me think about standardized data so that it is reusable in the future? And then my question goes to, is it wise and reasonable to standardize the way you're collecting cost actuals across contracts and types of work so that, you know, if you're collecting information about new service installations versus maintenance work or if you're going a level deeper and you're separating main work from tie ins and like, that's a level of detail that I'm imagining makes sense on specific contracts, but then you go to the next contract and does it? Does it make sense? And then how does that kind of information decisions, information management flow back? Maybe it to your ERP. Maybe it's to heavy bid, but across multiple contracts. Yeah. Like, how much do you think it's reasonable or wise to standardize the way you're collecting data as a business so that when you go to estimate the next contract, is maybe for a different customer, you have usable data? Is that reasonable to do? That's a really good question. And I mean, so here's the way that I can tell you how we approached it. I don't know if it was reasonable or not, but I'll tell you how we approached it. So what what we did was we said, look, customer A and customer B are going to be different and not only are they different but the conditions are going to be different, right? A crew in Florida doing work in the sand is going to have a much different experience than a crew in San Antonio digging into clay, right? Like, these are two different things and doing the work in those two areas are going to be completely different. So, does it matter if I have, right, this some standardized methodology at the unit level and the crew size level and those kind of things so I can compare between geographic areas? Or is it more important that I compare my profitability between types of work across those geographic areas. So we tended to try to narrow in on type of work in that condition rather than specific contract and customer, if that makes sense. So we would say things like, well, I wanna know how what is my performance from a margin? Just just talk about margin because margin removes all of the gap in geographic area. Right? Like, you have a target margin for your crew. You want your crew to deliver at whatever percentage. Right? X percentage and they deliver at Y percentage margin. Do you have a problem? Right? It's either you underestimated, you overestimated, you whatever it is. Right? You have a problem. And so what we tended to do is say, let's narrow in on the types of work that make the most sense to gather the data at and then make sure that that is consistent between operational areas, divisions, geographic areas, however you break up your work. And a lot of times, those geographic areas changed the customer the customer changed, but the type of work within the ERP system and in heavy jobs stayed the same. Even if the contract language might have been a little bit different or the units were different. And then we would measure things like margin in those cases because you really wanna understand performance at that point. Right? And if your margin gets way off, then I know my estimate was off somehow. Right? Up or down or, you know, operationally, maybe my estimate was right on, but we have an operations condition that changed, which like I mentioned. Right? I didn't realize that this whole town was made up of limestone and we're trying to dig in limestone when we bid the contract. Right? Like, those are the kind of things you need to think about. So if you understand the type of work across the areas and and you can calculate revenue versus cost from the margin perspective for that type of work, you can really get to a metric that you can compare across divisions, across your company, across contracts, and still drive performance. Alright. I was gonna ask you about some concrete examples, but you hit on that. So I'm just kinda recapping this in my head. If you look at an example, like the type of work they're doing actually, I didn't hear that one. What, When you talk about, yeah, we're drilling in limestone in this case, but not over there. What's an example of a type of work where you might say, look, we're going to track that type of work a category on every contract. But then we expect that there's gonna be some differences and we're not gonna track that. We're more gonna just look for that or maybe I'm putting words in your mouth, but we're gonna know that those differences exist as opposed to get that data in reports. Yeah. So, it was like service crews and then it was breaking down the types of service crews because certain service type installations might be faster than others. So, we would do like service replacements, new business services. We would do main installation from the gas side. We would do things like URDs. So, if you're building a development, you might have crews that build the backbone of the development and then you might have service crews that come in and build and just drop services all day. Either in the ditch or overhead services. And then replacement was a big difference, right? So like replacing a service versus a new business service installation completely different work, right? So, service replacements versus new business and then, main replacement versus new business and then, you might get into some specialty specialty type work like, you know, outage restoration or storm response or those type of things where the variability is really gonna be huge no matter what. And so you really just wanna know, are my storm crews generating the revenue and and is my margin where I want it to be on those storm crews even though storms are kind of an anomaly. Anybody's worked a storm kinda knows. So, it's just kinda throw everything at the storm to get everything up off the ground. But those were the that's kind of the granularity level I'm talking about without going through all of them. That's kinda how we thought about it. And then you would say, you know, you would wanna think about it when you're building this other than those specific examples. You'd wanna think about it from the perspective of where do I need a specific crew type to go do that work? Right? So, like, do I have a do I have boring crews that just go do boring work? And I offer that as a service to my customer or multiple customers? Or is that just an adder to the work when I run into that condition that I wanna make sure is is captured from a cost perspective. Right? So a lot of times the questions that I was asking was like, well, what are revenue generating crew types that you need to make sure that you track those the work that they do and then what do they do? Right? And are there specific crews that do those specific activities? Alright. We got six minutes left. And folks, if if you have more questions, fire them off. We are kinda checking them out. Emily, are there any other ones that, stand out to you that we should talk about? I mean, I guess, based on what you're saying, there was just a need for some advice which you've given about how to set up cost codes, but you did bring up maybe differences in geographical locations and how that could affect it. Are you recommending that they set up different cost codes for that or use something else like a tag to specify that? It's a good question. I mean, I think it could go either way. It kind of depends on a couple of things, right? One depends on how are you going to report that information and doesn't need to flow back to your ERP and then another one is, do you need it to be part of your billing output, right? So, you're gonna need to ask ask that question, you know, so do I need to have that information available on my billing export or my time card export that's gonna go back into my ERP. What I saw was probably the easiest way to do it was use the use the cost code for things like work type and then have pay items below the cost code and capture all your labor and equipment cost at the cost code level. So, I might have, so I would look at it like this. I'd have heavy job with a job number which is typically the work order and I'm given this like, this isn't like a one size fits all. This is just an example. Like, I would typically have a work order for the heavy job job and then, I would have a cost code which could be my type of work. My foreman is already going to be associated with the the work order itself and the type of work because of the time card and the linkage between the time card and the type of work that's in the cost code being added to the work order or the job and the time card. And then I'd have pay items behind the cost code that link back to the cost code and you can capture quantities at the pay items level when you drill into the cost code but all your labor and equipment just sits at the cost code level. And then like for a future thing like and I, you know, we talked about it, Frank. At some point, it would be really cool to see some sort of cost allocator from the Costco down into the pay items based on some sort of weighted percentage that could potentially even be calculated like as you go throughout the job, right? So, the volume of the cost of the pay items being collected versus the hours and it somehow weights the cost and distributes it across it knowing that it's an estimated cost per pay item but didn't require any data entry from the field. So that's typically how I saw the setup. Right? Work order at the job, cost code was type of work or some sort of collector that made sense for your business that you wanted to be able to report at. Pay items linked back to the cost code so you could capture revenue quantities. All hours and labor was entered against the cost code, and so it was easy for the crew to do the entry. Had an additional about just MSAs. So it sounds like in the scenario where your work orders are your jobs, how are we recommending that people look at their performance, let's say for the week, when they're in the field, working on different work orders on that MSA? What we used was, like I said, we used revenue per man hour, cost per man hour metrics to understand performance but we ran it. What we would do is create reports within insights at the time we were using insights a lot. We had a lot of insights reports that were pulling that data from the time sheets and then aggregating it at the forming level. So you knew form an A performed at this level. And then we made it where you could drill down into it and see the crew members below that, but you couldn't see revenue per man hour at the crew level, at the crew member level, just at the foreman level because the foreman gathered the revenue. That was the way we kinda managed crew performance. And if you wanted to communicate that to the foreman, it says just subscribing to the report Free performance email or how would, yeah. Yeah, sorry. So, what we, I didn't, I probably missed that part. So, what we did was had the insights report stood up so that the superintendent had it and they could see all of their crews by superintendent. So, we got grouped the foreman by superintendent and then, the superintendent would go have the conversation with the crew, right? Because they managed, let's say, a dozen crews by superintendent. So, they would look at each crew and say, okay, this crew didn't perform this week. I'm gonna go talk to the crew and sometimes, they would drill into those examples I talked about before like, go look at the photos, go look at the work order, try to understand what was happening before they went and had the conversation and then go have the conversation so they could show them how they how they actually did for the week. Okay. And I guess overall, just for you've mentioned different metrics, just KPIs that you would recommend. Are are they all rate based? Is there anything else that you would recommend? No. I mean, I think it really depends on your business. So you'd really wanna drill into your business, but most of what what we what we used was, like, revenue per man hour, cost per man hour, and then margin. And it was typically at the foreman level and at the type of work level. And those were pretty general KPIs. They're very general. So you probably, you know, wanna talk in detail and, you know, I mean, it's probably a good segue anyways for me. You know, I'm happy to jump in and and help anybody on the call if there's some value that you think we could bring just from the background that we've talked about today and the work that I've done in the past and thinking about this stuff with a little different lens than just pure IT and and accounting. That is the perfect segue with, you know, a minute to go here. Hopefully you folks can all see our glowing faces there. Darius' contact info, my contact info. There's some more questions floating out there. You probably have some more in your head. Reach out to us. We'd love to hear from you and answer questions. You know, I'll re clarify. Darius, I'm speaking for you here, but he is an HCSS consulting partner. We work with him, and he obviously brings a ton of industry experience and knowledge from the operational standpoint and from the office, the finance, accounting, IT standpoint. So, these kinds of questions, we expect you to have them and wish you had somebody to help you answer them. And, you know, we here, we love to sell you products, but sometimes you'd like to talk to somebody that is maybe more neutral in that process. So we want we we wanna hear from you. We wanna meet you, but I bet Darius does too. I'm about as neutral as they get. That sounds pretty There you go. I'd we'll leave that for another conversation. We've got negative seconds left. Darius, you got any closing thoughts? You want anything you wanna say to folks? I just appreciate the opportunity to talk about this stuff. Obviously, we could talk about it all day. I really do have a passion for, you know, trying to keep the field first and making sure that they can do their work and maybe kinda keep that in mind, I guess, as you go through these type of implementations, right, that those are the folks that are making y'all money. So keep them keep the field first. That's right. That's right. We love our we love our field folks. Well, as a guy outside drills, cuts through the concrete to install a sewer line next door and he's he's clearly telling me the utility webinar is over. Hopefully, y'all weren't hearing that in the last thirty seconds. So, with that, we'll leave everybody. Emily, thank you. Darius, thanks for joining on. This is amazing. And folks, get in contact with us and look for us again in another couple months.