On MOD construction projects, collaboration is constant. Drawings, RFIs, revisions, and mark-ups move between principal contractors, subcontractors, and specialist trades throughout the lifecycle of a programme.
Decisions made in one part of the supply chain affect others. Coordination isn’t a phase of the project – it’s continuous. In theory, the process is structured. In practice, it rarely stays that way.
Information doesn’t sit in one place. It moves across email, shared drives, partner systems, and project tools, depending on who needs it and when. Each environment holds its own version of events, and keeping them aligned becomes harder as the project grows. What starts as a manageable set of shared folders and distribution lists becomes progressively harder to see clearly, let alone control.
Version control is where this starts to show. A drawing is issued, marked up, revised, and reissued – sometimes multiple times in a short period. As soon as that process crosses organisational boundaries, consistency depends less on systems and more on people. Someone continues working from a previous version while an updated drawing is already in circulation. It only takes one instance for rework to follow, often surfacing after work is already underway.
The gap between site and office adds to this. Site teams work with what’s accessible and practical in the moment. That often means downloaded or locally stored information, because waiting for systems or connections isn’t compatible with the pace of a live programme. Meanwhile, the office continues working from central systems. Both approaches are valid, but they don’t always stay aligned – and the gap tends to widen as the project progresses.
Subcontractors introduce another layer of complexity. Each one needs access to the right information at the right stage, and that access changes over time. A groundworks contractor needs different information to a specialist M&E subcontractor coming on site months later. Managing that across multiple parties – each with their own systems and ways of working – creates overhead that scales with the programme. Onboarding, access control, and offboarding are not one-off activities; they’re continuous.
Then there’s the added complexity of secure and non-secure environments. On MOD projects, that boundary is real. Information often needs to move between classified and unclassified contexts, and when it does, it’s rarely seamless. In many cases, the gap is bridged manually. That introduces delay, increases the risk of error, and contributes to the version fragmentation that causes problems elsewhere.
None of this is unusual. It reflects how large, multi-party projects operate under real constraints.
The issue is that small inconsistencies compound over time. Version control becomes less certain. Visibility over access reduces. More time is spent reconciling information than using it. Conversations that should be about progress become conversations about which document is current and who is working from what. At programme scale, that overhead is significant, and largely avoidable.
Addressing this isn’t about adding more process. It’s about creating environments where information, access, and control stay aligned as the programme evolves.
Related Links:
