On Practice: A Fistful of Notebooks

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.

 

The most up-to-date pieces of technology in the office were the fax machine, with the old-style roll of slippery thermal paper, and the printer/copier, which had no scan or fax function. It was only in 2005 that AutoCAD made it into the office, shortly followed by sending out files to a remote printing service and abandoning the poor stinky ammonia printing machine.

The reason I mention all this (other than #humblebrag) is that there wasn't an overwhelming amount of correspondence and documentation to track. Meeting notes, field notes, site photos (on film!), letters, transmittals, billing documents, the occasional fax; nothing like the landslide of pictures and renderings and submittals and RFIs and product brochures and emails (Lord, the emails!) today.




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

Each tab has a label identifying a meeting or significant phone call - site meetings, design meetings, conference calls, and so on. Inevitably when I need to go back to find something I sketched or a passing remark that didn't make it into the official minutes, I use these tabs to identify where in my notebook to start searching. Absolutely critical when my full project notebook collection can be as many as 50 notebooks. While not as easy to search as a collection of digital files, this stack of notebooks is more satisfying when a project is over and it's time to archive. Just make sure you lift with your knees.

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.