Somewhere in every architecture firm's history, there's a story about the wrong drawing. The one that went out to the contractor after Rev D was already issued. The one that sat in the GC's set for three weeks after the architect updated the detail. The one that led to a wall being framed in the wrong location, and a conversation nobody wanted to have.
It's not usually negligence. It's a version control problem, and it's more common than anyone in the industry likes to admit.
This guide covers what effective drawing version control looks like in practice: the naming conventions, the distribution protocols, the tooling decisions, and the habits that separate firms where version confusion is rare from firms where it's chronic.
Why Version Control Breaks Down
The short answer: because design is iterative and distribution is manual.
Drawings change constantly during the design phase: sometimes multiple times a week on fast-track projects. Every change creates a new version. Every version needs to get to the right people. And every person on the project team has a slightly different idea of where "the current set" lives.
Add external consultants who are working in their own systems, clients who save PDFs to their desktop, and a GC who prints the set on day one and rarely checks for updates and you have the conditions for version chaos.
The standard approach, emailing updated drawings to a distribution list: fails for a predictable set of reasons:
- People miss the email or don't read it carefully
- Attachments get saved in the wrong folder, next to the old version
- There's no reliable way to know whether someone is actually working from the current set
- When something goes wrong, the audit trail is scattered across a dozen inboxes
The Foundation: A Consistent Naming Convention
Before you touch any software, you need agreement on how files are named. A naming convention only works if everyone on the project follows it, including consultants.
A workable convention for architectural drawing files includes:
[Discipline]-[Sheet Number]-[Description]-Rev[Revision Letter]-[YYYYMMDD]
Example: A-201-Floor Plan Level 2-RevD-20250318.pdf
Breaking that down:
- Discipline prefix (A for architecture, S for structural, M for mechanical, etc.) keeps multi-discipline sets organized at a glance
- Sheet number ties the file to the drawing set
- Short description makes it human-readable without opening the file
- Revision letter is the single most important field, it's what tells someone, immediately, whether they have the current version
- Date provides a secondary timestamp that's useful when revision letters get confusing mid-project
A few conventions worth establishing firm-wide:
- Superseded files should be moved to an "Archived" subfolder, not deleted
- Never use "FINAL" in a filename. It will inevitably be followed by "FINAL_v2"
- If a file is issued for construction, mark it clearly — IFC or IFC-RevX — to distinguish it from design development versions
Distribution: The Part Most Firms Get Wrong
Naming files correctly is half the battle. Getting the right file to the right person at the right time is the other half.
The default approach, emailing a PDF to a distribution list when a revision is issued — has obvious limitations. Emails get missed. People reply to old threads. Someone on the list forwards it to a sub who wasn't on the original list and shouldn't be working from that file anyway.
A better system separates storage from notification:
Centralized storage, all current drawing files live in one place, accessible to everyone on the project who needs them. When a new revision is issued, the old version is moved to an archive folder. The live folder always reflects the current set.
Notification, not distribution — instead of emailing the file, notify the team that a new revision is available and point them to where it lives. This breaks the "saving attachments in random folders" habit because there are no attachments to save.
Transmittals as the paper trail — issue a formal transmittal every time drawings are distributed, even internally. The transmittal documents what was issued, to whom, and when. If there's ever a dispute about who had access to what and when, the transmittal log settles it.
Version Tracking: What a Real System Looks Like
A drawing register is the backbone of version control. It doesn't have to be complicated — a spreadsheet with the right columns does the job for many firms. But it does have to be maintained in real time, not reconstructed after the fact.
At minimum, a drawing register should track:
- Sheet number and title
- Current revision letter
- Date of last revision
- Issued for: (Design Development, Construction Documents, IFC, etc.)
- Issued to: (consultant name, contractor, client)
- Notes (what changed, why it was revised)
For multi-discipline projects, each discipline should maintain its own register, with a master index that rolls everything up.
The register is only useful if it's updated every time a revision is issued. Building that habit — updating the register before hitting send on the transmittal, is the single highest-leverage behavior change most firms can make.
Common Failure Modes
Even firms with good intentions run into the same problems repeatedly:
The "latest" folder that isn't. Teams create a folder called "Current" or "Latest" and treat it as the source of truth. But if no one is actively managing what goes in and out, old versions accumulate and the folder title becomes a lie.
Consultant version drift. Your internal set is current. Your structural engineer is still working from the set you sent them six weeks ago. This is especially dangerous when late-stage design changes affect structural coordination.
The client who saves everything. Clients routinely save PDFs to their own drives and email them to their colleagues. Once a file leaves your system, you can't control what version someone is looking at. The only defense is issuing formal supersedure notices when major revisions go out.
Staff turnover mid-project. When the person who maintained the drawing register leaves, the register stops getting updated. The solution is to make the system so simple and so embedded in the workflow that any competent PM can maintain it without a transition briefing.
Tooling
Software helps, but it doesn't solve the problem on its own. The firms with the best version control are the ones where the process is tight, the tool just makes the process easier to maintain.
What to look for in a document management tool:
- Version history linked to the document. When you open a file, you can see every previous version and who issued it
- Access control, not everyone needs to see everything. Consultants should see their scope. Clients should see what you give them.
- Audit trail: who accessed what and when. This matters for disputes.
- Notification system, alerts when a document is updated, so people aren't relying on their memory or their inbox
Olumba tracks every version of every document linked to your project, your team and your consultants always know what's current, without having to ask. It's worth exploring if version control is a recurring source of friction on your projects.
The Bottom Line
Version control is not glamorous. It's not the part of project management that anyone goes into architecture to do. But it's one of the highest-leverage habits a firm can build, because the cost of getting it wrong shows up in rework, disputes, schedule hits, and occasionally, things built in the wrong place.
The good news: a solid version control system doesn't require expensive software or a dedicated document control manager. It requires a naming convention everyone follows, a distribution process that doesn't rely on email attachments, a register that's updated in real time, and a storage system where "current" actually means current.
That's achievable for a five-person firm. It's necessary for a firm of any size.
