Skip to the main content.

Owner Approach

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.

Services 

Owner Approach | Conspectus

 

Contact Us

    Architect Approach

    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.

    Services 

    Architects | Conspectus Inc

     

    Contact Us

      Design-Builder Approach

      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.

      Services 

      Design-Builders | Conspectus Inc

       

      Contact Us

        Construction Manager Approach

        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.

        Services 

        Construction Managers | Conspectus Inc

         

        Contact Us

          3 min read

          Magical Thinking in Specifications - Part 2

          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.

          Case Study

          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.

          Lessons Learned

          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.