So you've got your project notebooks and your pens and your sticky flags. You're ready to keep your own notes organized - first milestone on the Data Mountain path cleared. Now let's look at how to manage the project files.
I had the very good fortune to work under an extremely organized project architect when I started working full time after graduating architecture school. I still use his methodology (with some minor tweaks and customizing) to keep project files in order, but each office will be a little (or sometimes a lot) different. He was the senior associate, so he oversaw most of the projects in the office and was in a position to make sure his standards were enforced - not always the case!
Where do you start if you're the one setting the standards?
One strategy is to look to other sources. The AIA has some excellent resources, including project file organization. Here's an outline of a file directory you can find online: Project File Organization, AIA Best Practices (This is a major reason I'm a member of the AIA - the resources are invaluable for practice.) The Architect's Handbook of Professional Practice goes into greater detail on data management, and you can check out this book at your local library, although I recommend owning a copy.
 |
| The Architect's Handbook of Professional Practice - 15th Edition |
The overall structure for any architecture project is generally going to follow the phases of construction, from the initial programming to final punchlists. Some items, like email and working drawings, will need continuous management throughout the project. Some items, like site surveys and punchlist, will only occur at a specific phase and then become record documents. Some items fit neatly into the CSI MasterFormat Division list, like specification information or submittals. Some items don't, like correspondence. Whatever the approach, the basic rules stay the same:
Consistency is key - knowing where to file information means knowing where to retrieve information.
If your project file directory varies widely from project to project, depending on who has been working on it, it's not consistent enough. Set and enforce the office standards and make sure each employee knows how to make use of them. Often that variation is a symptom of vague categories or lack of time allowed for project management.
Files should not be like a box of chocolates - you should always know what you're going to get.
Related to consistency is naming conventions. I once had to take over a project from a designer who named all of his files "Project Name 1" or "Aerial View 6" or "North_No Trees"- what a headache. If someone in your office who has not worked on your project has to open every single file in that project directory to figure out what the heck it is, your naming convention is not working or not being used. A name should indicate what it is, when it was generated (or issued, or revised, or what have you), and who else is involved. 1441_MeetingMinutes_GC_150328 is very clear: 1441 is the in-house job number, MeetingMinutes is self-evident, GC is for General Contractor, and 150328 is the date when the meeting took place. You'll most likely accumulate a whole series of 1441_MeetingMinutes_GC files, and keeping the name consistent makes it easy to search for the one you need later on.
Duplication is a mistake - it's inefficient and means it's not clear where the information belongs and where you can expect to find it.
Duplication is another symptom of vague categories, and will drive you crazy trying to figure out the difference between files. This will also lead to problems when you accidentally choose the outdated "twin" to issue or reference. Your project file will also grow alarmingly bloated, and you won't easily be able to determine which files can be purged and which need to be kept. If you find yourself often having to choose between ill-fitting categories, maybe you need something less specific or better tailored to the kind of information you're filing.
Don't reinvent the wheel (unless the wheel isn't working).
If you find yourself trying to come up with naming conventions and continually revising them, look to outside resources to see if someone else has already solved the problem you're having. Again, the AIA is a great resource for tools to manage architectural projects. I mentioned the CSI MasterFormat Divisions above - this is also a powerful tool for organization if you can apply it to your file management. You can use it for organizing your submittals, your product information, your specifications, even your field reports.
For example: Field Reports. I inherited a clunky and inefficient format for taking field notes at my first full-time job. I took notes in a Steno pad and then transcribed everything significant into an outline sorted by topic. It was slow and ate up a lot of my time trying to put information from site visits into an issued document. It was also wildly inconsistent from site visit to site visit - I couldn't remember what topics we had discussed in months past so the names varied enough to make it a tedious chore to search for information later on. After years of this, I finally had the brainwave to make a 3-ring binder organized by divisions - each time a site meeting covered metals, for example, I'd flip to the Division 5 tab and take my notes. When we switched topics to wood flooring, I'd flip to Division 6. If we returned to metals, I'd flip back to Division 5 and pick up where we left off. Once the meeting was done, I could easily write out the notes in an outline based on division because it was all together and ready to go - I didn't have to flip back and forth through my Steno pad 80 times to finish one topic. The topic naming remains consistent, so I could easily go back and look through all the issued documents that talked about the metal stair, because all of those documents would have a Division 5 heading. Once I was done with the meeting notes, I took the loose leaf paper out, stapled it to the issued minutes, and filed it. The binder was then ready to go to the next site meeting.
Another example: Revit naming conventions. Revit has its standard pre-loaded families organized into folders named by category: Doors, Plumbing Fixtures, Annotation, etc. It also has a system of customizable keynotes that can be loaded in by the user as a text file. The keynotes can be a great way of standardizing annotation in a Revit file, but like anything else, they're only as good as the organization system. If you plan to use a lot of material notation, you can use the Revit standard material keynote or you could set a custom list for keynotes organized by division. If you plan to use more general notes, you could organize by the sheet number where the note would appear - plans, sections, elevations, details, etc. Creating a running list as you think of each annotative note is going to get old fast - you won't remember when you added the "Rafter tail extension at 24" O.C., for paint" to the list and you'll have to read through everything else to find it.
Be flexible and easy. (innuendo not included)
Your system, whatever it ends up being, should be flexible enough to accept unanticipated information. And it should be clear enough to make it obvious where files ought to go and can be found. In essence, your filing system needs to be easy enough to use that when you need to look up that site photo of the soil stack condition at the beam penetration or which wall treatment was approved in the kitchen or who the contact was for the art mosaic restoration specialist, you can actually find where you recorded it. And not just you - anyone in your office.
No comments:
Post a Comment