It worked last time! The perils of recycling specifications

Clovis' Taufe, by Meister des Heiligen Ägidius
[Public domain], via Wikimedia Commons

For many years, I was one of the instructors for my CSI chapter's certification classes. In addition to explaining what CSI's practice manuals say, I liked to include horror stories - real-world examples of the ways people found to really mess up a project. One of my favorite stories came from a public sector waste treatment agency. The project was a relatively simple addition to an existing building at one of the waste treatment facilities, to provide shower and locker rooms for the employees.

The agency had hired an architecture/engineering firm to design the addition, and to prepare bidding documents. As the bid opening date approached, the owner began getting calls from mechanical subcontractors, who asked, "Did you want to use fresh water or effluent to serve the baptismal font?"

Apparently, the mechanical engineer had reused specifications from another project, which happened to be a church. Obviously, assuming the specifications had been submitted for review, there should have been opportunities to discover and correct the error, but had the engineer started with master specifications, the baptismal font almost certainly would not have appeared in the specifications for this project.

This is an amusing result of the time-honored way of writing specifications: take the specs from the last project, change the client's name, and - voila! - they're done. While this may be a quick way to produce specifications, it also is a way to virtually guarantee those specifications will be incorrect.

There are times when this quick-fix approach almost works; certainly, in a project with multiple bid packs, there will be a great consistency and repetition from one bid pack to the next. An obvious example is waterproofing, which will probably be included in the foundations bid pack, though it could appear in later bid packs. Either way, it will probably appear only once. Given the nature of the product, it will be easy to either add or delete it as the project moves forward. 

Other materials are more complicated. Cast-in-place concrete, for example, could all appear in one bid pack, but it's just as likely to appear in the footings or footings/foundations bid pack, in the shell bid pack, and in the fit-out bid pack. If it's all specified at one time, it will be easy to remember to take the section out when it's not needed, but what if it appears in more than one bid pack? Ideally, each time a section is used, it will be edited down to address only what is needed for each bid pack. My experience has been that the design team often has trouble deciding which concrete is used in each bid pack, so there is a tendency to use essentially the same specifications each time, and let the contractor figure out which parts of it apply. The same can be said about masonry, insulation, hardware, and other products that may be required at different times.

Reusing old specifications also is tempting when designing additions to existing buildings, or doing more work for a regular client, but even then, there will be differences.

The older the reused specifications are, the greater the certainty that they will be incorrect. Codes change, reference standards change, companies go out of business, products are discontinued or changed, and owner preferences change. A design firm's practices also change; most firms are more green than they were even a few years ago, and specify different products. Most people seem to think specifications are boilerplate. In fact, they are living documents, which must be updated continually to incorporate all of these changes.

Traditional specification editing is a subtractive process. The specifier starts with a master specification, which contains many options. In most cases, offices pre-edit master specifications so to minimize editing for the types of work they do most often. These master specifications are further edited for each project by removing unnecessary information, and, frequently, adding in missing information.

The problem with reusing specifications is, to accurately fit the needs of another project, the specifier must remember to add things that had been deleted, and to remove things that no longer are needed. Both require thought, but it's far easier to delete things that aren't needed than to remember what's missing.

Without exception, every time I have to reuse specifications from another project, even from an earlier bid pack for the same project, we discover late in the construction documents phase that we don't need something that was in the reused specs, or that something we do need wasn't there. Unfortunately, these things sometimes are not discovered until the bidding documents have been issued, or until construction is underway.

When reusing specifications, they must be compared to the masters, to identify things that are have been deleted, or that may have changed as the masters evolved. And, they must be reviewed item by item with the team to make sure what's in them corresponds with requirements for the current project. I haven't kept track of how long it takes to review and update a reused specification, but it seems it would be just as easy and fast to start with unedited masters. Of course, the reason we're using old specs is that we don't have time to start over, so the review and re-editing is either ignored or superficial.

Isn't it amazing how often we can't find time to get the documents right before they're issued, but we somehow find time to fix them later?