Building for the Long Run: Rethinking Construction Data for the Building Lifecycle
The old expression “missing the forest for the trees” is old for a reason: it describes something that happens all the time.
And in the building industry, we are in the business of creating and managing buildings, not in the business of running processes for their own sake.
Like any other process, beginning with the end in mind keeps you focused on what matters.
And what matters most during the 50-year lifecyle of a building is data about the building, and the items & assets within that building.
So it can be surprising that so many software products organize themselves around processes, not outcomes: They focus on the path of an RFI, or a change order, instead of focusing on the history of, say a chiller, or an electric panel.
While this obviously helps the teams that are doing the actual building, focusing on process over outcome has the effect of leaving reams of data and documents that are organized in a way that makes them much harder to make useful at the end of the project, which the building will enter the next 48+ years of its life.
Some years ago, I recall a conversation I had with a senior facilities manager. I’d spent a long time in software, some of it on the web and marketing side, and took for granted that more data is better.
This gentleman reminded me that someone has to make sense of all this data, and that most of it is not organized in such a way that a normal facilities team can do anything with it.
A much more useful way to organize data is by asset: either tagging or otherwise connecting all of the data, documents and processes that impact a specific building element, building system and of course, the building itself.
At handover and beyond, the customer, knows at the deepest possible level what they are managing, what decisions led to the current form of the building and, of course, how to fix, replace or replenish items as time goes by.
AI has given us the opportunity to re-think how we organize data, and the power to support multiple views of data at once.
An example of this is Palantir, who have introduced “ontologies” as a core way of looking at data. Ontologies are just a data model that allows for both a definition of a thing (which all databases do), and how it is related to others (which most databases do not). Just that change in how data is organized has unlocked enormous value for Palantir and the government agencies that rely on them.
In construction, we have the same opportunity to rethink how we organize our data, both because it is much easier to manage data with multiple tags and classifications than it was just a few short years ago.
Also, for the first time, we have systems that leverage these new data approaches to automate some processes, and augment others.
Organizing our project data through the lens of what we are building, what we are installing, and what it took to put that work in place makes obvious sense.
As the industry adopts ever more powerful software and AI tools, this can unlock a lifecyle view of the project and the building it delivers that finally pays off the promises software has been making for years: safer buildings, more efficient projects, and cleaner handoffs.
