Why Construction Software Sucks

In September 2022, our COO 'Jason Lancini' was invited onto the Project Chatter Podcast to discuss 'Why Construction Software Sucks'. And whilst it's not fair to say that all construction software sucks (Aphex obviously being one of the exceptions 😉), a disproportionate amount of the tools available to the industry aren't as good as they should be.

Throughout the podcast, Jason and Dale Foong talked about the broader state of technology in construction, and where they think it's heading.

Read on for a summary of 'why construction software sucks' or check out the full podcast for a deep dive into construction tech.

Youtube: https://www.youtube.com/watch?v=TmU_djrDJR0

Spotify: https://open.spotify.com/episode/63VLJ00MucPdBagi6J0Ofd?si=2d3e8aeeb8094666

Why does construction software suck?

The problem is that most construction software is not built with the end user's benefit in mind. Whilst many tools solve the business problems that contractors face, they fail to recognise the individuals who will ultimately be using them.

The result is that end users get given a mandate to use new pieces of software that aren't user-friendly and often take longer to input data. "Users are treated as input rather than Customers".

One of the core reasons this happens, is the current relationship between contractors and software suppliers.

Take a large infrastructure project, for example. There are large sums of money involved, relatively low margins, and a lot of things that could go wrong.

It’s no wonder that testing different tools can feel dangerous and distracting.

Because of this, contractors tend to procure software the same way as anything else; write a scope of work, evaluate a few different tools, run a proof of concept (most likely with the tool that's already been chosen), then deploy.

The problem is that this approach incentivises software providers to build tools for the decision maker and not the end consumer.

"It's kind of like studying for a test. If you think about the emissions scandal with VW cars, they passed the test, but they were no good for the road."

But it doesn’t need to be like this.

If the individuals using the software were empowered to test, use, and deploy the tools they need to carry out a task, then developers would be forced to respond.

Imagine an engineer with this kind of authority. They identify a problem, trial software for free, make sure that it's the correct solution to fit their specific situation, and then deploy software that they know works.

Software providers would then be forced to build better tools for the end users (because they are now the decision-makers), and onboarding would need to be built into the software. Value would be obtained from the tool faster, and there’d be less need for company-wide training or refresher courses.

Companies deploy software this way outside of construction, but the process hasn't yet penetrated the industry.

What are the challenges with deploying software?

There are always challenges with deployment and projects need to be managed differently. For example, choosing the right time to test and deploy new software is scenario specific.

Another problem in construction is that many of the tasks that need to be completed are for the benefit of someone else. EG, the contractor may have to submit work for the use of the client. In these situations, it's more important than ever that software developers are building tools with the end user in mind. Otherwise, they will have trouble getting the team to adopt and engage.

"The onus should really be on the software provider to find a solution to that problem. If you've got a tool or a piece of software that sucks for the end user, it's hard because you're forcing people to do something that they inherently don't want to do or is worse for them."

So what’s the path to better software?

The solution lives with both the contractor and the software suppliers.

In an ideal situation, the people using the software would be empowered to choose a set of tools that best suit the way they want to work. In turn, the tools themselves need to be built with the end user in mind and with out-of-the-box integrations so that they work well together.

But as it stands, we have a long way to go from where we are now to get to that.