Technology Optimization

The 5 Signs Your Construction Programme Has Outgrown Its Document Management System

Prabal Laad
March 31, 2026

Still using shared drives, email chains, or a basic DMS on a major infrastructure programme? Here are five unmistakable signs it is time to move to a proper CDE and what to do about it.

At some point, the system that was working stops working. Not dramatically - there is rarely a single failure. It happens gradually: a disputed revision here, a missed transmittal there, a handover pack that takes three weeks to assemble. By the time the problem is obvious to everyone, it has already been costing the programme for months.

Most construction teams do not proactively upgrade their document management. They wait until a crisis forces the conversation - a regulatory audit, a version control dispute that escalates to a formal claim, or a handover that takes longer to assemble than anyone is willing to admit publicly. This post exists to help teams recognise the warning signs earlier, before a dispute or a handover disaster makes the decision for them.

If more than two of the following signs are familiar, it is probably worth a conversation about what comes next.

Sign 1: Nobody can confidently say which version is current

This is the most universal symptom, and the one that teams tend to normalise until it causes a serious problem. If answering “which revision of this drawing is current?” requires opening three different folders, checking two email threads, and calling someone who was on the project six months ago, the system is already failing.

What it looks like in practice

  • Filenames suffixed with _FINAL, _FINAL2, _APPROVED_USE_THIS, or _REV_C_ISSUED
  • Multiple people holding different versions of the same drawing, neither aware the other exists
  • A contractor building from a superseded revision because the updated drawing was sent to the wrong distribution list
  • Disputes at site about which drawing takes precedence, with no definitive system answer available

Without enforced version control and defined information states, version management depends entirely on individual discipline. At small project scale, that can work. At programme scale, multiple organisations, hundreds of live documents, dozens of simultaneous revisions - it breaks down. The cost is not administrative inconvenience. A single instance of construction from the wrong revision can generate tens of thousands of pounds in rework. The document management problem is a direct programme risk.

A properly configured CDE enforces a single authoritative published state. Only one version can be Published at a time. The history is preserved in full, but the current state is unambiguous - for every organisation on the project, simultaneously.

Sign 2: Your audit trail lives in people’s memories, not the system

This sign is less visible day-to-day but becomes catastrophic at the moments that matter most: a formal dispute, a regulatory audit, a defect investigation, or a challenge to the handover record.

What it looks like in practice

  • “Who approved this revision?” answered with “I think it was Sarah, but she left the project”
  • Transmittals reconstructed from email threads because no formal transmittal register was maintained
  • No record of when a document was issued, to whom, and whether receipt was acknowledged
  • An audit finding that cannot be evidenced because the approval happened verbally or via a Teams message

The audit trail is not just a compliance requirement. It is the programme’s institutional memory. When key people leave - and they always do, the audit trail is what remains. A document management system that cannot produce a timestamped, role-attributed approval history for every document on the project is not a document management system. It is a filing cabinet with a search function.

Every state transition, approval decision, review comment, and transmittal in a properly configured CDE is logged automatically, with timestamps and user attribution. It requires no additional effort from the project team, it is a byproduct of working in the system correctly.

Sign 3: Adding a new supplier or designer is a manual ordeal

Large infrastructure programmes are not static. Organisations join and leave throughout the lifecycle - new specialist contractors, replacement designers, additional consultants. The ease or pain of onboarding them is a direct and honest measure of whether the document management system is fit for purpose.

What it looks like in practice

  • New organisations need a full induction just to understand where things are stored and how they are named
  • Access permissions managed via a spreadsheet maintained by one person, with no audit of who has access to what
  • New team members receiving a ZIP file of “current” drawings on day one, immediately creating an offline copy that will drift from the live record
  • A week of email chains before a new supplier can submit their first document correctly

Every new organisation that starts with a poor understanding of the project’s information structures adds noise to the document register. Bad habits established at onboarding persist for the life of the appointment and compound as more organisations join. A well-configured CDE with role-based access templates and built-in naming validators can onboard a new organisation in hours, not days. The guidance is embedded in the environment, not communicated in a PDF that nobody reads.

Sign 4: Handover preparation starts months before completion - and still isn’t clean

If assembling the handover information pack requires a dedicated workstream, late nights, and a team of people chasing documents from across the supply chain, that is not a handover problem. It is the accumulated cost of an information management approach that has been generating debt throughout the project’s life.

What it looks like in practice

  • A “handover coordinator” role that exists solely to chase and reformat documents from multiple sources
  • O&M manuals, as-built drawings, and commissioning records stored in different systems, named inconsistently, requiring manual reconciliation
  • Metadata that does not exist or does not match what the asset management system expects at handover
  • A handover pack that takes three months to assemble for a project that took three years to build

Handover pain is always a symptom of upstream information management failure. If documents have been correctly named, tagged with asset metadata, and maintained in defined states throughout the project, handover is largely automated, a filtered export from the CDE, not a manual assembly exercise. A CDE with asset-linked metadata and integration to the asset management system produces a handover-ready information model as a byproduct of the project, not as a separate workstream bolted on at the end.

Sign 5: Programme reporting relies on someone manually collating a spreadsheet

When the question “where are we with document approvals?” requires a person to spend half a day querying a shared drive, exporting data, and manually updating a status tracker, the document management system has become a liability rather than an asset.

What it looks like in practice

  • Weekly document status reports that are already two days old by the time they are distributed
  • No visibility across multiple projects simultaneously, each project team manages their own register in isolation
  • The programme manager relying on anecdotal updates from project managers rather than live system data
  • Portfolio-level reporting impossible without a significant manual aggregation effort across multiple spreadsheets

The further up the programme hierarchy you go, the more consequential timely document status information becomes. Senior stakeholders making decisions about resource allocation, risk, and programme schedule need current data, not a snapshot assembled on Tuesday and distributed on Thursday. A CDE with Power BI integration or built-in dashboards provides live document status, approval progress, and MIDP compliance reporting at project, programme, and portfolio level, with no manual aggregation required.

Recognising the signs is the first step. Here is what comes next.

If several of these signs are familiar, the challenge is not identifying that there is a problem. The challenge is deciding how to address it without disrupting a programme that is already in flight. Three things are worth knowing before starting that conversation.

  • Start with an honest current-state assessment. Before evaluating any platform, map how documents are currently named, where they live, who has access, and what your handover requirements actually are. The gap between current state and target state is the scope of the change programme. Skipping this step is the single most common reason CDE implementations underdeliver.
  • Platform selection is secondary to configuration. The most common implementation mistake is choosing a CDE and assuming that ISO 19650 compliance follows automatically. It does not. Folder structures, metadata schemas, naming validators, and approval workflows must all be configured intentionally. The platform is the vehicle. The configuration is what makes it work.
  • Supply chain readiness is the hardest part. Your CDE is only as good as the least-engaged organisation using it. Plan for structured onboarding, role-based training, and ongoing governance from day one, not as an afterthought once the platform is live.

If more than two of these signs are familiar, it is probably worth a conversation. Contact VE3 to discuss your programme’s current state and what a transition would involve.

Get in touch now.

  • © 2026 VE3. All rights reserved.