©2020, Ontario Association of Architects (OAA). Management of the Project articles may be reproduced and distributed, with appropriate credit included, for non-commercial use only. Commercial use requires prior written permission from the OAA. The OAA reserves all other rights.
Introduction:
This article is the second in a series to address the subject of Document Control. The series addresses the storage, retrieval, internal use and distribution of electronic information. The first article focussed on file naming conventions. This particular article (the last of 4 parts) deals with 'Internal Filing Systems' for external and internal documents in an architectural practice. The various documents being filed may be related to the management of the practice, the management of a project or to resource materials available.
Part 4 discusses considerations for the filing of documents which are resources for multiple projects and which may constitute the office library.
Resource Files
Resource material is generally material that could be applicable to more than one project and that is persistent over a period of time. It is filed in a central location to be accessible to all users. You may consider copying files that have been used by a project to the project file so that it is archived with the project. Such material may include manufacturer’s product brochures, and applicable versions of codes and standards or by-laws. Doing so means that when you restore a project several years later, you don’t have to search for material related to why you designed it a certain way or selected the products you did. All that material is restored with the project.
The resource material includes those items that would have in the past typically been found in an office library. It will include files that originate within a practice and those that come from third parties. Some of the material is suitable for filing by project phase, some by specification section, and some by type of content. In some cases, what is stored electronically may be a link or URL to an on-line resource. The following is an example of how such information might be grouped at a high level:
\Resources
\Legislation
\OfficeStandards
\ProductLit
\ReferenceDocs
\Standards
\TrainingMaterial
\01_ProjectPlanning
\02_PreDesign
\03_SchematicDesign
\04_DesignDev
\05_ConsDocs
\06_Bidding
\07_ContractDocs
\08_ContractAdmin
\09_PostCons
To keep the project phases in chronological order, they have been numbered sequentially.
The reference material may originate in different jurisdications or countries or be international in application. It may be convenient to organize by place of origin.
For example:
\Standards, or \Legislation or \ReferenceDocs or \ProfOrganizations
\00_Canada
\01_BritishColumbia
\02_Alberta
\03_Saskatchewan
\04_Manitoba
\05_Ontario
\06_Quebec
\07_NewBrunswick
\08_NovaScotia
\09_PrinceEdwardIsland
\10_Newfoundland
\11_YukonTerritory
\12_NorthwestTerritories
\13_Nunavut
\90_USA
\99_International
This structure may be adopted to file lien acts, building codes, accessibility requirements, etc. Subfolders could be added for cities to file zoning by-laws, and municipal guidelines. Here the numbering imposes a West to East order on the provinces.
It may also be useful for grouping standards by place of origin and organization by adding a subfolder level as for example:
\Standards
\00_Canada
\CSA
\CuL
\CGSB
\05_Ontario
\OPSS
\90_USA
\ASTM
\ANSI
\99_International
\ISO
Similarly, reference documents from organizations such as IBC, BRI, DN, CCDC, CSC, NMS, etc., may be also organized by country of origin.
Product literature and master specifications will most suitably be subdivided into folders for each MasterFormat division and broadscope section (if appropriate) or for each UniFormat functional element.
Summary
There is no one filing system that is ideal for all situations. The best filing system is one that suits today’s needs and may be adapted to suit tomorrow’s needs with little effort. This argues that the best filing system should be:
1. based on clearly defined principles that are easily understood.
2. be unambiguous. That is, there should be one, and only one obvious location to file any particular piece of information.
3. be extensible. So additional file locations can be added as needed to suit project complexity or software changes.
4. be intuitive (and where not intuitive, provide a legend).
5. be consistent in folder naming
These articles do not represent OAA policy or guidance but rather are based on the opinions and experiences of members of the OAA and are prepared for the benefit of the profession at large.
Updated: 2020/May/06