Construction’s Digital Data Gap — Building Buildings vs. Building Software

Source: Shutterstock

The construction industry faces productivity challenges unlike other industries — labor shortages, supply chain issues, and slow technology adoption are three of the largest. Digital transformation will be a big part of the solution to these challenges, yet construction firms often lack an effective digital strategy.

The solution, we believe, comes down to understanding the fundamental business and cultural differences between building buildings, and building digital solutions. According to Deloitte, the construction industry spends about half as much on information technology compared to other industries. Around 90 percent of a typical construction company’s software investment is in large corporate systems such as human capital management, financial systems of record, office productivity suites, and CRMs.

Most of these applications are designed for and used by knowledge workers at headquarters.

There’s a tremendous amount of actionable data that remains inaccessible to and from the construction jobsite, where a general contractor’s profits are made — or lost. Several field applications, such as FieldWire and PlanGrid, have emerged that connect the field with headquarters. These “native to the field” applications understand that the jobsite worker’s culture comes from the building trades, not from knowledge workers in the back office.

We’ve found that technology that is successful in the field:

1. Requires little or no training
2. Is designed for field conditions where, at best, a temporary office is a trailer
3. Adapts to the huge regional and size variations in construction projects
4. Demonstrates a fast ROI without upfront capital investment

For example, there are apps like Safe Site Check In, which helps manage the people and activities on a construction jobsite using QR-codes. Consumer level usability makes Safe Site Check In trivial for firms to deploy and for workers to master, works on any device, is highly affordable, and integrates with back office applications.

Until recently, most field apps were simple point solutions designed to digitize time cards, compliance forms, change orders, etc. Most didn’t share data with other applications in the office and usage wasn’t standardized across the company. Since most field managers decided which tools and technology they’d use on each project, this resulted in duplicate software licenses, or even multiple apps on a project solving the same problem.

Along with adding unnecessary expenses to the project, point solutions maintain their own data, creating information silos. The inability to integrate with each other and eliminate duplicate or conflicting information makes it impossible to create an enterprise view. Tackling that complexity is the challenge, and promise, of digital transformation.

Many GCs recognize that field data is a critical missing piece of their digital strategy. And yet less than half of the Top 500 building contractors have some form of dedicated technology group outside of traditional IT that integrates field-facing applications.

Construction management solutions that are native to the field and integrate with HQ applications are on the rise. For example, Procore provides applications for both back office and the field, as does Trimble, CMIC and Autodesk. However, these solutions are often complex with high training and deployment costs, which can slow adoption in the field.

A strategic approach to digital transformation needs to provide GCs with a dashboard view of field operations that integrates field and back office data.

The Build vs. Buy Dilemma

One challenge for GCs using off the shelf construction software is that the industry’s technology ecosystem is comparatively late to the party in adopting modern cloud service computing.

The venture capital community also tends to focus on innovations that meet investor needs for rapid revenue growth (at all costs) by focusing on financial processes and is often unaware or avoids the HQ-to-field divide.

When developing for the field, the technology industry has a well-known tendency to overhype features and benefits by claiming the future is now. But today’s GCs need low cost, high ROI solutions that address current business challenges.

Can a build-it-yourself solution be the best way forward?

Since the construction industry’s technology ecosystem is still in its infancy, an executive or technology leader at a construction company that evaluates off-the-shelf solutions can often find few practical options.

Frustrated by a lack of software with modern characteristics, it’s tempting for one to embark on developing their own software in-house.

If that’s what you’re thinking, be careful: one-off software development can be time consuming and a costly choice if you conflate the process of building buildings with building software.

Building Buildings vs. Building Software

Project management for software development is very different from project management for construction projects. With software development, you are manipulating electrons and information — immaterial objects. When mistakes are made, you edit the code. As with all rework, the later a defect is discovered, the greater the mitigation costs. Code already in use may have to be redeployed and its users retrained.

With construction, a mistake is much harder to fix. You can set a window in the wrong place or wire a building in the wrong way. The repercussions of these mistakes are costly, time consuming, and not easily fixed once the structure is in place.

There is no continuous improvement on a building like there is with software. Rework is consequently much more expensive in construction.

