Focused on owner’s requirements, Conspectus offers an accurate, transparent view of how decisions made during the design process will ultimately impact project cost, construction quality, and building operations.
Focused on architect's requirements, Conspectus offers an accurate, transparent view of how decisions made during the design process will ultimately impact project cost, construction quality, and building operations.
Focused on design-builder's requirements, Conspectus offers an accurate, transparent view of how decisions made during the design process will ultimately impact project cost, construction quality, and building operations.
Focused on construction manager's requirements, Conspectus offers an accurate, transparent view of how decisions made during the design process will ultimately impact project cost, construction quality, and building operations.
In my recent post, When Specifiers Engage in Magical Thinking, I described what happens when a specifier believes that putting more instructions into a specification will make for a better outcome. Never mind whether or not those instructions were appropriate or even made sense. It turns out that dismantling an abysmally-written specification, while useful and informative (and entertaining), is easy. Too easy, even. Getting inappropriate language removed from specifications is low-hanging fruit because it’s right there and we can see it and react to it. We can explain why it’s wrong, predict what the results will be, and then see what happens.
Far more difficult, and a more pervasive problem, is identifying what is not stated in the specifications, but should be. Some specifiers believe that whatever they say in a specification will magically make everything come out the way they want, but it’s far more common for specifiers to believe that there will always be something somewhere in the specifications will magically cover them for errors in the drawings and omissions in the specs. Maybe they believe that a reference standard includes sufficient information, or that contractors will know the code well enough to keep them out of trouble.
When I teach my CSI chapter's CDT class every year, I include an example of a failure from my own history as a specifier, one that serves as a reminder to try to query every paragraph and think about what needs to be added.
In this example, from an eight-story hotel project, a detail indicates a floor-ceiling fire rating that is ubiquitous throughout the project. The assembly’s UL design number is helpfully called out on the detail:
The UL design refers to a required insulation layer, and labels the layer “batts and blankets.” The drawing says “mineral wool insulation” but not what type.
The specification is mostly mute about what the batts and blankets product is meant to be. The closest thing is a reference to acoustical fire batts in the drywall section, meant for partitions.
The UL design, for its part, shows the insulation like this:
So far, the UL design and the drawing seem in alignment, and the specifications’ omission of an actual product appears to be a non-issue. The contractor submitted a mineral wool blanket product for this assembly, Thermafiber SAFB.
During review of the submittal, the project architect double-checked the UL assembly and noticed something. He came to my desk with a question (I was an in-house specifier at the time so impromptu questions were very common). The UL design had named a different product.
Isolatek CB is not a “batts and blankets” product. It’s a rigid high-density mineral wool board and, as Murphy would have predicted, is more expensive than the submitted product. I don't recall how much more, but given there were tens of thousands of square feet of product, the gap was substantial.
The architect’s question: “Is there something in the spec that we can use to compel the contractor to use the correct product without incurring a change order?”
The answer we found after reading the specs, unfortunately, was “sort of, but not really.” The specifications included an instruction that fire rated assemblies be constructed using products required by UL designs. But the repetition of incorrect and vague information from the drawings to the specs ("mineral wool blankets") gave the contractor information he believed he could rely upon to buy out the project. The architect and owner chose to try to enforce the “fire rated assemblies” provision, which led to a lengthy dispute.
Being wrong is a humbling experience. Acknowledging your mistakes is hard, and changing your approach is harder.
Specifications will have omissions. That’s inevitable, no matter how diligent a specifier is. Part of the problem is the ‘text deletion’ model of commercial guide specifications: it’s far easier to delete something that you see and decide isn’t needed, than to add something that’s missing. Adding relevant information gleaned from discussions with the design team and spotted on the drawings and extracted from reference standards or UL designs takes practice and experience.
There’s an element of magical thinking in not specifying enough - a reliance on the belief that somewhere in that huge stack of paper is a sentence that will help me. The way to avoid this is to just do the work of deeply understanding the project requirements, and including the information necessary to achieve them, end neither less nor more than that.