Document control vs. shared drives: enforcing one current version of a technical document

Document control means enforcing exactly one current version of a technical document, with every prior revision retained and traceable. A shared drive or an email thread cannot do this: both let two people open the same file, edit it independently, and save two different "final" versions with no lock, no lineage, and no record of which one is actually in force.

Where a shared drive breaks down

A folder of files is a storage location, not a control system. It has no concept of:

• A single current version. Anyone can save a new copy under any name; nothing marks one file as the enforced release.
• Concurrent-edit protection. Two engineers can open the same drawing at the same time and each save conflicting changes, with no lock and no merge.
• A controlled hand-over. A revision emailed to a contractor has no record of when it was sent, to whom, or against what transmittal.
• Retention and disposal rules. Old revisions get deleted, renamed, or buried informally, not per a documented schedule.

Employees spend an average of 25% of their workweek searching for documents, information, or people they need to do their job — 2 hours a day (Glean, 2021). None of that time is spent doing the work; it's spent re-establishing which file is actually current.

What document control (DCC) actually enforces

A document-control system built to ISO 15489-1 (records management) and MoReq2010 (strict versioning, check-in/check-out, transmittals, metadata) replaces informal file-sharing with a release lifecycle:

1. Draft → in review → issued → superseded, plus a terminal obsolete state for a full void with no replacement — distinct from superseded, which keeps the prior revision retrievable.
2. Check-in / check-out. A revision under edit is locked to one editor; nobody else can save over it while it's checked out.
3. A revision code on every issued version — engineering codes like C (approved for construction), I (for information), U (approved for use), Z (as-built), separate from the lifecycle state itself, so "issued" and "approved for what" are never conflated.
4. Per-document reviewer/approver chains, resolved from a distribution matrix and a RACI assignment — verify and approve are different roles, not the same signature twice.
5. Transmittals — the controlled hand-over record: a document is delivered and received against a sequential transmittal tied to a master document register, not an email with an attachment.
6. Cryptographic signing on the issued transition, with the file hash recorded for integrity.

Every one of these is a mechanism a shared drive has no equivalent for — not a policy choice, a structural one.

What changes for the people who touch a document

• The DCC controller stops being the informal keeper of "which version is right" by memory — the system enforces it.
• The project or EPC manager references one issued revision from a project plan instead of copying drawings into project folders that immediately start to drift from the source.
• The sponsor answers "which revision is current" with the system, not a phone call.

Adopting it without a big-bang migration

Document control does not require migrating every historical file on day one. A common rollout starts with new and actively-revised documents under control immediately, while historical archives are brought in on a scoped, module-by-module basis — the point is stopping new version ambiguity first, then working backward.

Sources

• Employees spend 25% of the workweek (2 hours/day) searching for documents/information/people — Glean, 2021.
• ISO 15489-1 (records management) and MoReq2010 (versioning, check-in/check-out, transmittals, metadata matrix, cryptographic signing) — standards basis, 02_Products_and_SaaS/e_edms.md.