Author: Ryan Tufts File Management Rules Version 1 – Approved for Use

Table of Contents
Introduction..........................................................................................................................................................1
Definitions............................................................................................................................................................1
Project Directory Template...................................................................................................................................2
Discipline Folders.................................................................................................................................................2
Discipline Folder References...........................................................................................................................3
Working Items..................................................................................................................................................3
0_References....................................................................................................................................................4
1_Working:.......................................................................................................................................................4
2_Checking:..........................................................................................................................................................6
3_Approved:.....................................................................................................................................................7
_Issued:.............................................................................................................................................................8
8 Rules for File Management...............................................................................................................................9

Introduction
The following instructions define how to revise documents, how to keep track of redlines and checkprints, and
how to approve and issue documents to other disciplines, the client, and third parties.

Definitions
Working Item: is a document that we will create or modify and that need to be approved before use
Checkprint: is a snaptshot in time of a Working Item
Redline: is a copy of a Working Item with instructions for changes to be made.

Page 1 of 9
Author: Ryan Tufts File Management Rules Version 1 – Approved for Use

Project Directory Template

Here is the project directory template. This is identical to the current template at this folder level.

Discipline Folders
The “discipline” folders have been simplified. They contain only one subfolder by default. For example, here
is the Electrical discipline folder. Add folders only when needed, rather than starting with a template of empty
folders most of which will not ever be used.

Page 2 of 9
Author: Ryan Tufts File Management Rules Version 1 – Approved for Use

Discipline Folder References

The previous discipline folder structure has been saved as a Reference, within each discipline. For example.
Each of these subfolders are examples of types of “Working Items”.

Working Items
Working Items are documents that we will create or modify and that need to be approved before use. The
folders that are populated in each discipline folder are “Working Items”.
A conceptual sketch, or an email with a scope of work, or a markup of a document used to convey some
information are examples of things that may not require a Working Items folder to keep track of. There will
always be several places that project information is saved besides folders, such as: personal notebooks, emails,
our desks and shelves, Teams sites, our brains, etc. If it isn’t a working item then it is a “Reference” item and
should be saved in a Reference folder (or several different Reference folders).
Working items are either used internally for the project (within a discipline or to be shared with other
disciplines), issued to the client (as a deliverable) or to a 3 rd party. Examples are calculations, reports, drawings,
equipment lists, line lists, diagrams, and many more.
This is the template folder structure for a Working Item:

Page 3 of 9
Author: Ryan Tufts File Management Rules Version 1 – Approved for Use
0_References: file sufficient reference documents for that working item that complete checkprint package
could easily be prepared (if you have to go looking elsewhere for a document or piece of information there is a
good chance that it should also be copied / saved into the Reference folder).
Examples:
- Original documents received from the client
- Vendor documents
- Equipment documents
- Copies of documents from other disciplines
- Emails

1_Working: this is where the current version of the file / set of files must be saved. Only the current version
being worked on will be saved here. For example:

Each current version of drawings in this set is saved here. All other previous versions have been moved into
“Superseded”

Page 4 of 9
Author: Ryan Tufts File Management Rules Version 1 – Approved for Use

You can have many different sets of working items in the same folder. For example:

When using folders to store sets of working items, the “Superseded” folder should be located inside each of
these subfolders. For example:

This way the revision history stays with the drawing sets. The convention for revision control is the
responsibility of each discipline lead. But ONLY keep the current version of the working item(s) in the
1_Working folder.
Refer to the GRDi Project Execution Manuals for procedures on naming drawings and documents.

Page 5 of 9
Author: Ryan Tufts File Management Rules Version 1 – Approved for Use
Checkprints are generated from working items in the discipline folder or come from Drafting. A checkprint is a
snapshot in time of a working item and is particularly relevant at the time of major milestone (IFA, IFH, IFR,
IFC, etc.) but a checkprint should be made before every checking cycle that may produce redlines. A checkprint
itself does not get saved with any markups on it.
You should follow this convention to identify the date and reason for the checkprint:

Checkprints are snapshots in time of a Working Item. Redlines capture changes and are used to convey this
information to others. Working items are updated from Redlines and then a new Checkprint is created. Here is
the general workflow.
From Drafting:
Working (Drafting) -> PDF -> Checkprint -> Working -> Redlines -> update Working (Drafting)
Within Engineering:
Working -> Checkprint -> Redlines -> Update Working

