Version Control in Construction: 5-Step Framework

Version control in construction still fails without software because manual naming conventions, email distribution, paper transmittals and Excel logs cannot reliably control thousands of changing documents across multiple parties. Effective control means ensuring that each participant uses the current, approved and contractually valid drawing, specification, RFI response or submittal—and being able to prove who had which version, when, and for what work.

The risk is measurable. Rework can represent 5–20% of total construction cost, while Autodesk and FMI attributed 52% of rework to poor project data and miscommunication in their 2018 survey. PlanGrid and FMI reported that 24% of respondents had carried out rework because teams worked from the wrong project documents. Version control is therefore not a filing exercise. It is a project-controls process connecting information status to decisions, site work, quality records, payment and contractual evidence.

What Version Control In Construction Why It Still Fails Without Software Means in Practice

In plain terms, version control is the controlled creation, review, approval, issue, use and supersession of project information. It covers drawings, models, specifications, method statements, inspection and test plans, RFIs, submittals, site instructions and as-built records.

The phrase is often misunderstood as “put a revision letter in the filename”. A revision code identifies a change, but it does not by itself prove that the change was approved, communicated to the right trade, received on site or used after its effective date. A document can have the correct revision label and still be in the wrong folder, attached to an old email or printed in a site office.

ISO 19650-1:2018 and ISO 19650-2:2018 frame information management around a Common Data Environment (CDE), defined states, status codes, revision codes and controlled acceptance and authorisation. BS EN ISO 9001:2015, Clause 7.5, also requires documented information to be identified, reviewed, approved, kept current and protected from unintended use when obsolete.

For an owner, the practical test is temporal: “Which drawing was current for this zone on the date the work was installed?” A credible answer requires a time-stamped history of revision, approval, distribution and access—not simply the latest file visible today.

Why This Matters for Document Controllers & Project Coordinators

Document Controllers and Project Coordinators sit at the point where design information becomes authorised project information. Their work supports the Engineer, consultant, contractor, subcontractors, quality team, commercial team and owner’s governance process.

A controlled workflow should answer five questions without reconstructing an email trail:

• Who created or revised the information?
• Who reviewed and authorised it, and under which status?
• When did it become current or suitable for construction?
• Which people, trades or locations received or acknowledged it?
• Which RFI, submittal, instruction or change explains the revision?

That evidence matters under contracts where communications must be readable, copyable and recordable. FIDIC 2017 Clause 1.4 addresses communications, while disputes may turn on whether the latest approved drawings and specifications were available and used. A RACI must therefore distinguish system approval from contractual authority: a project user clicking “approved” is not necessarily the same as the Engineer or Contract Administrator authorising information for construction.

The operational consequences are also significant. Newforma’s 2018 AEC survey found that 51% of architects and engineers considered finding the right information a top challenge, and 46% cited version-control issues as a frequent problem. PlanGrid and FMI found that construction professionals spent 35% of their time on non-productive activities, including looking for information, resolving conflicts and handling mistakes and rework.

For a document controller, control protects more than the document register. It protects the project’s ability to explain why work was performed, what information governed it and whether a later variation or defect relates to an authorised change.

The Traditional/Manual Approach — and Where It Breaks Down

The traditional process usually combines a folder structure on a shared drive, filenames containing revision letters, email attachments, paper issue sheets and an Excel transmittal log. The document controller receives a revision, checks its naming and metadata, records it, sends a transmittal and asks recipients to replace old copies.

This can work for a small, stable document set. It becomes brittle when drawings, specifications, RFIs and submittals change across disciplines, zones and packages. A shared drive is not automatically a CDE: ISO 19650 describes a managed information process with states, responsibilities and controlled exchanges, not merely a storage location.

The last-mile problem is particularly persistent. A crew may print a drawing in the morning, while a revised version is approved later. A supervisor may keep an offline PDF on a tablet without checking whether it has synchronised. The central register can be correct while field use remains uncontrolled.

RFIs and submittals also need to be treated as versioned decisions, not email-like conversations. If RFI-102 clarifies a detail on drawing A-301, the response should be traceable to the drawing or specification revision that implements it. Otherwise, the project may know that a question was answered but not which answer governed pricing, installation or inspection.

The scale of the exposure explains why the manual approach fails silently. McKinsey reported in 2017 that non-value-added activities, including rework and searching for information, could account for 30% of construction cost, and estimated global construction inefficiency at $1.6 trillion annually. Those figures cover more than version control alone, but they show why information retrieval and miscommunication are project-controls concerns rather than administrative inconveniences.

Step-by-Step Framework

Step 1 — Assess current state

Start with a two-week sample of active information rather than a general workshop. Select critical IFC drawings, specifications, method statements, ITPs, RFIs and submittals from one package or zone. For each item, record its source, filename, revision, status, approval authority, issue date, recipients, acknowledgement and current field location.

Ask whether the team can answer “Which revision of drawing X was current on 14 March?” within minutes. Count the number of sources of truth: CDE, network drive, SharePoint, email, WhatsApp, personal laptops, paper files and subcontractor systems. Test whether an RFI answer can be traced to the document it affects.

Use the UK BIM Framework information-management guidance as a reference for assessing standards, roles, CDE usage, exchanges and quality control. Establish a baseline for wrong-version events, search time, RFI turnaround, metadata completeness and the time between approval and field access. Do not set arbitrary “good” targets; first measure the existing process.

Step 2 — Define standards, templates & governance

Write the rules before configuring a tool. Define the information container, naming convention, metadata, revision code, status code, review route, approval authority, distribution method and supersession rule for each document type.

ISO 19650 provides a useful structure for agreed status codes such as S0–S4 and authorisation codes such as A, B and C, or equivalent project-specific values. A practical status set might include WIP, For Review, For Comment, For Construction, As Built and Superseded. Each value must have a business meaning, not just a label.

