- Industry Insights
- 4 August 2026
27 subcontractors, one live data centre, and the truth about software adoption.
-
Sam Dorevitch
- 3 minutes
Construction software doesn’t usually get rejected. It gets ignored.
The demo goes well. The contract gets signed. The platform works exactly as promised. And then, six weeks into the build, half the site is still running the old spreadsheet next to it, and the tool that was meant to give everyone one version of the truth has quietly become one more place nobody looks.
That gap, between a tool that functions and a tool that gets used, is where most construction technology loses its return. It is almost never a software problem. It is a workflow problem. Nobody agreed who owns which approval, nobody mapped how the field and the office actually talk to each other, and nobody checked whether the people doing the inspections found it faster than the way they worked before.
So earlier this year, we checked. On a live data centre build, while the rollout was still happening, we surveyed the subcontractors doing the work. Here is what 27 of them told us, and what it says about why some construction software lands and most of it drifts.
The missing link isn’t the software
A recent piece in For Construction Pros put it plainly: the missing link in construction technology is business integration, not systems integration. A general contractor can buy the best project management platform, the best estimating tools, the best field technology on the market. But if nobody understands the workflows, nobody agrees on role responsibilities, and the field and office keep communicating around the tool instead of through it, the project still struggles. The technology functions. The business doesn’t.
The reporting on this is blunt. Most technology transformations fail to hit the success metrics leadership approved them for, and a large share deliver only a fraction of the ROI that was promised at sign-off. The root cause is rarely a bad vendor. It is a rollout that treated a workflow problem as an IT problem.
Systems integration is getting the platform to work. Business integration is deciding how people will actually use it. On a busy site, the software rarely gets rejected outright, because nobody has time to reject anything. It gets worked around. And a workaround is quieter, and more expensive, than a refusal.
What 27 subcontractors said, mid-rollout
The respondents covered the full commissioning scope of a hyperscale data centre: ACMV air side and water side, earthing and lightning protection, fuel systems, HV equipment, fire protection, ICT, façade, and civil and structural works. These are the trades whose sign-offs sit on the critical path to energisation. They are exactly the crews a quality tool has to win over if it is going to mean anything at handover.
The headline numbers held up:
- 85% (23 of 27) said the digital process improved their work efficiency compared with how they used to work.
- Overall satisfaction landed at 4.0 out of 5, with 78% (21 of 27) rating it a 4 or a 5.
- Understanding of the tool scored 4.2 out of 5. Not one respondent rated their understanding below 3.
Read those three together, because they matter more as a set than individually. The crews found it faster. They were satisfied with it. And, critically, they understood it. Subcontractors rating a quality tool 4 out of 5 while the rollout is still live takes two things at once: a platform genuinely built for the field, and a rollout that met them where they work. Either one without the other, and that number does not happen.
Where the friction actually was
The survey was not a clean sweep, and the honest part is where it was not.
About four in ten respondents flagged a technical or workflow issue. When we sorted them, almost none were complaints about whether the tool made sense. They clustered at the seams between parties.
The clearest example was approval timing. Several crews raised the same structural point: an inspection has a closure window, but closing it depends on the consultant and the main contractor signing off the associated drawings, and that approval sits outside the subcontractor’s control. So an item shows overdue on the dashboard even though the crew has done nothing wrong. As one respondent put it, the delay is not on our side, it is waiting on an approval we do not own.
The rest followed the same pattern. Crews wanted to be notified when an inspection was approved, rejected, or rescheduled, rather than checking for themselves. They wanted a clean way to remove a record raised in error. They wanted the loop closed when a consultant left a comment, so everyone could see the rectification had actually happened.
None of that is a usability failure. It is a workflow-ownership question wearing a software costume. Who closes the loop when a consultant raises a comment? How does a crew know their request for inspection has been actioned rather than parked? Those are the exact questions business integration is meant to answer before go-live. Where they were answered, the numbers were strong. Where they were not, the friction showed up in the tool, because the tool is now where the work is visible.
This is not a small thing to get right. Rework alone consumes a meaningful share of construction time and project cost, commonly put at 5 to 15% of total project value. A commissioning record that is complete, current, and trusted is what keeps that number down. A record that crews route around is not a record at all.
What makes software land on site
If the goal is a tool that gets used rather than one that gets ignored, the work happens before anyone logs in.
- Map the workflow before go-live, trade by trade. Not a generic template. The façade crew’s inspection flow is not the HV crew’s, and a rollout that pretends otherwise creates the exact seams where adoption leaks.
- Assign every approval, in writing, before the first inspection is raised. Most adoption friction is an unassigned handoff. Decide who closes the loop between subcontractor, main contractor, and consultant, and the “overdue” problem largely disappears.
- Train by discipline, not in one big room. The ACMV crews and the fire protection crews have different sign-off chains. Train them against their real chain, not a demo dataset.
- Measure adoption while it is live. We surveyed mid-rollout on purpose. You cannot fix a rollout you only assess at the end.
- Treat implementation as part of the product, not something that happens after the sale.
That last point is the whole argument. Your process, our platform. The software does not replace how your teams work. It carries it. Which means the rollout has to start from how they actually work, not from how the tool would prefer they did.
The finding worth keeping
The easy takeaway is the one that fits on a slide: 85% more efficient, 4.0 out of 5, understood by everyone who touched it. The more useful takeaway is quieter. The tool succeeded where the workflow around it was mapped and owned, and it strained where it was not. That is the difference between software that gets used and software that gets ignored, and it is decided long before go-live.
If you are rolling out quality management software across a complex build, or you are about to, that is worth pressure-testing first.
Want to see where the quality magic happens?
Reach out to the team for a quick demo of the project management tool that puts quality and compliance front and center.
Why does construction software fail to get adopted on site?
Most of the time it is not rejected, it is worked around. The platform functions, but the workflow around it was never mapped: approvals are unassigned, the field and office communicate around the tool instead of through it, and crews fall back on the old spreadsheet. Adoption follows workflow ownership, not features.
What is the difference between systems integration and business integration?
Systems integration is getting the software to work and connect to other tools. Business integration is agreeing how people will actually use it: who owns each approval, how sign-offs flow between subcontractor, main contractor and consultant, and how success is defined before go-live. The second one decides whether the first one pays off.
Do subcontractors actually use quality management software?
They do when it is faster than the alternative and built for the field. In a mid-rollout survey of 27 subcontractors on a live data centre project, 85% said the digital process improved their efficiency and overall satisfaction was 4.0 out of 5. The crews who rated it lower were reacting to approval-chain timing, not the tool itself.
How do you measure software adoption during a construction rollout?
Survey the people doing the work while the rollout is live, not after it. Ask about efficiency versus their old way of working, satisfaction, and whether they understand the tool. Then sort the friction: usability problems are a product issue, but approval-timing and sign-off problems are a workflow-ownership issue you can fix mid-rollout.
