How to integrate scan data into your construction programme

A scanning survey is only as useful as the workflow that consumes it. Plenty of well-executed surveys end up underused because the contractor’s programme doesn’t have a clear place for the data, the engineer’s model doesn’t easily ingest it, or the on-site team doesn’t know it exists. Integration is the difference between data that informs decisions and data that sits in a folder.

Here is how to integrate scanning into a UK construction programme so it earns the spend.

When in the programme

Different surveys belong at different points in the programme:

Pre-design surveys. LiDAR existing-conditions capture, large-scale GPR utility mapping, baseline drone capture. These belong before substantive design begins. The earlier they happen, the more design work they save.

Design-phase surveys. Façade surveys, detailed reinforcement mapping for retrofit work, NDT for structural assessment. These belong during the design development phase, where they inform decisions that go into the construction documents.

Pre-construction surveys. PAS 128 utility verification, additional GPR before specific intrusive works, drone progress baseline. These belong immediately before the works they support.

Construction-phase surveys. Pre-drill scanning, ad-hoc verification of as-built quality, drone progress capture. Routine, integrated into the programme.

Handover surveys. Final as-built capture, completed-works verification, asset records for the client. These belong at completion.

A programme with scanning slotted at the right points produces a smooth flow of data into decisions. A programme with scanning slotted only at the last minute often discovers that the data has nothing to inform any more.

Who owns the data

Within the project team, the scanning data needs an owner. Common patterns:

• The contractor’s design manager owns LiDAR, GPR, and PAS 128 deliverables on a design-and-build project.
• The engineer owns NDT and structural assessment data.
• The contractor’s site team owns pre-drill scanning data on the day-to-day.
• The client’s BIM coordinator owns the master point cloud on a BIM-coordinated project.

Whoever owns it must:

• Receive the deliverable.
• Make sure it is in the project record system in a known location.
• Brief downstream users on its existence and content.
• Keep it current as conditions change.

Without a clear owner, the deliverable risks being forgotten.

How to ingest the data

For each kind of deliverable, a typical ingest workflow:

LiDAR point clouds. Loaded into the BIM environment as reference (Recap project for Autodesk users, or equivalent). Distributed to the design team. Drawings and models derived from the cloud are tagged with the cloud’s reference.

GPR and ferro CAD plans. Imported into the project drawing set, on a reserved layer, referenced to the project coordinate system. Added to the architectural and structural drawings as appropriate.

NDT reports. Filed in the engineering record system. Headline findings and characteristic strengths summarised in the engineer’s calculation report.

Drone orthomosaics. Loaded into GIS or project management platform as a base layer. Updated monthly for progress capture.

Inspection reports. Filed in the asset register or defects log, with clear references to the captured imagery.

The pattern is consistent: every deliverable has a known home in the project’s information architecture, and a known link to the workflow it supports.

Linking data to decisions

A scanning deliverable is most useful when it is linked to the specific decisions it informs. Common decision-data links:

• Pre-drill scan → drilling plan sign-off → drilling permit issue.
• Reinforcement mapping → engineer’s analytical model → assessment output.
• PAS 128 utility map → excavation method statement → excavation permit.
• Cover-depth survey → durability assessment → mitigation specification.
• LiDAR cloud → design package → coordination model.

A project that articulates these links explicitly — in the programme, in the document control register, in the meeting agendas — is a project that uses its data well.

Information governance

For projects following BS EN ISO 19650 or comparable BIM frameworks, scanning deliverables fit into the project’s information governance:

• Naming conventions.
• Status codes (work-in-progress, shared, published).
• Approval workflow.
• Archival rules.

Scanning deliverables that don’t fit the governance get treated as ad-hoc — and tend to be lost or forgotten. A short conversation with the project’s BIM manager before commissioning the survey ensures the deliverable arrives in the right format and the right metadata for the project’s information system.

Common integration failures

Cloud sits outside the BIM environment. A point cloud delivered as files but never loaded into the project’s federated model is a wasted asset. Integration is the work; the file is the input to it.

CAD plan never overlays the design drawings. A DXF in a different coordinate system is hard to use. Specify the coordinate system in the brief.

Report distributed but not read. A report sent as an email attachment that nobody opens is not informing decisions. Brief the relevant team members on the headline findings.

Data not maintained. A point cloud captured before construction starts is no longer current after construction. Where currency matters, plan re-capture into the programme.

Stale data treated as current. A scan from a previous project, treated as if it represented the current condition. Always check the date and conditions of any data inherited from a previous project.

Practical advice

For a contractor or designer planning the use of scanning data:

1. Plan the surveys at the right points in the programme.
2. Assign a clear owner to each deliverable.
3. Specify the deliverable formats to fit the project’s information system.
4. Articulate the decision-data links in the programme.
5. Brief the team on the existence and content of each deliverable.
6. Plan refresh captures where the data needs to remain current.

A scanning deliverable that is integrated into the project’s workflow earns its cost many times over. A deliverable that lives in a folder unread is wasted budget. The discipline of integration is what separates the two.