Build a RACI that identifies who can create, modify, review, approve and publish drawings, RFIs, submittals, procedures and ITPs. Map those permissions to the contract. Under a FIDIC project, define which role can authorise information for construction and how that approval relates to instructions, notices and variations.

Set review service levels—for example, a project may agree a seven-day RFI response period—but treat that as a project rule, not a universal benchmark. Create templates for transmittals, RFI references, submittal registers, acknowledgement records and superseded-document notices. Include discipline, zone, phase, status and revision fields so the current document can be found without relying on memory.

Step 3 — Select & implement supporting technology

Select technology against the workflow, not the storage capacity. A supporting CDE should provide automatic version history, clear current status, permissions, approval workflows, distribution records, time-stamped audit logs and field access. It should connect RFIs and submittals to the documents and drawings they reference.

Check the full sequence in a pilot: upload a revision, route it for review, authorise it, distribute it, acknowledge it on mobile, supersede the previous version and retrieve the state at a historic date. Test offline behaviour and confirm how the system warns users about outdated content.

Integrated platforms are relevant because isolated tools create “islands of automation”, a concern identified in McKinsey’s construction technology research. Deloitte’s 2020 Engineering & Construction Industry Outlook likewise described cloud collaboration, BIM and integrated platforms as important to reducing delays, cost overruns and disputes. Integration should include project controls, quality, commercial records and handover—not only a document folder.

AI can support the process by classifying documents, extracting revision and discipline information, linking RFI text to drawing numbers and identifying repeated access to superseded files. It should surface a reviewable signal, not silently change a contractually consequential record.

Step 4 — Roll out, train and monitor adoption

Begin with one project, package or discipline. Train by role: document controllers need configuration and audit skills; project coordinators need routing and escalation; site engineers need current-document retrieval; subcontractor foremen need simple access and acknowledgement steps.

Assign a superuser in each discipline or location. Publish one operational rule: if a document, RFI or submittal is not in the agreed CDE, it is not the controlled project record. That rule must be supported by contract communications and practical access; otherwise teams will continue using email attachments, WhatsApp or local servers.

Review adoption weekly during the pilot, using 15–30-minute feedback sessions to remove friction. Report the percentage of RFIs raised through the system, the percentage of drawings accessed through the CDE and the number of uncontrolled distributions. Train field teams to check the current status before using a printout or offline file.

Step 5 — Measure impact against baseline KPIs

Measure version control as a project outcome, not as the number of files uploaded. Set targets relative to the baseline because the dossier contains no universal numeric benchmark for an acceptable search time, synchronisation lag or adoption rate.

Also track self-reported search time before and after implementation. The objective is not a generic productivity claim; it is to determine whether the team spends less time finding, checking and reconciling project information, against the 35% non-productive-time finding reported by PlanGrid and FMI in 2018.

Common Mistakes to Avoid

• Calling a shared drive a CDE. Storage without controlled states, permissions, workflows and auditability does not satisfy the information-management process described by ISO 19650.
• Using filenames as the control system. Naming is necessary, but it cannot prove approval, distribution, acknowledgement or historic status.
• Keeping email and Excel as parallel records. A shadow register creates duplicate data and conflicting evidence. Use email for notification where required, but keep the controlled record in the agreed workflow.
• Leaving superseded files easy to use. Obsolete information should be clearly marked, controlled and prevented from unintended use, consistent with ISO 9001:2015 Clause 7.5.
• Confusing system approval with contractual authority. Configure permissions around the contract RACI, including who can issue information for construction.
• Ignoring subcontractor and field behaviour. A process fails if the people installing the work cannot quickly access and acknowledge the current information.
• Tracking uploads instead of consequences. A full register can coexist with wrong-version rework. Track wrong-version events, MTTS, current-document coverage and cost-coded rework.

How AI-Native Platforms Like Zepth Change This Workflow

An AI-native approach treats the CDE as a working project environment rather than a passive archive. The controlled record remains governed by roles and approvals, while AI helps people find relationships and risks across documents, RFIs, submittals and project controls.

Zepth Core provides the documents, RFI, submittal, quality, safety and site-operations workflows in the project environment. Zepth AI reviews submittals and RFIs against drawings and specifications, returns a confidence score, and can draft RFI responses with cited references. A human must sign off anything consequential.

That matters to version control because the question is not only whether a file is newer. It is whether a response is consistent with the governing drawing and specification, whether a clarification changes design intent, and whether the resulting decision is traceable. Zepth AI can help surface those relationships for review rather than asking a document controller to search separate folders and email chains.

For owners, developers, PMCs and owner’s engineers, the wider value is continuity from information control to governance. Zepth AI’s intelligence layer works across Zepth Core, Zepth Vector procurement workflows and Zepth Edge asset and financial management. This creates a route from an approved project document to procurement, cost, risk, handover and MIS reporting without treating each record as an isolated file.

The architecture does not remove accountability. The document controller, reviewer, Engineer, Contract Administrator or owner’s representative still decides whether information is accepted, issued or acted upon. AI supplies references, confidence and early signals; authorised people make consequential decisions.

Zepth does not charge per seat or per collaborator and does not price on construction volume. For an owner-side team, that supports participation by the people who need to review, acknowledge or act on information without treating collaboration as a separate metered resource.

The practical test remains the same: can the team retrieve the right version, understand why it changed, see who authorised it, prove who received it and connect it to the RFI or submittal that informed the work? If the answer is still dependent on an individual’s inbox or spreadsheet, the control is not yet reliable.

For a project-specific discussion of the workflow, schedule a walkthrough. You can also subscribe to Zepth Insights and download the related version-control framework and checklist to assess your current process.

FAQ