Ask ten architecture firms how they organize project documents and you'll get ten different answers. And if you look at the actual folder structures, you'll probably find that most of them, including the ones with documented policies. Have evolved into something messier than anyone intended.
That's not a failure of discipline. It's a predictable outcome of a system that wasn't designed to handle the volume and variety of documents that a real design project generates.
This post lays out a practical approach to document organization: one that's simple enough to actually maintain, flexible enough to handle different project types, and structured enough that anyone on the team can find what they need without asking.
The Problem with Organic Organization
Most firms start with a reasonable folder structure and then watch it drift over the course of a project. The culprits are familiar:
- Files saved in the wrong folder because someone was in a hurry
- Folders created ad-hoc for specific deliverables that don't fit the existing structure
- "Archive" folders that accumulate everything without any system
- Consultant deliverables mixed with internal files because there was nowhere else to put them
- Multiple versions of the same file in the same folder with slightly different names
The result is a project folder that becomes less usable over time, not more. And a team that spends increasing amounts of time looking for things.
The Core Principle: Separate by Purpose
The most durable document organization systems separate files by their purpose and their audience, not just by their type.
A drawing is different from a meeting minute, which is different from a consultant deliverable, which is different from a client submittal — even if they're all PDFs. Putting them in the same folder because they're the same file type is how folders become useless.
A purpose-based structure looks something like this:
[Project Number] — [Project Name]
├── 01, Project Management
│ ├── Contracts
│ ├── Schedule
│ ├── Meeting Minutes
│ └── Correspondence
├── 02 — Design
│ ├── Schematic Design
│ ├── Design Development
│ └── Construction Documents
├── 03: Drawings, Current
│ ├── Architectural
│ ├── Structural
│ ├── MEP
│ └── Civil
├── 04 — Drawings. Archive
├── 05, Specifications
│ ├── Current
│ └── Archive
├── 06: Consultant Deliverables
│ ├── Structural
│ ├── MEP
│ └── Civil
├── 07: Client Submittals
│ ├── SD Submittal
│ ├── DD Submittal
│ └── CD Submittal
├── 08, Permits
│ ├── Submission
│ └── Review Comments
└── 09, Reference
├── Site Information
├── Code Research
└── PrecedentThis structure isn't universal, adapt it to your firm's workflow. But the underlying logic applies broadly:
- PM documents are separated from design work
- Current drawings are separated from archived versions
- Consultant deliverables are separated from internal work
- Client submittals are a distinct category — what went out to the client, formally
The "Current" Folder Rule
The most important convention in any document organization system: there should be exactly one place that always contains the current version of every active document.
Call it "Current," call it "Active," call it whatever makes sense. But enforce the rule: when a new version is issued, the old version moves to Archive. The Current folder never contains superseded files.
This single rule prevents the most common version control problem: a team member opening a folder, seeing two versions of a drawing, and guessing which one is current.
Naming Conventions That Actually Work
Files are only as findable as their names allow. A naming convention needs to be:
Consistent., everyone on the project uses the same format
Descriptive. The filename tells you what the file is without opening it
Sortable. — files in alphabetical or numerical order should also be in a logical order
A working convention for drawing files: [Discipline]-[Sheet]-[Description]-[Rev]-[Date]
For other documents: [YYYYMMDD]-[Document Type]-[Description]
The date at the front of non-drawing files (using YYYYMMDD format) makes folders sort chronologically, which is usually how you want to find correspondence, meeting minutes, and similar documents.
Consultant Deliverables: The Special Case
Consultant files need to live in your system, but they follow their own naming conventions — and you can't control that. The practical solution: create a folder structure for consultant deliverables that mirrors your own drawing structure, and enforce the "current vs. Archive" rule there too.
When a consultant issues an updated set, the old set goes to archive, the new set goes to current. Simple. Consistent. Auditable.
One additional step worth the effort: a consultant log that tracks what was received, from whom, and when. Not elaborate — a spreadsheet with five columns is enough. But when there's a coordination dispute later, knowing exactly what version of the structural drawings you had access to on a specific date is valuable.
Who Owns the System
A document organization system is only as good as the discipline behind it. In practice, that means:
- Someone has explicit ownership of the project folder structure
- That person is responsible for enforcing the naming convention and the current/archive rule
- New team members are briefed on the system before they start adding files
- The system is reviewed and cleaned up at each phase transition — SD to DD, DD to CDs
The review at phase transitions is easy to skip and worth doing. Old SD files that were loosely organized can be cleaned up before they become a problem in DD. An hour of organization at the phase transition prevents three hours of searching during the next phase.
The Honest Caveat
No folder structure survives contact with a chaotic project completely intact. Files will end up in the wrong place. Old versions will accidentally stay in Current. That's normal.
What you want isn't a perfect system. It's a system that's good enough that people can find what they need most of the time, and that errors are obvious when they happen rather than invisible until they cause a problem.
That bar is achievable. It just requires a structure that makes sense, a naming convention that's enforced, and someone who takes ownership of keeping it that way.
