What Data Governance Actually Means (And Why Most Projects Get It Wrong)
"Data governance" gets used constantly in construction conversations. It turns up in tender documents, strategy decks, and kick-off meetings. But on most live projects, the reality looks quite different.
Quite often, I go into a meeting at a major programme and still find inspection records stored in a shared drive, status tracked in a spreadsheet, updates typed into free-text comment fields, and a small team spending their week(end) reconciling all of it before Monday’s report. It looks busy. It might even look digital. But what it is not, is governed.
What data governance actually means
Data governance is not a technology. It is a set of decisions about how information is defined, structured, and controlled so that it can actually be used for reporting, for assurance, and eventually for handover.
The difference between a well-governed data environment and a typical project tracker comes down to specificity. A tracker might record an inspection with a name, an area, a subcontractor, a status, and a date. That is enough to answer the question “has this been done?” It is not enough to answer “has this asset been inspected to the required standard, by a qualified person, with the outcome linked to the relevant defect or sign-off?”
A structured approach changes the question being asked of the data. Instead of a status column, you have a controlled outcome field: pass, fail, or conditional. Instead of a comments box, you have a linked defect record. Instead of a subcontractor name, you have a named individual with a clear role. Small changes. Significant difference.
Why most projects get it wrong
The problem is not that teams lack data. Infrastructure projects generate enormous amounts of it. The problem is that the data is captured in a way that makes it difficult to trust, aggregate, or act on.
Free-text fields allow different people to record the same thing in different ways. Columns without controlled values mean no two entries mean quite the same thing. And when information lives in a spreadsheet rather than a structured database, there is no audit trail: no record of who changed what, when, and why.
By the time a project approaches handover, someone has to make sense of it all. That typically means a team of people manually pulling together evidence, often at the last minute, from paper, Excel, and disparate systems to compile the documentation the asset owner needs. It is slow, costly, and entirely avoidable.
Three rules that make the difference
Getting data governance right does not require a lengthy transformation programme. It requires three habits applied consistently from the start.
- Define fields, not columns. Rather than a single “comments” column that becomes a dumping ground, break information down into its component parts. What outcome was recorded? What defect was raised? What action is required? Each of those is a separate, structured field.
- Use controlled values. Dropdowns instead of free text. Standard inspection types instead of whatever the engineer decided to write that morning. This sounds like a small thing, but it is what makes aggregation and reporting possible without manual interpretation.
- Link everything. An inspection record should link to an asset. A document should link to the requirement it fulfils. A task should link to a deliverable. Without these connections, you have data. With them, you have information.
The practical upside
When eviFile supported the Transpennine Route Upgrade, the team was able to bring together assurance data from across multiple disciplines, including overhead line, signalling, and civils, into a single environment. Because the underlying data was structured from the outset, reporting became largely automated. The manual effort that would normally sit behind a weekly dashboard simply was not needed.
On a recent rail signalling scheme delivered with AtkinsRéalis, nearly 300 Wheel Detection Point records were captured digitally using structured workflows, saving an estimated 900 to 1,500 hours compared to a document-based approach. All because the information had been defined clearly before anyone went near a mobile device.
The real gap
Most project trackers are trying to answer three questions: what is done, what is not, and who is responsible? The problem is not the questions. It is that they are answered manually, inconsistently, and too late.
What good looks like: a quick reference
The table below shows the difference between how information is typically captured on site, a structured improvement, and what best practice looks like when governance is set up correctly from the start.
|
Field |
Poor (Typical Tracker) |
Good (Structured) |
|---|---|---|
|
Identification |
Inspection name (free text) |
Inspection ID (auto-generated, unique) |
|
Asset link |
Area or location (free text) |
Asset ID linked to asset register |
|
Responsible party |
Subcontractor name (free text) |
Named individual with defined role |
|
Inspection type |
Free-text description |
Controlled list (standard types only) |
|
Date |
Typed manually, inconsistent format |
Captured automatically at submission |
|
Outcome |
Status column (free text) |
Controlled field: Pass / Fail / Conditional |
|
Issues raised |
Comments box |
Linked defect record with unique ID |
|
Document link |
File name in comments |
Document linked to requirement it fulfils |
|
Audit trail |
None |
Full record: who captured, when, and any changes |
If you want to explore what a governed data environment could look like on your programme, we’d be glad to talk it through. Get in touch with the eviFile team for a chat.