2_Checking: this is where the design cycle of redlines is stored.

Redlines are created from a Checkprint to transmit information about changes or comments on the working item
to another discipline or to Drafting (and sometimes to a third party such as our client). Redlines are an
important record of the decisions that occur in the project. Redlines can also be added to the current working
item and once ready to transmit this information a copy is made and saved in the Redlines folder. Either
convention is acceptable and the preferable method will depend on the particular document and workflow for
that document.

Page 6 of 9
Author: Ryan Tufts File Management Rules Version 1 – Approved for Use
Follow this naming convention to create a folder in which to place the redline set:
yyyy.mm.dd_(Item_Description).

The purpose of this is to help find when and where design changes occurred. It is not required to keep an
electronic record of checkprints and redlines, however it is strongly encouraged to do so because of the benefits
of easily finding and sharing that information with others, even remotely. There will be duplicates of these
documents between the Project folders and the Drafting folders and this is intentional. The Drafting folder has
its own file management procedures and will be addressed separately.
Since redlines can also come either from within GRD or from our client / 3 rd party, you may want to separate
these two sources of redlines to have a clear record of client instructions.

3_Approved: After the design cycle is completed for a particular stage in the project the working item will
be approved for use. This “approved for use” follows our convention for the design cycle (IFA, IFH, IFB, IFP,
IFC, etc.). Interdisciplinary reviews / squad checks are included in the formal revisions.

Once a version has been made obsolete by a subsequent approval stage (i.e. going from IFA to IFH, or IFC) it is
a best practice to move those older versions into an “Obsolete” folder.

Page 7 of 9
Author: Ryan Tufts File Management Rules Version 1 – Approved for Use

Only “Approved” documents may be issued for use by other disciplines, the client, or a third party.
Remember that the “Checking” phase is used for document revisions between Approvals. An approved
document is always required for major milestones (IFA, IFH, IFR, IFC, etc.) and also when issuing information
to be used by another discipline within the project before or between major milestones. This latter type of
internal document should be “approved for information only” and “issued for information”. If a document
doesn’t have a final design state such as “construction” or “demolition” it can just be “approved for use” and
“issued for use”.

_Issued: is an optional folder that can be used to keep track of when “Approved” documents were issued and
to whom. It is saved, as shown below, at the top level in the discipline folders. There are several benefits to
using an “Issued” folder. It may be the case that many different working items are all to be issued at once
(Single line + Panel Drawings + Datasheets). In such a case, it may be preferable to use the “Issued” folder to
clearly identify what was issued (when and to whom), rather than having to look through several “Approved”
folders. Whenever you issue a document it’s a good practice to save that email in the folder too.

Page 8 of 9
Author: Ryan Tufts File Management Rules Version 1 – Approved for Use

9 Rules for File Management

To sum everything up, here are the 8 rules to live by for file management:
1) File regularly (references, redlines, checkprints, emails, and other feedback)
2) Create subfolders in the discipline when they are needed. Avoid empty folders
3) All deliverables are Working Items. Any other document may also be a Working Item if others will rely
upon it.
4) All working items have this structure:
 0_References
 _VOID
 1_Working
 _Superseded
File “ABC123_1”.X

 Checkprints
 yyyy.mm.dd_Description
File “ABC123_1”
File “ABC123_2”
 2_Checking
 From Client
 yyyy.mm.dd_Description
File “ABC123_1”
File “ABC123_2”
 From Checker
 yyyy.mm.dd_Description
File “ABC123_1”
File “ABC123_2”
 To Worker
 yyyy.mm.dd_Description
File “ABC123_1”
File “ABC123_2”

 3_Approved
 yyyy.mm.dd_Description
 _Obsolete
5) Maintain version control of working items
6) Checkprints are a snapshot in time of working items.
7) Keep track of redlines and separate out those from the client, from the checker, and to the worker
8) Only issue “Approved” documents to other disciplines, the client, or a 3rd party.
9) Use the “Issued” folder to transmit documents to other disciplines, the client, or a 3 rd party

Page 9 of 9