The scope of this document goes beyond the confines of Construction Contract Administration (CCA) as it is applicable to any electronic document filing; however, it is particularly important during CCA because of the sheer number and types of documents that are created or received during the construction phase. This article does not address database based document storage and retrieval systems where much if not the entire document is indexed and searchable; it is about filing documents in the simple file systems that most operating systems provide by default.
Just as there is no single best filing system overall, there is no single best filing system for a particular office. The requirements a filing system must respond to and vary depending on the type of project, the number of people who will access the files, the volume of material to be filed, the number of projects to be filed, the means by which files are archived, the frequency with which files are accessed and a number of other parameters. As a result, expect filing systems to be dynamic; changing over time, rather than static.
An office is likely to have several different filing systems in use concurrently. These may include Marketing, Accounting, Reference Material and Project Document filing systems. This article is concerned with Project Document filing only, although many of the principles will be broadly applicable.
There are several inter-related components of a filing system. These are: the file name, the folder name, and the folder structure.
The ability to assign a descriptive/informative file name has come a long way since the 8.3 limitation of MS-DOS, but there are still restrictions. Each operating system will have a number of characters which cannot be used in file names. Each operating system will also have a limit on the number of characters which can be used in the full drive path and file name. The longer the path, the fewer the character count that remains for the file name.
Additionally, if you are automating some aspects of file management/access you should avoid characters which may be interpreted as control characters if the file or folder names are passed to the macro or programming language you are using. If using SQL, avoid the use of embedded apostrophes, quotation marks or ampersands. If you don’t know what SQL is, you probably aren’t using it.
In an effort to simplify the naming of electronic documents they can be divided into two categories. One category would be documents that are specific forms that are sequentially numbered. Examples of this would be Supplemental Instructions and Changes Orders. These could be named in the following manner: CO-01_nnnnn.pdf. This would be Change Order Number 01 for project number nnnnn.
To ensure sequential listing in the operating system, use at least 2 digits for a sequence number. For large or complex projects, you may need to use 3 digits. If you don’t use enough digits, the sort order may not be what you want. (E.g. 1, 10, 11, 12, 2, 3… rather than 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13…)
The other category of documents would be general types of correspondence, reports, minutes etc. that require a more descriptive file name, along with a date to aid in tracking and retrieval. These could be named in the following manner: LTR-20140903_RBrown-Contract_nnnnn.docx. This would be a letter dated September 03, 2014 to R. Brown regarding the contract for project number nnnnn.
The date/time stamp of a file should not be relied upon to determine when a file was issued. If it is important to know when a file dates from, the date should be encoded in the file name. To take advantage of the operating systems sorting capabilities, the date should be encoded as YYMMDD or as YYYYMMDD. This is consistent with both the Canadian standard and ISO 8601:2004- Data elements and interchange formats -- Information interchange -- Representation of dates and times.
Depending on your priorities, you may want to put the document type (e.g. Letter, Transmittal, Change Order) first in the file name followed by the date, or maybe the project name or number. (e.g. YYMMDD_LTR_PermitApp.docx or LTR_PermitApp_YYMMDD.docx) If the first facets of the file name are these types of information, the documents will be grouped when sorted and listed. If the beginning of the file name is highly variable such as a document topic, then there will be little grouping of similar documents.
Where possible, develop and use a consistent system of abbreviations in file names. This both makes scanning the file names easier and preserves the most character positions possible in the file name for descriptive text. As with many things computer related, the particular system used is not critical as long as it is consistently applied. Inconsistency is anathema to document retrieval.
If possible avoid the use of spaces in file names. It uses up valuable character positions and makes handling file names in programs more difficult. Rather than using spaces for readability, try capitalizing the first letter of each word. (e.g. “ThisIsAnExample.doc” rather than “This is an example.doc”) If a file name contains words or abbreviations that are in capitals, readability can be improved by using underscores or hyphens rather than spaces. (e.g. “OAA_CCDC2-Comments_140828.pdf” rather than “OAACCDC2Comments140828.pdf”) It is suggested that underscores be used to separate different types of information and hyphens be used to separate more closely related portions of the file name.
Do not rely on which folder a file is in to identify which project a file relates to. It is too easy to accidentally move or copy files or folders. A simple file name such as “CO-01.docx” is easy to accidentally overwrite since you may create a CO-01 for most projects. A file name with the project number included is much less likely to be accidentally overwritten.
Using project numbers in the file name will assist file searches using the Windows Find command. Searching for file names containing the project number is a good way to locate misplaced files. For this reason one should consider using a project number even with files that have unique descriptions as part of their names
Another reason for using project numbers in file names is that it will assist in file searches using the operating system’s search capability. Searching for file names containing the project number is a good way to locate misplaced files. For this reason one should consider using a project number even with files that have unique descriptions as part of their names.
For some files only the latest version is ever kept. For other files it may be necessary to temporarily or permanently retain multiple versions. It is suggested that the revision number be the last part of the file name immediately before the file name extension. E.g. “OAA_CCDC2-Comments_140828_R0.pdf”
You may choose to use different naming conventions for different types of files or different content. For example, to save having to open a shop drawing file to determine the review status, you can append the status to the file name. i.e. _R, _RaN, _RR, _NR.
Folder names should be brief but descriptive. In some cases the folder name will describe the type of information contained. E.g. “CADD”, “Images”, “Communications”. Some folder names will describe the origin or destination of the contents. E.g. “Incoming”, “Email”. Others will relate to a project phase. E.g. “ProjectCloseOut”.
Do not assume that the folder names are descriptive enough to unequivocally define what is to be stored in a folder. It is important to create an index that identifies where every file is to be saved. This cannot be done all at once, but is an effort over time as each project will have its own peculiarities to find a place for.
By default, folder names are sorted and displayed in alphabetic order. Usually this is not a particularly useful order. It is suggested that folder names be prefixed with an alphanumeric. Use A, B, C, D, etc. for top level folders. Subfolders under A would be prefixed A01, A02, A03, A04, etc. The next level of subfolders would be A01.01 for example. The leading zeroes are important in order to have the folders sort in sequence when there are ten or more folders at the same level.
In this way the folders can be ordered in what you consider the most useful way. It also allows you to refer to a particular folder by stating its number rather than having to state the name of every folder in the complete path. This makes it easier for new users to learn the filing system.
Folders can be organized many layers deep in a hierarchical fashion or wide and flat. There is no single optimum layout for project files. A short duration simple project may only need (among others) “Email”, “Incoming” and “Outgoing” folders. A longer duration, more complex project may be better served with subfolders under “Email” for each year, and for each month below that; as well as under the correspondence folders, subfolders for “Authorities”, “Client”, “Consultants”, “ProjectManager”, “Manufacturers”, etc.
Each one must decide on the appropriate balance between few folders with many files in each, and many folders with few files in each. With fewer folders, it takes less time to decide where a specific file should be saved, but more time to locate a specific file within a folder.
It is advisable to create a template folder structure that can be copied for each new project. If a project is simple, then delete the unneeded folders. As new folders are created for a specific project, the same folder should be added to the template. Over time, fewer and fewer folders will need to be added.
Depending on how you organize your document templates, you may find it helpful to pre-populate the template folder structure with commonly used document templates. Users will get used to finding the templates in specific folders and won’t have to worry about where to save them.
Do not think that you will continue with only one project document folder structure. As new software is adopted, as new backup tools are used, and as work flow processes change, the folder structure will have to change to accommodate the new capabilities and requirements.
Your strategy for backup, archiving of project deliverables, and document retention for legal purposes will influence how the project folder structure is organized. The structure should make it easy to archive or restore all the files related to any specific project.