Elias Saltz
Specifiers often struggle to come up with ways to make specifying simpler, to eliminate unwanted language, and to make specifications more correct. At this year's CONSTRUCT AEC Education and Expo, Beth Stroshane posited that the way we write specifications is analogous to wandering around in a giant antique mall, searching for stuff that's relevant. That analogy is apt, and this article will use it abundantly. Specification masters, both the commercial and custom varieties, become filled with the flotsam of products and projects past. We add paragraphs to prevent repeating problems that occurred on a project, but in a few years will anyone remember exactly why we did it? Probably not. Keeping the specs dust-free and updated is an ongoing task that is difficult partially because maintaining masters is not billable work. We're all busy writing new projects, so we're usually stuck working with what we have.
Even so, there are some things we can do to streamline the specification writing process. Some of these are common ideas, some perhaps less so.
A commonsense strategy that is already standard practice for most firms: plan in advance for the specifications' level of detail to align with the project scope. If it's a small interior renovation project or a simple building with very common construction materials and methods, short-form or even sheet specs are almost certainly sufficient. But if short form / sheet specs are just cut-down versions of full-length specs, is that the best way to write them? Does that still require a trip to the antique mall?
Another strategy is to only produce as many iterations as make sense for the project scope. For small, or simple projects, consider whether design development specifications actually add anything useful. In most cases, specs won't be needed before the end of construction documents, so why produce them earlier?
For larger projects, many of the same principles apply when specifying earlier design phases. Frequently, large projects require specifications at the end of schematic design and design development. So what's the best way to produce those? A common approach is to write a narrative project description at SD, deliver it, then set it aside and produce full-length specification for DD. The SD narrative might make sense on its face because the information density is roughly equivalent to the drawings. But there are no industry standards or checklists for design narratives, and the information can be difficult to validate. A full-length spec at DD does not make sense at all. That's like specifying the entire antique mall, hoping that someone will both find something useful and know it's useful when they see it. The drawings are incomplete, missing notes, lacking details, etc., so how can the specs pretend to be complete?
Drawings are built from blank pages, and details and material notes are added over time as the project comes into focus. Most full-length specifications are built from massive, dusty antique-filled masters. Information is deleted over time as the project comes into focus. It's rather a miracle that these two disparate approaches ever result in cohesive documents, not least because of the time interval between when DD and CD specs are produced, myriad changes might be made and the specifier needs to re-familiarize himself or herself with the drawings and the entire antique shop.
A smarter approach is to align the entire spec writing process, particularly the SD and DD specifications, to the drawing development. This way, rather than deleting anything, information is written on blank pages, and details are added to the specification documents as the project comes into focus. This might sound like a daunting task, but it isn't. Drawings aren't really made on blank pages anymore, that's just an analogy. Instead, they're constructed on a framework: Design and BIM software and their built-in tools and assemblies. Early-phase specifications are also constructed on a framework: industry-standard formats, templates, and common language. It's possible to build MasterFormat® specs ground up starting from a SectionFormat template, only adding information a little at a time, but that is neither particularly simple nor likely to be aligned with the drawings. Instead, project descriptions, built on Uniformat* (perhaps using PPDFormat™) is preferred. Uniformat is a standard designed to describe collections of systems and assemblies rather than individual components as in MasterFormat® outline and construction specifications. Uniformat serves as a checklist to ensure all elements are included, and systems and assemblies descriptions enable ready cost estimating, aid in decision making, and present complex information so that it's understandable by the entire team.
Building specs from a blank-page Uniformat framework allows specifiers to deliberately write in what a project contains right from the start, rather than meandering through mountains of dusty masters figuring out what doesn't belong. This can result in cleaner, more correct specs that are better aligned with projects, both in the process and in the results.
*“UniFormat™ is a publication of the Construction Specifications Institute (CSI) and Construction Specifications Canada (CSC). A competing document is published as ASTM E1557-09 (2015) Standard Classification for Building Elements and Related Sitework - UNIFORMAT II. Both standards function roughly equally; this article is not recommending one over the other and simply uses "Uniformat" to refer to either classification system.”