The hidden cost of disconnected project data

Infrastructure projects do not usually fail because a team cannot make a spreadsheet. They fail because five teams made five spreadsheets and believed they were looking at the same job.

The information chain is simple to draw and expensive to break:

Estimating → Engineering → Procurement → Project Controls → Execution

Every arrow is a handoff. Every handoff is a chance to copy data, lose a revision, or change a unit without changing the story.

Estimating

Estimating produces a priced intent: quantities, rates, allowances, and a total someone is willing to stand behind. If that intent is a file rather than a record, the next team will not inherit it. They will recreate it.

Recreation is not review. Review challenges assumptions. Recreation retypes numbers and introduces new ones.

Engineering

Engineering produces geometry, loads, and foundation strategy. When those outputs stay in CAD, PDF, and email, estimating treats them as inspiration. Layout row counts and pile types then drift from the commercial baseline while both teams insist they are current.

The hidden cost is not the extra meeting. It is the bid that assumed one embedment while the drawing set assumed another.

Procurement

Procurement buys what it is asked to buy. If the RFQ is assembled from a remembered quantity, the PO will match the RFQ and mismatch the estimate. That mismatch becomes a commitment in project controls that nobody can map to a line item.

Supplier quotes that never return to the estimate as sourced rates create a second commercial truth: the number you sold and the number you can purchase.

Project Controls

Controls is asked to explain variance. Variance against what? If the budget was a rounded total pasted from an email, the category structure in the cost report is a fiction. Forecasts then chase invoices instead of remaining work.

Disconnected data turns project controls into archaeology: reconstructing what the estimate meant from people who have already moved to the next bid.

Execution

The field records what happened: daily quantities, deliveries, incidents, punch lists. If those records use different units than the estimate, production percent is a narrative. Closeout then cannot answer whether the job matched the commercial intent.

The superintendent is not the problem. The missing object model is.

What separate files actually cost

Duplicated entry

The same table count is typed into the estimate, the RFQ, the logistics tracker, and the daily report. Each typing is an opportunity to be almost right.

Stale quantities

A layout revision that does not recompile the estimate leaves a zombie quantity in procurement. Steel is ordered for the zombie.

Scope gaps

Allowances that were obvious to the estimator are invisible to the buyer. The gap appears on site as a missing item and in controls as an unexpected invoice.

Revision mismatch

Engineering Rev 4, estimate “final,” RFQ Rev 2, budget from Rev 1. Everyone is busy. Nobody is aligned.

Procurement mistakes

Wrong coating, wrong origin assumption, wrong lead time, wrong quantity. These are not random. They are what happens when the package is not the approved estimate.

Forecasting issues

A forecast that cannot see commitments, remaining quantities, and open engineering holds is a guess with formatting.

Handoff problems

Each team invents a status: “good to buy,” “90%,” “waiting on geotech.” Those statuses do not compose. A project record can. A folder of decks cannot.

The compounding effect

Early disconnects are cheap to fix and easy to ignore. Late disconnects are invoices, idle crews, and claims. The cost is hidden because no single spreadsheet contains the whole loss. Each team can show that *their* file was consistent.

The project needed a consistent object, not five consistent files.

Connected systems are not a cultural slogan. They are how a quantity keeps its identity as it moves down the chain. If you cannot point to the same table count in estimating, procurement, and execution, you do not have a chain. You have a set of local optimizations.

A practical test is boring and sufficient: pick one foundation post count. Find it in the layout revision, the estimate line, the RFQ, the commitment, and the daily installed quantity. If those five numbers are not the same object moving through time, the project is already paying a tax. The tax shows up as expedite fees, idle labour, and a forecast that has to be “managed” every Friday.

That chain is the subject of the utility-scale solar project delivery page, using one Red Mesa foundation quantity across GeoLab, estimating, procurement, controls, and execution.

See Project Controls overview and Creating a project for how Infrenta models that record. The modeling is only useful if teams are willing to issue revisions instead of side files.