What "One Source of Truth" Actually Means on a Construction Project

A developer calls on a Thursday afternoon asking for a straight answer: are we on budget, and are we on time? The project manager pulls up the cost report from one system, the programme from another, checks a spreadsheet a site engineer updated three days ago, and texts the site supervisor to confirm what actually happened on site this week. Twenty minutes later, the answer the developer gets is a synthesis, not a fact. It is the PM's best guess, assembled from five sources that do not talk to each other.

This is not a failure of any one person. It is what happens when a project's information lives in more tools than the team has hours to reconcile.

The real cost of a fragmented tool stack

Data fragmentation is not an abstract IT problem, it is the daily condition most construction projects operate under. Site diaries, cost reports, RFIs, variations, safety records, and schedules routinely live in separate systems that were each bought to solve one problem, never designed to talk to the others. The result is a project where nobody, not the PM, not the developer, not the site team, is looking at the same current picture at the same time.

Workers lose almost two full working days each week solving avoidable issues and searching for project information, and poor project data and miscommunication is responsible for 48% of all rework in the construction industry. PlanGrid and FMI, Construction Disconnected, 2018

Why this happens even on well-run projects

No project manager sets out to run five disconnected systems. It happens one purchase at a time: a scheduling tool bought to fix programme visibility, a safety app added after an audit, a spreadsheet that started as a stopgap and never left. Each tool solves its own problem well. None of them were built to be the single place a project's truth lives, because none of them were designed with the others in mind. The construction data management problem is not a lack of tools, it is too many of them, each holding a different fragment of the same project.

The commercial result of that fragmentation is what PlanGrid and FMI's industry survey put a number on: $177 billion in annual US labour costs tied to non-productive activity, including searching for information, resolving conflicts caused by inconsistent data, and redoing work that was based on the wrong version of the truth.

What it costs when nobody has the full picture

$31.3 billion in US construction rework in 2018 was directly attributable to poor project data and miscommunication between stakeholders. PlanGrid and FMI, Construction Disconnected, 2018

Every one of the problems we have covered in this series traces back to the same root cause. A disputed variation is a documentation gap between what happened on site and what the payment claim can prove. A slipping schedule is a gap between what the programme says and what is actually happening on the ground. A defect surfacing at handover is a gap between what the quality record shows and what was actually built. None of these are separate problems. They are the same problem, showing up in different modules.

What a single source of truth actually looks like

A single source of truth does not mean one screen with everything crammed onto it. It means that when a variation is logged, it is the same record the progress claim references. When a schedule slips, it is the same programme the cost report is built on. When a defect is raised, it ties back to the same inspection and the same trade that will need to fix it. The record does not get recreated at each stage, it gets carried forward.

When that discipline holds:

• A developer's Thursday afternoon question gets answered from one system, not five.

• Cost, schedule, and quality data all reference the same underlying project record, not separate reconstructions of it.

• A variation raised on site shows up in the next progress claim automatically, with its evidence attached.

• A defect at handover traces back to the exact inspection, trade, and date it originated from.

• New team members can see the full history of a decision without chasing down the person who made it.

The Australian context

Australian construction firms are investing heavily in digital tools, but the FMI and PlanGrid data reflects an industry pattern that Australian builders know well: buying more software does not automatically produce more visibility. Integration between systems, not the addition of another standalone tool, is what actually closes the gap. On a market where margins are tighter than they used to be, the cost of that fragmentation is not abstract, it shows up directly in the disputes and rework we cover in our piece on why construction profit margins are tighter than they should be. The same gap between what is happening on site and what the systems know is also the root cause behind why Australian construction schedules slip, and why defects surface late at handover instead of during the build.

Where Plexa fits

Plexa is built around a single project record that cost, schedule, safety, quality, and correspondence all reference, rather than five separate systems that each hold a fragment of the truth. A variation logged on site carries through to the progress claim. A schedule slip shows up in the cost report the same day, not three weeks later. A defect at handover traces back to the inspection and trade that produced it. None of that requires the team to change how they work on site. It requires the systems behind them to stop working in isolation.

The developer who calls on a Thursday afternoon should get an answer, not a synthesis. That is the entire point of a single source of truth: the truth should already be sitting there, waiting to be read, not assembled under time pressure from five different places.

If you want to see what one connected project record looks like in practice, book a 30-minute demo with the Plexa team.