Where do bad specifications come from?

It's approaching ten years since I wrote "The Making of a Curmudgeon." In it, I reminisced about my decision to run for Institute Director and thinking, "Holy cow, when my term is done I'll be almost sixty!" Well, sixty came and went, and I recently celebrated my twentieth anniversary at my office.

Milestones like that tend to make one look back, to think about what has happened, to think about what might have been. During my thirty years as a specifier, I thought things would improve, that specifications would get better, that relations within the construction team would become more collaborative and trusting, that drawing details would gradually lose the pesky problems that lead to problems in construction, and that, eventually, the construction process would be a thing of wonder, with few difficulties. I thought that when it came time to retire, I could look back on continual progress and leave knowing that the world was a better place, due at least in some part to what I had done.

Unfortunately, I see now that little progress has been made. I see the same bad details, the lack of understanding of material properties, and specifications that show no understanding or, or confidence in, the basic tenets of writing specifications. One of the reasons is that there is always an influx of new people, who need to learn the trade. However, I find that an unsatisfactory answer; even the most recent graduates should know more than they do.

I often have blamed architecture schools for many of these problems, and I will continue to do so. I cannot understand why a professional school spends so little time teaching the things that require architects to be licensed, and puts so much emphasis on what amounts to art. But that's another matter for another time.

Perhaps the most disappointing thing to me is the nearly universal use of specifications that ignore CSI's Manual of Practice (later the PRM and Practice Guides). If this were the result of specifiers writing their own specifications it would be less surprising, but it's not. The problem arises from the widespread use of commercial master specifications that often miss the mark set by CSI.

When I was drafted into the Army, my only experience shooting a rifle was at Boy Scout summer camp, where we each shot ten or so rounds at a target. Even though I grew up in Minnesota, I wasn't a hunter. That lack of experience meant I had no bad habits to break, so I learned how to shoot the right way (or at least the Army way). I was one of only four who qualified as expert marksman in my entire company.

My experience with specifications was similar. Before taking my first job as a specifier, my experience was limited to copying specifications onto a drawing. Again, I had no bad habits to break, and I devoured CSI's MOP, learning how to write specifications the right way!

The office I worked in had office masters, which were, I believe, based on SpecText because of their brevity. As I gained experience, I began to question them, and I started rewriting them to follow the principles found in the MOP.

Later, I began writing articles for newsletters. The topics covered a wide range of subjects, but several times I wrote about how specifications could be improved simply by following the MOP. Not only did I write about it, but I made many presentations that highlighted the ways specifications could be improved by removing unneeded text. I thought I was doing some good, but I had no more success than Ben John Small, who had written about streamlined specifications in 1949.

In future articles, we'll look in detail at where specifications are needlessly complex and bloated. Some will argue, "If the reader understands them, does it matter?" Following that logic, it should be ok to include an encyclopedia in the project manual. It might have useful information that might be necessary, but it discourages readers from reading everything.

Do you have examples of unnecessary text in specifications? If so, please add your comment below.