We can understand why GCs might like the idea of building software solutions themselves in order to advance their digital transformation faster. But they risk yet even more frustration months later if the technology solution isn’t completed because (as hard as it is to believe!) software development cost estimation is absolutely terrible compared to construction project estimation.

Let’s compare the big differences between building buildings and building software:

• Project Requirements: Construction projects are managed to create a fixed baseline of non-functional requirements so that the project budget can be anchored and controlled as much as possible, even if changes and T&M work occur. Today, software projects are managed using agile methods that are predicated on constantly changing functional and non-functional requirements. Software often changes because it can, or depends on another piece of software whose changes are outside of its control. Put another way, it’s easier to move electrons than molecules.
• Project Management Methods: Structures are primarily static, while software is better compared to a machine that needs operating instructions. Agile methods plus the high hourly cost of programmers often leads to unrealistic schedules that skip architecture, design, testing, documentation and most planning in favor of continuous trial and error.

About the only thing construction and software project managers have in common today are the occasional Gantt chart.

• Architecture: Enterprise data and software architecture are their own unique disciplines, and while no less necessary than building architecture, it is usually skipped over by programmers under time and budget pressure. Like all things digital, data architecture is much more liable to change over time than the architecture of physical buildings. And data architecture is critical to information security — another huge, under-mitigated risk in construction.
• Design: Software design is usually a separate step in software development, where the details of software creation and assembly are defined. Design in construction tends to be more about aesthetics than in software. Programmers like to skip this step, which usually results in many more bugs.
• Modularization: Modern software makes much more use of off the shelf modules than construction, and that’s generally a good thing. However, software modules often have vague and unspecified origins and performance specs: Some are licensed and cost money, some are “free”, but still licensed, some are “software as a service” and an active part of someone else’s architecture, etc. Unlike modules in construction, almost none are warranted to perform to any particular engineering standards or specification.
• Testing and Quality Assurance: The flip side of no warranted performance specifications is that the software creator is entirely responsible for testing and assuring the quality of the new software product. Unlike reputable engineering design and construction, programmers under time and budget pressures almost always skip most if not all testing.
• Deployment: If new software is more like a new machine, then every software machine needs new operating instructions and operators will need to be trained on its use. Decommissioning an existing piece of software is often required, making deployment even more difficult. And, yes, time and budget pressures mean that programmers often skip writing these instructions down.
• Maintenance: Unlike buildings where the GC turns over the property to its owner, software maintenance never ends. A piece of software is rarely ever “done”, it’s a machine that’s always evolving. Computing environments are not like building foundations — they change frequently. Software firms are motivated to change them all the time, usually for competitive or “upsell” reasons, and to “lock in” customers. Because programmers skip design and documentation steps, turnover when programmers quit can feel like starting all over again. Producers of software of any kind can have maintenance costs of over 30 percent of the original build costs. With physical buildings, it’s closer to 5 percent.
• Lifecycle costs: An in-house team is a forever cost to keep custom software and integrations operating securely. Worse, you’re unlikely to understand what the software folks are doing if you cannot afford a technical manager. Look at it this way: If you’re a GC, and use specialty subcontractors for say, plumbing, because you lack the expertise or domain knowledge, what makes you think hiring a software developer will be any different?
• Asset ownership: The idea of software asset ownership is not something that construction companies are too familiar with. The traditional project delivery model involves a GC completing construction and then handing ownership over to the owner. Rarely does a construction company have skin in the game when it comes to maintenance and asset ownership. Assets are thought of as equipment. But software is more like a custom built machine or tool.

Buy Better to Limit Shadow IT

For much of its history, construction software has been acquired to solve a specific problem on a specific project, often for a specific buyer, such as the head of safety, estimating, etc. The result has been siloed and incompatible data which can inhibit, not accelerate, digital transformation. This is one reason why construction compares poorly with what the rest of the economy enjoys today.

Apart from HR and financials, software has not traditionally been acquired as part of an enterprise-wide IT strategy. Instead, it’s accumulated as part of construction project needs. This has resulted in product portfolios that are filled with lots of software and apps purchased by individuals, a portfolio that’s constantly changing as different projects select different solutions.

Frequently, there’s a disconnect between corporate IT and field users. Because of the relative speed of construction delivery, corporate IT can be caught flatfooted when projects speed ahead self-selecting whatever software is needed by individual project managers to complete the job.

