I started working in an architecture firm in 2003.It was a tiny residential firm; just the principal, one employee, and one intern (me). Because it was so very small, this office was still using some fairly antiquated technology, including parallel rules, a typewriter, Letraset, and an ammonia printing machine with that UV-light-sensitive paper (!!).
|Parallel Rule - check out those drafting dots!|
|Letraset - the coolest and most tedious lettering method imaginable.|
In most ways the digital overhaul of the architectural office has made practice much better. Drawings (particularly in BIM software) can be updated and modified and re-issued almost instantaneously, renderings can be made to look nearly life-like, coordination with consultants and contractors is much more streamlined across the country and around the world.
The downside is the avalanche of data that must be managed.
Drawing sets have become hundreds of pages long. Meeting minutes and field reports seem to multiply into the thousands. Digital pictures mean that one project can easily have ten thousand photographs. Emails can easily accumulate into the hundreds of thousands. How do you manage these files so you can make use of this mountain of data effectively?
My introduction to architectural practice being synonymous with my introduction to antiquated technology, which was only reinforced with my architectural education, my own style of documentation tends to be somewhat of a mix of old and new. I will pivot table the living daylights out of a spreadsheet to provide snapshots of a millwork log, but I will also write all of my notes into a physical paper notebook. Not just meetings, either - this is the paper version of my brain for any given project - phone calls, meetings, sketches, everything. This means I have a LOT of notebooks.
|9 Months of Note-Taking for One Project|
This is just 9 months of notebooks so far on a project that was well into construction when I started work on it. Each one has the project name and ID number, the start and end dates of that notebook's use, my name, and an overall sequential number for collecting them all together. And you'll notice that there is a whole flock of tabs on those notebooks. Here's the current notebook with its tabs:
|Notebook with Tabs|
Standardizing the project directory and how it's used on a server is critical. Without careful and regular maintenance, a project file can quickly devolve into a rabbit warren of poorly chosen names, duplicates, and empty folders that make it impossible to find anything. Something I've found myself repeating (most likely ad nauseum) when supervising intern architects is this:
Documentation is great, but it's only the first step. And if you can't find the data, you might as well not have recorded it at all.
And if you happen to be unlucky enough to take over a project from someone who was documenting it in an idiosyncratic way, (and even worse, no longer at the firm!) it can be a nightmare to make sense of and unsnarl. So how do you set a precedent that is easy to follow for your colleagues now and into the future? We'll take a look at that in the next entry in this "On Practice" series.