Comprehensive Guide to Technical Questions to Ask a Heavy Civil Construction Software Vendor
Here are some tips for doing due diligence before selecting software that will underpin your construction operations.
Software vendors work long and hard to prepare for customer interactions, and will seek to steer demos, conversations and lines of questioning towards their strengths.
That’s their job—as a construction executive, your job is to pull them back to the topics that matter most to you and your business. Given that many contractors outside of the ENR top contractors list have not run software selection processes before, it is appropriate for us to discuss some questions you can use to redirect vendors away from their own agenda and onto yours.
1. When was the software developed, and if not in the last 5-10 years, when was it last significantly re-architected?
Why is this important? Think of the advances in vehicle technology that have taken place over the last ten years. In that time, CO2 emission rates for new vehicles fell by 10 gallons per mile even as horsepower increased. Technologies including turbocharging and direct fuel injection play a role and comparing a new with a 10-year-old vehicle will leave most people wanting the new vehicle.
With construction software, change has been even more rapid. There is no manufacturing or tooling, and digital systems can evolve much more rapidly than manufactured products. One obvious change is the increase in reliance on software-as-a-service (SaaS)—software sold by subscription in the cloud as opposed to on-premise use paid for through a perpetual license. Several mature construction software vendors have taken their on-premise software and shoehorned it in various ways into an online deployment model with subscription pricing. This may help contractors move the software expenditure off a capital budget and onto an operating budget and eliminate some of the administrative work necessary to run the software. Too often, construction software vendors use this managed services approach to engage in “cloudwashing”—an attempt to make their legacy software appear more modern and acceptable than it really is.
Some software vendors meanwhile have either re-imagined their software as a cloud-first solution or developed software from the start as a multi-tenant SaaS offering. Multi-tenant SaaS has advantages for both the software vendor and the contractor using the software. This is important for contractors to consider because these newer solutions will:
- Run more efficiently in a cloud environment than legacy software in a managed services environment
- Perform better for users outside of an office environment, connecting over a cellular network or the public internet
- Involve fewer additional costs – there is only one instance of the software in the cloud that is shared by many users with secure, segregated databases, so all users have the newest version with no need to test updates and roll them out across their company
- Be easier to integrate with because they will almost universally be built on an architecture where any part of the solution can be exposed easily for integration through an application programming interface (API)
- Help end users create integrations or speed up software vendors creation of standard integrations, shortening the time between a customer asking for a new integration and when it can be delivered
Ask a construction software vendor specifically about how the current software architecture is structured including:
- Dates of initial launch
- Date of last substantial revision of the software architecture (not just new functionality, but the underlying technology stack)
- Number of application programming interfaces (APIs)
- How many contracts do I have to sign? If there is one for the software subscription and another for hosting or cloud provisioning, you are probably looking at a vendor engaged in “cloudwashing”
- Is the software available on-premise, and if it is, whether a “cloud” version complies with the National Institute of Standards and Technology (NIST) definition for cloud computing:
- On-demand self-service, so an end-user can provision computing capabilities, such as server time and network storage without human interaction with the vendor
- Broad network access to support mobile phones, tablets, laptops, and workstations
- Resource pooling to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand
- Rapid elasticity so compute capacity can scale up and down, sometimes even automatically in lockstep with demand
- Measured service so usage of compute resources can be monitored, controlled, and reported
Construction software offered on-premise will fall down on most of these, and that matters in a few ways, starting with cost. If the software cannot scale up compute capacity depending on demand, that vendor will need to price their managed services offering around peak demand while a modern solution can scale its compute resources up and down as more users in the software conduct more transactions that consume more capacity.
For some contractors, a managed services model where legacy software is hosted in the cloud, perhaps tweaked and optimized to improve performance, might not be a bad way to go, particularly if you are already using that software on-premise. In some cases, there may be a performance improvement from moving that solution to the cloud. But for net-new purchases, going with old technology will not make sense, so probing the above topics with a vendor will be important.
2. Is this software part of a back-office business suite that handles finance, project administration, estimating, or other tasks?
In the days before modern API-first software, broad application suites were the norm. It made sense because having a pure-play, integrated environment where a single software was used across the business eliminated duplicate data entry and helped everyone standardize on the same data set in real time.
APIs may have made this approach somewhat obsolete however because they have freed construction leadership teams to choose the right application for different parts of their business. One advantage of the broad application suite for vendors was that it encouraged vendor lock-in, helping them compete for a larger share of each customer’s wallet. Today, even construction software companies that had avoided partnerships for this very reason have seen the light and are announcing partnerships with complementary solutions. But is their software up to the test?
Because modern software is designed around APIs, it is exponentially easier to integrate one software product with another. Vendors can create standard integrations, create new integrations per customer demand, or a contractor with more IT resources may even integrate two software products themselves. This is a lot easier with modern software—even construction integration platform-as-a-service (iPaaS) vendors like Agave, whose core business is to wire up multiple construction softwares, tend to focus just on modern cloud software.
Legacy software will tend to have a limited number of APIs bolted on from the outside at great expense to the vendor. These may support specific integration use cases the vendor could imagine when they opened these ports in their software, but integration of new fields or to different steps in a process that were not anticipated may come at high cost if at all.
Another challenge that comes with field operations or field productivity software that is part of a construction business software suite is that the software may be built more around the needs of finance than the field. In superhero stories, the origin story matters, and the same is true of construction software. Many construction enterprise resource planning (ERP) products have software to release job tickets to the field and report on productivity as it happens. These use cases serve the needs of people in the back office who want visibility and control and are often going unused in favor of purpose-built software for use in the field. Early on, suite vendors started to use the term Field Productivity to refer to the software modules they sold for use by superintendents, operating engineers, equipment and crews with their boots on the ground, and that truly reflects the attitude about what the software does—hand off information on productivity that must be achieved and reporting actual productivity or progress to the back office.
More recently, some vendors including IVO Systems have started to refer to their applications as construction operations software. This is because the software starts in the field, dealing with the specific needs of those who execute projects as opposed to the back-office team that administers them and accounts for productivity. But regardless of what you call it, when asked about the specific ways operations or field productivity software supports the needs of field workers, a vendor may have difficulty formulating a response.
While field productivity software will prioritize meeting informational needs of the accounting and business side, field operations software will focus on execution of the work by people and equipment, oftentimes with telematics. One more area to investigate here is whether the vendor will require or strongly recommend you purchase GPS/telematics hardware. These devices can be bolted on to your equipment and provide data such as locations, utilization, idle time, and more. Some vendors will sell their own or have partners they recommend. Be careful, as these Internet of Things (IoT) devices are loaded with proprietary software that may only work with a dedicated software product.
The most robust construction operations software vendors will be able to integrate with your existing hardware whether it’s via the equipment directly (VisionLink, JD Link, Komtrax, etc.) or with the telematics device. Vendors should also provide a way for critical equipment that would not have GPS devices, such as trench boxes or augers, to also be tracked in the same system alongside the telematics-enabled equipment.
3. Who owns the vendor organization and what is their posture towards the product?
When you select construction operations software, vendor ownership matters. There are certainly private equity groups that make investments in their portfolio companies, and then there are large, private equity rollups of multiple software products that become numbers in a ledger and may not receive the investment and attention to evolve. Sometimes, too, a broad technology vendor will make acquisitions that get them into the software market, and then must assault the learning curve of a very different industry.
Venture-funded startups, middle market companies, large corporations, private equity, sole proprietorships and other models all present risks. But the risks presented by the ownership structure—disinvestment in favor of other products in the portfolio for instance—increase depending on how well an acquired product holds up after examining it against our first point—modernity of software is important. There are examples in construction technology where a legacy on-premise product is acquired and then re-invented on a modern architecture. These are rare, so buyers should ask vendors about their roadmap for products while at the same time keeping their own counsel. What has the vendor done with other acquired products—let them idle, invested in them, or maybe spun them back out? Apart from asking the vendor directly about the product roadmap, looking at their career page to see if they are hiring development or sales staff to grow the product can be one guerilla technique to gather insights.
This software will run in your business for years, so it makes sense to look down the road at where the product and company are headed.
Early-stage software companies may also present some risk, but even if a venture-funded startup is acquired, its product set will probably be modern enough to become the solution that acquiring vendor, if they have multiple competing products, will lead with. A legacy software company developed for on-premise use may not fare as well because it will require extensive investment or actual redevelopment from scratch to catch up to newer products. The risk of buying from an early-stage company plummets after the series B round, or once a solid product-market fit is achieved leading to a growing commercial install base.