When buying decisions are completely tactical, with a “shoot, ready, aim’’ approach, it results in what is known as “shadow IT.” The amount of shadow IT in construction is comparatively higher than other industries, which contributes to ever greater data voids and inconsistent project data.

Often, in their rush to use technology to quickly solve a specific project problem, some basic rules of software procurement are skipped. This can put a firm at risk of ransomware or other cyber attacks. Procurement processes matter: a cheap or free app can grab your company’s data and sell it.

Enterprise Software Strategies for Construction

Today’s GCs manage in an environment where it’s difficult to gain a whole view of a construction business due to the HQ-to-field divide, where projects operate in their own world, loosely integrated (if at all) at the firm level. A true digital transformation strategy aims to create management dashboards that can bridge the divide.

There are proven digital transformation strategies that can be adapted to the construction industry’s use of software. Here are the ones we believe are the most effective:

• Create an enterprise architecture that includes all your software, network, computing and data assets (sometimes called your tech stack). An enterprise architecture incorporates the non-functional requirements (the “ilities”) your business needs — availability, configurability, usability, security, etc. If you keep it up to date, your enterprise architecture will guide your digital investments for lowest cost and risk, identifying the data you need to protect from loss, corruption or worse. You wouldn’t build a structure without a structural engineer; you cannot become digital without one either.
• Seek out platform solutions that are built around a common data architecture that the vendor maintains over time (e.g., Procore, Autodesk, etc.) Platforms are a big expense and a big bet that your vendor will include all your critical needs now and in the future. But a platform does guarantee a shared data model. Over time, your firm’s data architecture will be inherited from the platform — a good thing if you cannot create, afford or maintain your own.
• Directly integrate key applications, e.g., CRM to bid/estimate, bid/estimate to financials, etc. This makes sense for big departmental apps. Because these apps change all the time, your integration software needs to keep up. If you use an IT firm to integrate, you may become dependent on them if loosely managed.
• Create a data warehouse or a data lake to merge data models then combine the models with advanced reporting, dashboards, and analytics tools. Since this is very expensive and difficult to do and maintain, even with just a handful of applications, it’s usually limited to only richly funded IT teams at the largest firms looking to create their own “big data/machine learning” solutions.
• A lighter strategy uses modern “low code” tools to develop selected apps and integrations. These tools are not cheap, but they do open programming up to more than software professionals. Choose tools that force your programmer/business analyst to develop designs, documentation and tests along the way to reduce lifecycle maintenance costs.
• A “very lite” strategy involves piecing together business intelligence through office suite applications, applications that custom integrate data from legacy systems into something like an Excel spreadsheet or Power BI dashboard. Inexpensive; many, if not all, large construction companies do some form of this strategy to some degree. The result is often termed “gum and baling wire” integration because the solutions are operationally fragile and only understood by the author. Good for non-critical functions, or when data accuracy tolerances are fairly wide.
• The “heavy” version involves bringing on an in-house team of software developers to not only integrate software applications, but to build fully custom made, cloud-native software with modern features that are operationally robust. Ideally, the supplier will also leave design, documentation and other artifacts so that a firm is not permanently needed to keep things running.
• Every software product has lifecycle costs that most firms underestimate. Continuously pruning the software product portfolio to eliminate duplication and consolidating operational knowledge is always a good idea. But strong management support from above is required to get project leaders to give up on pet products and adopt a company standard.
• Because of the competing push and pull of enterprise strategy versus project speed, one of the more successful ways to organize a construction software portfolio is around communities of interest or knowledge networks that stretch across dispersed field-based project teams. This ensures field users are engaged in the process and stay on the radar of enterprise strategy. By moving software procurement away from project teams to an enterprise data team, the GC can then take a more strategic view of software purchases.

Only as a last resort, carefully approved and managed, should your firm build its own digital solutions. If you do, use modern software tools and methods like workflow, low-code, no-code, agile. If software development is not managed for the long term, you may just be digging a hole you cannot climb out of except at great expense.

Nate Fuller is Managing Director of Placer Construction Solutions, advising leadership teams to transform their organizations in ways that improve performance and agility at the field level.

David Ward is Founder & CEO of Safe Site Check In, who has spent his entire career helping software “eat the world”.