The Single Source of Truth Is What Lets a Program Scale

Your Data Is Duplicated, and the Duplicates Drift

Ask a store development team where a project stands and you will get an answer within a minute. Ask three people and you may get three answers that are all sincere and well sourced, yet slightly different from each other. The weekly report, the schedule, the date real estate is using for rent commencement, and the date operations staffed to are four different dates.

That is the shape the problem takes. Data gets duplicated on a rollout, and the duplicates drift. The same fact gets restated in a daily log, a weekly report, a meeting minute, an escalation email, and a slide, and every restatement is a fork. A week later nobody can tell which one is current, so the safest move is to ask again, which creates a sixth version.

Autodesk and FMI, surveying more than 3,900 construction professionals for their 2021 study Harnessing the Data Advantage in Construction, defined bad data as information that is inaccurate, incomplete, inaccessible, inconsistent, or untimely, and therefore cannot be used to derive actionable insight. Inconsistent is the word doing the work in that list. A number can be individually correct in five places and still be useless, because the organization cannot tell you which of the five to act on.

The Quickbase Gray Work Index puts a number on the resulting doubt. Only about 10% of respondents said they were extremely confident in the accuracy of key project information. Roughly 9 in 10 carry some hedge on the numbers they are managing against.

A Single Source of Truth Means One Owned Record per Fact

The phrase gets read as a mandate to consolidate. One tool, every fact, everybody logs in. That reading has funded a lot of expensive migrations that did not fix the underlying problem, because what drove it was the number of unowned copies, not how many systems held them.

The useful definition is narrower and far easier to act on. For any given fact, one record is authoritative, one role is allowed to change it, and everything else that displays that fact references it rather than restating it. Copies are fine. Derived views are fine. The problem is a second place where the fact can be edited independently.

That definition matters because it stays achievable in a real environment. Your lease data probably lives in a real estate system. Commitments live in an ERP. The general contractor's critical path lives in the general contractor's scheduling tool. None of that has to move. What has to happen is that each of those facts has a declared home, and every report that uses it points back to that home instead of holding a copy that ages.

There is a quick test. If a fact changes at three in the afternoon, how many places have to be updated by hand before the organization is consistent again? If the answer is more than one, that fact has a distribution list where it should have a source of truth.

Four Questions That Tell You Whether a Fact Has an Owner

Ownership is the part that gets skipped, because it is organizational rather than technical, and technical work is easier to schedule. But an authoritative record without a named owner reverts to being just another copy inside a quarter.

Run these four questions against any number that shows up in an executive conversation. If you cannot answer all four quickly, that number is not governed, whatever system it lives in.

• Who is allowed to change it? Physical edit access to the file is a separate thing from the authority to move the number and be accountable for the move. If the honest answer is anyone with the link, there is no owner.
• What happens downstream when they do? A governed change propagates. An ungoverned change depends on somebody remembering every report that quoted the old number. The second one loses eventually, and usually at the worst time.
• Can you reproduce last quarter's version? A record that only holds current state cannot defend a past decision. If the number in the board deck can no longer be regenerated, it was only ever a screenshot.
• Who notices when it goes stale? Every fact needs an expected update cadence and somebody who sees when it is missed. A field nobody has touched in five months is abandoned, whatever it still displays.

Why It Is the Gate on Scaling

At five active projects, divergence is survivable because one person holds the reconciliation in their head. They know the schedule says the 14th but the real date is the 21st, and they correct for it automatically without noticing they are doing it. This works, which is why small programs feel deceptively easy.

The reconciliation work does not grow in step with the portfolio. It grows with the number of pairs of things that have to agree, which grows much faster. Add stores, add vendors, add a second region with its own general contractor roster, and the cost of keeping everyone consistent starts to overtake the cost of doing the work. Programs usually experience this as a staffing conversation, framed as needing more coordinators.

The research supports reading it as a data problem rather than a headcount problem. In the same Quickbase research, 45% of respondents reported spending 11 or more hours a week chasing information across their organization, and the three consequences cited most often were miscommunication, duplicated work, and project delays. Separately, PlanGrid and FMI, surveying nearly 600 construction leaders, attributed 48% of all rework on United States jobsites to poor communication and poor project data, and put the annual cost of those two causes together at roughly 31 billion dollars.

A program hits its ceiling once the cost of disagreeing with itself grows faster than the program does, even though the work itself never got harder.

A Source of Truth Has to Be True About the Past

There is a second requirement most teams discover late. A system that only holds current state cannot answer a question about a past decision, and past decisions are the ones that get audited.

When a VP re-runs last quarter's portfolio report, the numbers have to match what was presented last quarter. If a region was reorganized in the meantime, or a project's prototype version changed, or the cost code structure was revised, a system that reflects only today's structure will quietly produce a different number and nobody will be able to explain the gap. That is the moment people stop trusting the reporting.

Holding history means keeping the value as of a date rather than only the current value, and keeping the structure as of a date too. It also means the record has to survive the things that reliably churn on a long program: project managers leaving, general contractor rosters changing, and a tool migration somewhere around year three. The organizational memory of a rollout should not depend on which software the team happened to be using at the time.

The practical version of this is unglamorous. Snapshot the numbers on the cadence you report on, and keep the snapshots. A frozen monthly record of every project's status, forecast, and open exposure costs almost nothing to store, and it is the only thing that will let you answer why a decision looked correct when it was made.

Where to Start

You do not begin by mapping every field in every system. That project does not finish. You begin with the small set of facts that show up in every conversation that matters, because those are the ones disagreement is expensive on.

For most store development programs that list runs to about 10 items: target opening date, current forecast opening date, possession or delivery date, permit status, approved budget, committed cost to date, current forecast at completion, assigned general contractor, prototype version being built to, and project phase. Almost every executive question is a slice of those 10.

Take them one at a time. Name the system that owns it, name the role that can change it, define what triggers an update, then go find the reports that currently restate it and point them back. Governing 10 facts is worth more than nominally centralizing a hundred, and it is a quarter of work rather than a multi-year program.

Do that, and the next 30 stores cost about what the last 30 did to coordinate.