Two conversations happen in every boardroom about data, and both ask the wrong question. The first is "have we got enough of it?" The second is "is it good enough?" One chases volume, the other chases quality. Neither can be answered as posed, because both have dropped the only word that settles them: purpose.
Data has no fixed value. It has a value relative to a purpose. That single sentence, taken seriously, does more work than any maturity model. It tells you why data matters, how to use it, how good it has to be, and whether you can afford to wait for more. They are not four problems. They are one idea seen from four sides, and this piece takes the first two: why data matters, and how to use it.
One source, many readings
Start with importance, and resist the instinct to measure it by volume. The value of a dataset is not how much of it you have. It is the number of distinct decisions one capture can answer without your having to go back and collect again.
A small example makes the point better than the principle does. On one major infrastructure programme, the humble delivery record kept at the concrete batching plant, one row per load, turned out to answer at least five separate questions with no additional data collected. Read five ways, it was a record of:
- Plant and fleet performance: throughput, cycle times, truck turnaround and utilisation.
- Placement: where the concrete physically went, load by load.
- Traceability: which mix, which material lot, in which pour.
- Procurement and invoicing: material consumed drove reorder and matched supplier invoices, and a three-way match fell out of the same rows.
- Verifiable as-built progress: poured volume set against programme, progress that could stand up rather than be asserted.
Five datasets, from one. You did not collect five things. You collected one thing and read it five ways. That multiplier, not the raw volume, is where the value sits, and it is almost always larger than anyone realises at the point of capture.
Capture richly, deploy sparingly
The multiplier is also almost always squandered. The widely cited industry figure is that the large majority of construction project data is never used at all, and that teams spend a meaningful share of their working time simply looking for data they already hold [1]. The data is there. The readings are not taken. Most organisations are sitting on multiples of the value they think they have, unread.
That multiplier, not the raw volume, is where the value sits, and it is almost always larger than anyone realises at the point of capture.
One design consequence follows, and it is the only place importance forces your hand at capture. Capture once, at the finest resolution you might ever need, because you cannot know in advance every question the source will later be asked. You can clean data later, at a cost. You can never make coarse data fine after the fact. Resolution is the one decision you cannot walk back, so the time to be generous with it is now, not when the question arrives.
The multiplier has a counterweight, and the two are halves of one idea. It does not follow, because one source can answer many questions, that you bring all of it to any single question. For one decision, most of what a rich source holds is noise, and noise is not free. Past the point of sufficiency, more data does not sharpen an answer. It buries it.
Again, an example. On a modular manufacturing programme, each standardised design unit carried dozens of fields: resourcing, equipment specifications, room dimensions, energy and ventilation demand, and more. But the fields that mattered were set entirely by the question. Sizing the ventilation plant needed the energy and dimensional data and almost nothing else. Building a labour plan needed the resourcing fields and ignored the rest. Bringing the whole unit to every question did not enrich the answer. It hid it.
Too little, too much
So relevance and sufficiency are set by the question, not by what the source happens to hold. There are two symmetric failure modes. Too little, and you cannot answer. Too much, and you cannot see the answer. The skill is to bring the minimum sufficient set, the right data at the right time, and then stop. Knowing how to see the wood from the trees is as much the discipline as having the trees in the first place.
Read the source widely to know everything it could tell you. Deploy only what the question in front of you needs.
The one question
Importance and use are two sides of the idea. Quality and timing are the other two, and all four answer to the same question: what is this data for?
Ask it, and the rest falls out. It tells you to capture one source richly, because it will serve many purposes you cannot yet name. It tells you to bring only what the question in front of you actually needs. It tells you which bar the data has to clear before you rely on it. And it tells you whether to act now or wait. Stop asking whether your data is big enough, or good enough. Ask what it is for. Almost everything else is downstream of that one question.
That is where Synaform's Data service starts: connecting the sources you already hold and modelling them in the Playground, so that one capture can be read for every decision it serves and turned into insight and foresight.
Sources
- [1] FMI and Autodesk, Harnessing the Data Advantage in Construction, 2018.