Issues on job sites tend to compound as construction projects mature. Meanwhile the gap between what was planned and budgeted for, and what actually happens on-site grows ever larger. Construction technology can help bring those two together again, but only if it’s built on the humble premise that construction, by its very nature, is a chaotic enterprise.
This article explores the question of what is needed, exactly, to come to a full 360 degree understanding of what is happening on site, and why it has proven so difficult for many construction technology vendors to build a solution that provides this.
Shit happens. Everyone knows that. And shit happens especially during the build phase of construction projects.
It gets worse when a project matures when lots of little problems tend to clump together and complicate into bigger problems. These slow a project down and make life increasingly hard for everybody on site.
How to solve this? Over the last couple of years, many construction tech companies have come up with — what seems to be — a straightforward answer to this conundrum.
They said: well, let's prevent shit from happening in the first place with better planning.
But they were wrong. They weren’t completely wrong, but they were wrong enough to never be able to solve the problem.
A construction project is like a living organism. It has its own metabolism. Complications are going to occur. The longer a project goes on for, the more complex the interactions, and the bigger the chance of unfortunate events unfolding.
What you CAN do is accept that issues will be there, dispose of them properly as soon as they occur, and, crucially, make sure they don't cause other issues to happen downstream.
But that's not how most construction tech companies have approached things over the last couple of years. Many have come at construction from the outside and see this incredibly broken industry. They look at everything that's going wrong and see a massive opportunity.
And, yes, the opportunity is there. But where many contech companies go astray, is that they typically think that the same types of solutions that have worked in other domains, like manufacturing, will also work in construction without recognising that the problem space is far more ambiguous.
So they have been trying to build idealistic solutions aimed at preventing shit from happening.
If only we could build systems that are smart enough…
If only we could build systems that are complete enough…
That same thinking is endemic to construction, too. I'd be rich If I got a dime for every time I've heard construction people say:
If only we could create schedules and drawings that are accurate enough…
Except it doesn't work. Because shit happens, shit will continue to happen until well into the foreseeable future, and, to make matters worse, shit does not give a shit about the accuracy of your schedule.
The inability of many contech companies to embrace the chaotic ground conditions in construction prevents them from building solutions that adequately address that reality.
And if you don't believe this, just look at the billions and billions of investment dollars that have been poured into construction tech over the last 10-15 years, and compare that with the depressing overall productivity rate in construction, which is actually declining.
Now, despite my mildly sardonic tone, I appreciate that it is not an easy problem to solve. Humanity has been building shelters ever since we came down from the trees. So if it were easy to solve, we would have figured it out by now.
It’s a hard problem.
And when we, Disperse, were first building out our productivity solution for the construction industry, there were also a couple of things we could certainly have done better.
What we got right was this: to solve construction's massive productivity challenges, we need to take a long hard look at (what we consider to be) the 'core' of construction: the actual on-site execution of the project. Now this is contentious, because it sounds like saying construction execution is more important than other aspects of building.
And fair enough, without people securing building permits, designing the building and supporting the project administratively, there would not even be a core process.
But the issue is twofold. First of all, the core execution comprises well over 70% of the entire project's worth. And secondly, those peripheral activities are not nearly as broken as the physical execution of the project is. The actual processes going on there are better understood and can be brought under control more easily.
What we have seen in ambitious construction startups is that many began with the intention of solving core execution, but ultimately failed to penetrate the critical issues, because it was just too hard.
But in trying to solve the core issues, they would drift away from the main problem. They would inadvertently stumble upon possibilities for efficiency gains in the peripheral areas of construction. They saw that it was possible to make money there. So they stopped trying to solve the core construction issues and focused on the edge problems that were much easier to tackle.
That's why some of the biggest names in construction software today, are now nothing more than glorified construction documentation systems. But construction's current woes are not served with better documentation systems.
We have felt the pull of these same dynamics ourselves, as well. Initially, the majority of the ROI of our solution came from claim mitigation - because reality capture enables one to document the job site exhaustively, it becomes much easier to resolve disputes over what has been done versus what has been agreed upon.
Had we decided to double down on claim mitigation, we could have made money initially, but we would have contributed very little, if anything, to improving the industry's productivity curve.
Instead, we have concentrated on penetrating the core issues of construction, and measured by the success of the current iteration of our product suite, we are making some serious headway.
But here is what we got wrong: when we observed how construction leaders were spending their time, we noticed that they spent quite a lot of time assembling data to create reports. We did not realise that they did not use those reports for themselves; that's not how they drove their projects.
We discovered project leaders produced reports because they HAD to for contractual reasons, but they did not consult them for their own execution process. So, yes, our system helped them cut down on the tedious manual labour of data gathering -- which saved them time -- but the reports themselves did not actually help them execute.
The reason? Most construction leaders are visual people who hate digging into Excel sheets to understand what is happening.
In the process, we realised that, yes, it is helpful to produce reports — but only because they need to exist.
We needed to find ways to present the information we gathered more visually, so boots-on-the-ground project people could make sense of what was going on at their site immediately and intuitively.
For that reason, we developed an almost entirely visual interface as a project overlay that gave users an easy way to zoom in and out of their project.
But it was not enough. Because another issue was constantly tugging at the validity of our project data: the mismatch between schedule and actual.
Initially, we had this idea: if we can ingest the schedule, shop drawings and other documents pertaining to the planned build, and we can compare these to the actual build progress, we can see what is supposed to happen on-site and what actually happens.
Except, there is one glaring issue, and that is that the schedule does not get updated regularly. So when you compare actual build progress with an out-of-date schedule, of course you'll see things that are off. But they are not going to be the right things.
PMs would tell us that the data was inaccurate because it was not in line with the schedule. But then the schedule itself was not kept up to date either. This situation had us running around like a dog chasing our own tail trying to provide the teams with reliable project insights. Meanwhile the meaning of ‘accurate data’ kept shifting depending on who we asked.
This mismatch between the schedule and the actual build became such a big deal from a data-reliability perspective, that we eventually decided to let go of linking our systems to the schedule. Because building a data-insight application based on incomplete, inaccurate or out-of-date information is useless; it will produce outputs that are inaccurate by definition.
(This, incidentally, is the same reason that we don't think it's particularly fruitful to integrate with BIM, since such a tiny percentage of projects deploy an up-to-date model throughout the project's lifetime.)
But we discovered we could still do a few helpful things, even without the schedule.
You see, we possess a lot of preexisting construction data. Our systems have seen over a hundred projects being built — a vastly bigger number than any PM will ever encounter in their lifetime. And since construction, for the most part, follows predictable sequences, in many cases we don't even need the schedule to be able to tell if something is being done right or wrong.
Decoupling from the schedule is not problematic if the schedule is not up to date and is not actually being used to drive everyday decisions.
But even with this, there is still crucial information missing from the loop. Because construction teams are not just doing something. They assess the state of the project, consider where things are blocked, and then plan what needs to be done next in the weekly or biweekly lookahead meetings.
Except a lot of that activity is going on in the brains of Project Managers who are simultaneously trying to keep track of a million minutiae in their head. That's not ideal because, especially on large projects, it becomes impossible to keep all those details straight.
But also because if planned sequences are never made explicit and fed back into tracking systems, we'll never have accurate insights into what was supposed to happen and what actually happens on site. And so we are missing crucial information about how our project is doing and if we are delivering what we promise.
This is the reason we built Lookahead, our second product. It enables Project Managers to make explicit where the project is blocked and how they are resequencing to work around those blockers. By linking that information to our core visual performance tracking product, Impulse, we are creating a closed information loop of project information that enables you to see exactly where the bottlenecks are, how fast they are being resolved, and how efficiently the work is being redirected around them.
That's why Lookahead is such a significant step forward for our product development and has become an essential tool for our clients. It turns the entire core execution process into data – from beginning to end.
Now, when shit happens, we'll be able to see exactly what caused it to happen, what is being done to get rid of it, and we'll be able to easily do root cause analysis to assess whether it's systemic and how we can address it in the future.
Now, because we have a substrate of valid information describing many important data points of the project accurately, we can build new, advanced functionalities on top of that. We can integrate with the supply chain, create high-level project controls, and that's just the tip of the iceberg.
A lot of things become possible when the information loop is closed.
