David Stutzman
Just who are specifications written for? The Architect? The Owner? Neither! In order of importance, I profess that specifications are written for the benefit of:
- The Contractor's Estimator,
- the Contractor's Field Superintendent, and
- the Architect's Construction Administrator.
The architect spends months creating the contract documents, including the specifications. The estimator must comprehend the drawings and specifications, assign work to each subcontractor, solicit pricing, and assemble the construction estimate in a matter of weeks - hoping nothing is forgotten and no duplication exists - to be selected as the lowest responsible bidder. The field superintendent orchestrates the daily activities to construct the design. And, finally, the construction administrator monitors the process to ensure the construction complies with the contract requirements.
What Can the Design Team Do to Help?
The most helpful thing the design team can do is to produce a set of clear, complete, concise, and correct documents - the CSI 4Cs mantra. Perfection is the goal, but will never be achieved. Time and budget will see to that.
As one of my Miami University architecture professors, Hal Barcus put it, "Architecture is never done. You just run out of time, patience, or money." I never knew if there is any significance to the order of these. Although, I can believe that money is the first to disappear from having spent too much time designing, leaving not enough for documentation. Patience is next - mainly because of budget and administrative pressures. And time is last, as the team scrambles to meet each issue deadline.
Despite Professor Barcus's somewhat pessimistic outlook, there is hope for approaching that perfect set of documents - at least the part I help control: the specifications.
Writing Specifications is a Process
Writing the specifications is the easiest part of a Specifier's job. Collecting the right information, at the right time, from the right source is where a Specifier's skill and some luck are required. Oh that I should be blessed with the ability of Mr. Spock's Vulcan mind meld. Then data extraction from the design team would be greatly simplified. But barring a scientific breakthrough in the near future, I will settle for other means.
Collecting data begins when Specifiers review whatever documents are available - drawings, basis of design narratives, project programs, owner's project requirements. All design projects will have drawings. Many will have little more. So the search begins. Specifiers review the drawings, noting what is found and inferring what will be required even when not found. Experience with the building type, the architect, and even the individuals on the design team help Specifiers complete their notes. The notes will show the major materials, products, systems, and assemblies that will eventually create the design.
The collected data is communicated to the design team for confirmation. The Specifier generates a table of contents, listing all the specification section numbers and titles that will be required. The Specifier's notes about the project requirements will be inserted in the contents. Now the design team can review the Specifier's findings to confirm the project scope is understood. When content is missed, it signals the design team that the documents must be modified to convey the intent more clearly.
Next, the Specifier collects the basis of design product data and the specifics for the project. Nearly every product is available with options - colors, finishes, sizes, and configurations. It is not sufficient for the design team to simply select a manufacturer and a product without identifying the options that will be required.
As I prepare to begin a new interior renovation project to convert an existing office building into a charter high school for the performing arts and sciences, I assembled a set of 113 MasterSpec architectural and MEP specification sections needed for the project. Within that set of files, there are 13,425 editing choices (text surrounded by brackets) about the materials, products, and options that must be made.
The writing begins and unresolved questions remain. So what does a Specifier do? Are the sections written only to the extent information is known? How are the remaining questions resolved?
The Act of Communicating
To complete the specifications efficiently, Specifiers make choices, including choices for information that may not be known, yet. Each of these choices made without complete information is flagged as an unresolved issue. We add a variety of project notes to the specifications. The notes contain comments and questions addressed specifically to the Architect, the Owner, or the Engineer, informing the team about who is expected to respond. Or they may be written as coordination instructions for ourselves, depending on answers the design team provides. Some notes may contain a record of the specification writing progress. +
The project notes inform the design team what we did, explain what the alternatives may be, and ask for their confirmation. From experience, we know that we will make the right selection for the project about 90% of the time. Then we only need to delete the project note - an automated task for us - to complete our work.
Compensating for Appearance's Sake
Some Architects are hesitant about publishing a draft specification full of project notes. They make the specifications look incomplete. Imagine a draft specification that is not complete - just like the progress drawings are not complete. Usually Architects ask us to remove the project notes before the draft specifications are published. We prefer to share the notes with the entire team to tap the collective knowledge of the entire team to resolve each item. However, we comply but choose to hide the project notes rather than deleting them. These notes are our quality control tool to help strive for perfection.
So the project notes are not forgotten, we automatically compile the notes from
every project specification file. We create a list for the design team's reference and response. We can selectively compile the project notes by type and by their status as hidden text. The advantage is that all the notes are collected in one location. The disadvantage is the compiled notes are removed from their context. But better to have a record of the notes to share with the team, than to ignore the unresolved issues they identify.
Fortunately we have a powerful tool (the running guy) that allows us to run custom macros on an entire list of files from a single command. This tool allows us to complete the note compilation and many other repetitive tasks efficiently and accurately, essentially with the press of a button. Using technology where possible, allows Specifiers to concentrate on information gathering, writing and other tasks requiring skills and experience that machines cannot duplicate.
And the final result - a collection of all the unresolved issues in each specification section in one convenient location. Sample Compiled Notes Page.pdf
Building a Communications Knowledge Bank
All these project notes need not be created for every project. Some can be included in office master guide specifications. The notes in the master guides can serve as an initial checklist for assembling specifications data. If answered before the specifications are written, many of these questions and comments can be addressed when writing the first draft.
We rely heavily on notes in our master specifications files. The notes include very specific editing instructions and guidance for making editing choices. These notes allow us to make the right decision most of the time, even in the absence of direction from the design team. These notes capture individual experience and knowledge gained from completing every project that is shared with the entire staff.
The knowledge that can be collected in the office master guide specifications is invaluable. The specifications and the notes become an effective tool for teaching younger staff and new employees about how the company approaches their designs. Regularly updating the specifications to reflect the current state of the industry and the most recent project experience moves the documents ever closer to perfection.
Maybe, just maybe, that next project will be nearly perfect!