🎙️Transcript: The Great Debate - Infraday Northwest
Infraday Northwest
"The Great Debate: Build vs. Buy"
Jon Porterfield (Accenture), AJ Waters (Kahua), Ralph Barsi (Kahua)
November 14, 2024
đź“ş View on YouTube
Summary
This engaging debate between AJ Waters (Chief Evangelist at Kahua) and Ralph Barsi explores the classic technology decision facing construction and infrastructure companies: whether to build custom software solutions or buy off-the-shelf products.
Through a cleverly staged debate format moderated by Jon Porterfield of Answer Advisory/Accenture, the speakers initially argue opposing sides before revealing that the real answer isn't binary. Both speakers draw from extensive real-world experience, with Waters having lived through Kiewit's custom build journey and Barsi bringing decades of SaaS expertise, to illustrate the challenges and benefits of each approach.
The debate takes an unexpected turn midway through when both speakers begin arguing points that seem to support their opponent's position, ultimately revealing that the optimal solution combines both approaches through Platform as a Service (PaaS) and low-code/no-code solutions.
This hybrid approach offers the immediate functionality and best practices of commercial software while providing the flexibility to customize workflows and build additional applications as needed. The discussion concludes with practical insights about security considerations, future-proofing technology investments, and the importance of scalability in making these critical infrastructure decisions.
BIG Takeaways
• Platform as a Service (PaaS) Offers the Best of Both Worlds – Rather than choosing between building or buying, organizations should consider PaaS solutions that provide out-of-the-box functionality with the flexibility to customize and extend.
These platforms allow companies to start with industry best practices on day one while building custom applications and workflows that align with their unique business processes. This approach eliminates the false dichotomy of build versus buy and provides a path that can evolve with organizational needs.
• The Hidden Costs of Building Custom Software Go Beyond Development – Building custom software requires organizations to become their own training departments, support teams, and maintenance crews. Every button change, feature update, or bug fix becomes an internal responsibility requiring documentation updates, user retraining, and support ticket management.
Organizations must consider not just the initial development costs but the ongoing burden of being their own software company, including studying UI/UX principles, managing technical debt, and handling scalability challenges as the business grows.
• Security Must Be a Primary Consideration, Not an Afterthought – The Target data breach, which occurred through an HVAC subcontractor's compromised system, illustrates why construction and infrastructure companies must prioritize security in their technology decisions.
Working with established vendors who maintain certifications like SOC 2 Type II, FedRAMP, or StateRAMP provides built-in security frameworks, regulatory compliance, and risk management capabilities. This level of security infrastructure would be extremely difficult and costly for organizations to build and maintain independently.
• "One Size Fits All" Is a Myth, But So Is Complete Uniqueness – While off-the-shelf solutions often claim to handle everyone's needs, the reality is that no two companies handle processes like change orders identically. However, as AJ Waters pointedly notes, "outside of changing the names of a few fields, you're not as special as you think you are."
The key is finding solutions that maintain core standardized processes while allowing configuration for the 20% of workflows that truly differentiate your business, rather than building everything from scratch.
• Implementation Timeline Promises Are Rarely Kept, Regardless of Approach – Both build and buy approaches frequently exceed their promised timelines, with custom builds taking years to complete basic functionality and enterprise software implementations becoming "never-ending projects."
The speakers note that building a custom solution at one company took over two years just for the base system, which ironically is similar to many commercial implementation timelines. Organizations should plan for extended timelines regardless of approach and consider solutions that can deliver value incrementally rather than requiring complete implementation before providing any benefit.
• Future-Proofing Requires Architectural Flexibility, Not Crystal Ball Predictions – Many current SaaS solutions were architected in the early 2000s, pre-dating mobile technology, cloud computing, and modern user expectations. Waters uses the analogy of trying to run Windows XP today to illustrate how quickly technology becomes outdated. The solution isn't to predict future needs but to choose platforms built on modern, extensible architectures that can adapt as technology evolves. Think of it like buying a smartphone that can download new apps versus buying a dedicated device for each function.
• Low-Code/No-Code Democratizes Customization While Maintaining Standards – The emergence of low-code and no-code platforms fundamentally changes the build versus buy equation by allowing business users to create customizations without extensive programming knowledge.
This approach maintains consistent user experience and core functionality while enabling rapid adjustments to workflows, forms, and processes. Like how Apple and Google provide a platform where third parties can build apps, modern construction platforms should allow organizations to extend functionality without compromising the stable core that provides security, scalability, and support.
Transcript
Jon Porterfield (00:05):
Afternoon. Good afternoon, everyone. So as we close in on the home stretch of our election season, we thought we'd see if anyone was interested in another debate. And so today we're going to debate the great debate of whether to build or to buy.
I'm Jon Porterfield. I am with Answer Advisory, part of Accenture. We are a program, project, and construction management firm. We have about 1,300 folks in North America. We provide owner representative services on capital projects and infrastructure projects with Accenture.
We are capable of helping our clients from every stage of a project, from planning all the way through design and construction. One of the things we do is help our clients assess their needs and identify the best software solution for their project management. Today we are going to be talking about one of the key decision points in that process, which is: do you build your own or do you buy an off-the-shelf solution?
Jon Porterfield (01:26):
So this is often the great debate when it comes to technology - the build versus buy. There are definitely pros and cons to each, and is one of these options better than the other? That's what we're going to debate today.
We have two panelists here who are each going to be debating the two sides of that topic, build or buy. First we have AJ Waters. To your right, AJ Waters is a veteran in the construction space who has led many evaluation teams in the selection of off-the-shelf software. He will be representing the argument to buy software off the shelf.
And then with him we have Ralph Barsi, who is no stranger to technology himself. He spent more than two decades helping grow software-as-a-service companies. Therefore, he will be representing the build side of the argument.
I'm blessed that you folks are a little distant, but since this is being videotaped, I do have a gash across one of my cheeks here and I have to reveal how that happened. These two men - I got between them, so I don't have the ability to mute either of the microphones. So gentlemen, I'm going to hand it off to you, but please let's be civil about this debate. And with that AJ, the floor is yours.
AJ Waters (03:02):
Alright, well good afternoon everyone. As Jon mentioned, my name's AJ Waters, Chief Evangelist at Kahua. And for the last decade or so, I have been on the buy side of the industry. I've been helping customers look at software, evaluate software, and see how software off the shelf can solve their problems.
But before that I worked for Kiewit, which some of you may be familiar with. In the late 2000s and early 2010s, they went through a software implementation and custom built a bunch of applications in order to make their business processes work. So I went through the build and it was not pretty. That's kind of the background that I have.
Before I go too far, is Kyle from the Ferries Department still here? I heard Kyle this morning say "get to know your IT architecture staff." I got voluntold to be on that team at Kiewit. And yeah, it was hard. Those people do work hard on the backend to build your IT architecture.
AJ Waters (04:11):
But the reason out-of-the-box is a better option is that out-of-the-box is ready on day one. When you start your implementation, the best practices of the industry have been baked in. That's kind of the point of these software providers - they have worked with hundreds if not thousands of customers to build in best practices in an intuitive way that your users can use them right away.
The other great thing they do is they offer training and support. Software that you buy off the shelf has both a training team and a support team, probably has a library of videos, a YouTube channel, those sorts of things. If you're building it yourself, you're doing that yourself. You are the trainer, you are the support staff. So get used to those phone calls.
The other thing that it does is it's already developed to be scalable, and the maintenance, innovation, and upgrades are a part of how they operate as a business. All of those things together are things that you, if you are building it yourself, have to do. Every update is on you. Every maintenance cycle is on you. Trying to scale it up for bigger projects - if it doesn't handle it because your business grew, that's on you. So all of these are reasons why buying off the shelf makes it a lot easier on your internal team.
Jon Porterfield (05:52):
Alright, thank you AJ. Alright, Ralph. So what's wrong with that?
Ralph Barsi (05:55):
Well, what's wrong with it? Everything. So thank you Jon. I'm sorry about the gash. I think you've done a wonderful job mediating. We didn't mean to get too... we didn't mean to thrash too much.
You know what I mean? Everybody, it's great to be here. I'm Ralph Barsi, and I'm really having a hard time listening to my colleague AJ over here. In fact, just last week I spoke with a colleague who shared, and I quote, "We were sold a bill of goods back in the late 2000s that an off-the-shelf solution was the way to go. However, we quickly came to the realization that no matter how out-of-the-box something may seem, it will never truly conform to our way of doing business."
AJ mentioned thousands of customers do this, thousands of different businesses run into these problems and handle it. But we have our own unique way of doing things, therefore building it is the way to go.
Ralph Barsi (06:59):
In fact, AJ, in many cases, this system of industry best practices didn't understand many of the common phrases that we all learn in Construction 101. Things like change orders, for example, or back charges and production factors were foreign to a solution built by technologists. So in order to find something that would help us keep our competitive edge, we found out really quickly that we had to build it ourselves.
Let's face it, you're never going to have all the requirements outlined for a technology purchase. The very first time building your own software makes it easy to make changes whenever you want. For example, if you missed a step in a particular process and wanted to add it in, or you decided you want to automate an additional workflow without a significant upcharge from a vendor, build it out.
We spent just over two years, by the way, building out a solution, which is kind of the same amount of time it takes to implement a lot of software these days. By the time the base system was live, we had three additional products in the queue and ready to develop right behind it. So you see there are some very specific ways that we did things and they had always been done that way.
AJ Waters (08:22):
Now, if I remember correctly, my friends at Forbes say "it's always been done that way" is the worst phrase in business.
Ralph Barsi (08:29):
Okay, I appreciate that you did have your turn. So let me just finish real quick. We're talking about an incredibly successful, incredibly profitable contractor. Obviously doing things our way was a driving factor to our success.
I mean, buying software that was off the shelf and used by all of our competitors wasn't going to protect our edge. No, that was going to bring us backward in terms of processes. We had our standard operating procedures and that's what we're going to build. Couple that with a host of resources and you have a win-win for continued profitability and success.
Jon Porterfield (09:10):
Alright, well thank you Ralph. I mean obviously you've had some experience with this process and so I think what we would like to hear is what is it that's wrong about what AJ is saying?
Ralph Barsi (09:24):
So look, I started that way because it's just straight up - he's wrong. So if everybody can help me out here, a show of hands: who here's been part of a technology implementation? Very good. It's a majority of the room. So I don't think anybody in the room will argue with me that those implementations take forever. Am I right?
I mean, when was the last time a technology company actually delivered on a promised timeline? One of the most significant issues we had when first attempting to utilize out-of-the-box software was a never-ending project. Construction gets a bad wrap. For example, there's an old meme of a dinghy called "original contract" and it happens to be tied to a yacht called "change order."
But software companies make us look like novices in extending implementations. And when was the last time one size actually fit all? Out-of-the-box processes inherently assume everyone works exactly the same way. Those thousands of customers that AJ mentioned - I can't remember the last time two projects handled a change order the same way, let alone entire companies.
AJ Waters (10:36):
Maybe that's where that meme comes from.
Ralph Barsi (10:38):
Right? It definitely doesn't come from asking a software vendor for a new feature, I could tell you that much. The second we run into something that isn't quite as intuitive as they say or doesn't quite complete a process, we have to load our request into a feature queue and wait and wait and wait. And then hear that it's not really a priority for other customers. I might as well go stand in line at the DMV for crying out loud.
Jon Porterfield (11:05):
Okay. Alright. Wait, I think that's enough. Alright, so thank you Ralph. AJ, would you care to respond to Ralph's...
AJ Waters (11:16):
Well, it's interesting because you mentioned your plethora of resources and profitability to just go build whatever you want. Not everyone can look like Jeff Bezos. We don't always have that much money and time available.
And if that one ERP implementation is the standard that you're going to go off of - because yes, ERP takes forever - that's not the same thing as project management software. You can't use that as your benchmark for a two-year implementation.
Listen, let me ask you a question. If you were to build something yourself, when was the last time you studied UI/UX? Or how about what's a proper button location for an action button? Or what's the difference between Enter and Return?
AJ Waters (12:22):
Yeah, that's my point. What is the difference between Enter and Return? And you should know this, you're older than me. Enter was on a typewriter... or no, Return was on the typewriter. So it returned the typewriter to the other side, right? Enter came along when it started to be utilized more as an action button and not just to make the next line.
See, those are the kinds of things you have to consider when you're building stuff yourself. You have to consider all of these little nooks and crannies that you've never thought of about software. And those continued tweaks? They're never-ending. Like, it goes on forever.
When we built way back in 2012, I remember constant retraining. Every time a new button was added or a new feature, we had to go back and update all our material. We had to go back and train all the people. And of course they're not going to listen to us the first time, so we get a hundred support tickets because our button moved or our action is different.
And these trade secrets that you have to build into the system - your people are your trade secret. Your business process tends to be pretty close to the industry standard. It's not quite as crazy as it needs to be. And there are a few configurable providers out there, but I mean, outside of changing the names of a few fields, you're not as special as you think you are.
Ralph Barsi (13:42):
AJ, as I was saying, there's nothing standard about how we do business. I mean, sure, it'd be great to be able to share resources across projects with processes and procedures that were repeatable, but we would need a solution that streamlined these processes to support an initiative like that. Of course standards like this could decrease time to ROI and increase efficiency, but would it be worth the trade-off?
AJ Waters (14:08):
Well, that's an excellent question. It would only be worth the trade-off if you could connect the missing links. You'd have to be able to maybe build in a little bit of workflow that would connect the dots. Because I mean the right steps aren't going to be for everyone, right?
Ralph Barsi (14:28):
Yeah. I mean, but to do that, you'd have to be constantly tweaking and updating your user training and guidelines. There would need to be certain core aspects of the system, for example, that didn't change - like a common user experience and an intuitive interface. The more you look to build or change, the more important it is to keep things familiar to the end user. I mean, there is no room for clunky screens that are hard to navigate or siloed systems that look nothing like the other.
Jon Porterfield (14:57):
Sorry to interrupt, but Ralph, are you still talking about building?
AJ Waters (15:00):
But you also want it familiar to your user, right? You want your business flows in there so that it's quicker to learn, so it's easier for them to navigate around and get to the things that they need. So you've got to build in that process.
Jon Porterfield (15:16):
I thought you were talking about buying.
Ralph Barsi (15:18):
Yeah, look, as you can clearly see the correct solution to the problem of digital transformation in construction is to buy a system that is off the shelf and build around industry best practices. It decreases time to ROI. It's easy to use and it could scale with your business.
AJ Waters (15:34):
No, no, no, no. The correct option is to build your own. It satisfies all your requirements. It's more nimble and it does things that your users want it to do. If you need to buy it, man... I... build. Build!
Jon Porterfield (15:48):
Alright, I have to stop both of you. So you guys sound like you're flipping sides.
AJ Waters (15:57):
Isn't that what they do? Is that how a debate works?
Jon Porterfield (16:01):
Yeah, we flip sides.
AJ Waters (16:06):
No, no, no. We...
Ralph Barsi (16:07):
Just go with the... But...
Jon Porterfield (16:07):
You guys can't hold your ground.
Ralph Barsi (16:10):
Help us out, Jon. Help us out.
Jon Porterfield (16:13):
Let's cut to a little presentation here, right? Okay. So does that come up on its own? Or you might get there through the click. There we go. There we go. Alright.
So I mean, what we're talking about here is do we walk, crawl, or run with the platform as a service or a low-code application process? You're going to get the benefits of a commercial off-the-shelf product. You're going to get easy configuration with minor enhancements to it. You're going to be able to have complete flexibility to create new applications.
AJ Waters (16:56):
So essentially, why not do both? If you have the opportunity, do both. Get something that runs off the shelf that you can build in your own processes. And that's the idea of a platform as a service, which is a little bit different than a SaaS or a software as a service product.
So that was kind of the argument that we were having a little fun with up here. But the idea is there's more than one way to handle something like an RFI or a submittal. And maybe that out-of-the-box way is not the right way. Well, maybe a low-code, no-code application builder allows you to tweak that, not necessarily follow the scheduled path.
Jon Porterfield (17:43):
Answer Advisory has found with some of our clients that this is the best solution for them because it allows a quick implementation to keep pace with a tight schedule on delivery. But it also builds in that flexibility to make adjustments on their own to workflow and to naming conventions on fields and what have you, so that it can better fit their own delivery processes.
Let's see here. So with a low-code platform as a service, you don't have to be held back by the development bottlenecks. You don't have to spend a year getting it configured for your application. AJ, I think you have some experience with this. Can you tell us a little bit about how this plays out?
AJ Waters (18:39):
So essentially what happens when you're looking for - and we made this comment in the debate - the new feature request with a software provider. If you are not a priority customer, if your feature isn't something that most of the customers are going to get benefit out of, it gets deprioritized down the list.
So if anybody here is an avid user of P6 and has ever submitted a feature request, you probably know what this feels like. Because I think I have 10 from the early 2000s that still haven't been answered. And so that's the idea of the development bottleneck.
You submit tickets for feature requests to providers, and then you kind of wait your turn. I think one of the big ones in Autodesk is a search in their UI so that you can find parts and pieces faster and they never built it out. So a partner actually built out an add-in to make it work. That's the kind of idea of the low-code.
Ralph Barsi (19:44):
Yeah, I was just going to add to AJ - so obviously we're partial to buying software that is on the market, taking advantage of this ecosystem he talks about. But for anybody who's considering making an investment like that, I would implore you to consider the agility and the scalability and the evolution that a platform or software as a service can provide your organization as it scales and grows and evolves over time. It's absolutely critical to think about that when you're in the evaluation process.
Jon Porterfield (20:23):
With platform as a service, your data could be more secure, right? Ralph, can you elaborate on that?
Ralph Barsi (20:31):
Absolutely. So it can't be emphasized enough how paramount security is. And this is just a handful of some of the entities out there that you'll want to be keeping in mind and searching for when you're considering making an investment in a platform.
I mean, just a couple bullet points to keep in mind in terms of the benefits that you get from partnering with a secure environment and a vendor that understands security. For example, the whole procurement process becomes streamlined and efficient, especially when you see FedRAMP or StateRAMP environments. Processes are going to be streamlined at very high standards as well.
Also, there's enhanced risk management. Implementing SOC 2 Type II measures helps identify and mitigate risk across your organization. I mean, there's regulatory compliance benefits. They help you meet legal requirements and reduce fines from legal issues, God forbid that happened. You also have a competitive advantage. There's user confidence that's driven across the organization, which also drives consumer and customer confidence. So there's a ton of benefits and advantages to going with a secure environment and making sure that that remains at the forefront of your initiatives.
AJ Waters (22:00):
And to go along with that, here's kind of the overall idea of why security is so important in the construction industry. Not just because of things like what happened with the Seattle airport, but who here - a little over a handful of years ago - who here lost data when Target got hacked? Basically all of us, right? Because their entire customer database was hacked.
But what few people realize, if you go and you read about what actually happened, they got hacked through their HVAC subcontractor. So that subcontractor had an insecure system and somebody hacked that system and found the login credentials for Target's system. So they got into Target through construction. That's why it's such a big deal for our industry to be as excited about security as all other industries.
Jon Porterfield (23:12):
Well, I did not know that story about Target, so that's interesting. So AJ, what about future proofing? I mean...
AJ Waters (23:22):
So this one's one of my favorite ones - future proofing technology. Because if you think about the speed at which things are innovating right now and the speed at which things are changing, and you look at technology that was architected 20 years ago, you start to understand...
Like, I loved Windows XP 2. It was one of the best versions of Windows. But I couldn't imagine trying to run Windows XP today. And that's the timeline that we're talking about.
When we look at a lot of the SaaS providers that are on the market, they were architected in the early 2000s, right around Windows XP, Windows Vista - like that timeline. And so they run on backend systems like those architectures would run on. That's pre-iOS, that's pre-Android, that's pre this low-code idea of what all of our mobile technologies utilize today.
AJ Waters (24:42):
And that's where some of the newer low-code platform as a service providers give you the opportunity not just to buy something off the shelf that is what it is, but also to continue to build your own applications and to future proof that investment.
Because now if something changes tomorrow, you have a way to add a new Lego block or to add a new application. It's just like the phone that's in your pocket - iOS or Android, whatever you're running - that is a platform as a service. Out of the box it works.
But on day two, you decide that you're going to take a flight and go somewhere. Apple or Google, they didn't develop the United app - they let United do that. Now you as a user who bought this new phone? Well, I don't have that app on my phone. I got to go get it. They allow you to do that versus having to go buy a phone specifically for travel that specifically has travel applications, right? That's kind of the idea of future proofing your tech.
Ralph Barsi (25:33):
A separate thing I would add to what AJ's talking about is not everybody in the room is keeping their finger on the pulse of the proliferation of apps that we're seeing today or the evolution of technology. So anybody who has an iPhone in their pocket right now knows that it seems like every month to three months you have to click update to do the software update because there's constant change and evolution.
We have Procore in the room, we have Asite in the room, obviously we represent Kahua. We are people who have our finger on the pulse of this proliferation of technology and the evolution. So you don't have to - you can consult people like us in the marketplace, and we would consult you right back and help you make sound decisions for your organization as you're managing the technology wave that isn't going to stop.
Jon Porterfield (26:35):
So just to summarize what we've been talking about up here: you're looking at cost savings, having the best of both. You're looking at flexibility, you're looking at agility. This is something that you can implement fast and then retool it as the sophistication of your process or your program advances. You have security, you have longevity because of the future proofing. So I think that summarizes it. Anything you gentlemen want to add to that?
AJ Waters (27:11):
Nope. All I'll say is: software providers, we're done ahead of schedule and we'll give you back a couple minutes.
Ralph Barsi (27:21):
Yeah, I would say also, if you're in the process of considering that investment and buying something on your own, I would recommend what AJ recommended. That is: consider doing both. Do the buying and the building if it's going to benefit your organization and your mission.
You've all been generous with your time. Thanks to Ken and the Infra Day team. It's a real pleasure to be here with you. And thank you, Jon. Thank you all.
Jon Porterfield (27:48):
Thank you. Ken and Kahua has a booth outside, so if there are any Q&A that you have, you can meet up with them out there. Thank you.