Sunday, December 18, 2011


Preparing class materials for my spring 2012 semester portion of “Codes, Contracts, and Specifications” this weekend, I found myself comparing the old CSI Project Resource Manual to the new Project Delivery Practice Guide.  

In the Project Resource Manual, the product selection process, and by implication the spec writing process, is portrayed in a very neat, orderly, structured, idealized, one-step-follows-the-next, flow-chart-y way.

It would be nice, but a little boring, if the process actually unfolded this way much of the time for me.

Instead, construction document production is usually on such a tight schedule that drawings and specs have to proceed simultaneously, so the spec writing process is anything but a straight line affair. 

In order to edit even some of the simpler spec sections, it’s often necessary to look multiple times at constantly evolving in-progress drawings on the server, ask various members of the project design team lots of detailed questions, wait for answers, and draw inferences when drawings aren’t explicit or when product or design decisions don’t seem to be imminent.  Often it's necessary to go back and delete or add sections when the design takes an unforeseen direction. 

If anything, the trajectory of the process I’ve become accustomed to is less like a flow chart and more like the way a restless canine explores his territory.  

Like my Sheltie, Ollie, in the snow in my back yard this morning.


  1. I always hear Specifiers talking about what they need from Architects. Finally it is like fighting against windmills. Isn't it high time to talk about good practices for Architects to feed Specifers appropriately?

  2. Thanks for your comment, Bruno.

    I sure hope working with me is not like "fighting against windmills".

    In my experience, architects are more than willing to share with me as a specifier what they know about in-progress projects. The problem with hyper-schedule projects is that even the architects may not know some of the answers yet because they're still refining the solution to the owner's program. Or maybe the owner hasn't been able to make some crucial decision, or worse yet, rescinds a previous decision, which triggers redrawing and a rewrite of previously edited spec sections. As an in-house specifier, I have the luxury of easy collaboration with the architects and I relish being part of a team producing the construction documents. My point in the post was that the spec editing process isn't linear or simple for me, or for that matter, for the architects and engineers.

    Your point about "...good practices for Architects to feed Specifiers appropriately": The only good practice you need is to put yourself in the specifier's shoes and ask yourself "What would I need to know to produce specifications for this project?"