The purpose of construction documents is simple: They tell the contractor what is needed to complete a project. How best to do that has been a subject of debate for a long time, even though a basic set of rules has been used at least as far back as the 1940s. In his "The Case For the Streamlined Specification", published in the July 1949 Construction Specifier, Ben John Small referred to a book titled "Specifications" that was written in 1896; the older book apparently discussed some degree of streamlining.

That's fine as far as it goes, but if the intent is to clearly communicate with the contractor, are we doing as well as we could? Architects and specifiers have a nice collection of rules for organizing information, but do they make sense for the contractor? Our rules are fairly consistent, and they are generally accepted by design firms, but can they be improved? A large project many take a year or more to complete, yet we still have inconsistencies and conflicts. Is it fair to expect a bidder, who typically has only a few weeks to figure out what we want, collect subcontract bids (many of which are incomplete or include qualifications), decide how much to include to cover the inevitable problems, and arrive at a competitive price?

Can we do better than asking contractors to find the critical information in a haystack of information that is less important?

Let's start with what works. Streamlining is the practice of removing many of the words we would use in ordinary conversation, but which add nothing to construction documents. A big step toward simplification is achieved by a simple change of mindset; if you understand that specifications and drawings are instructions written to the contractor, rather than a disinterested explanation of what is to happen, the rest will be easier. When teaching certification classes, I tell the class to write as if they are talking directly to the contractor. If you are talking with a contractor you won't say, "The contractor shall fill the bollard with concrete." Instead, you would say, "Fill the bollard with concrete."

As noted, this is a big first step, one that will automatically eliminate the "shall be" phrases that still are far too common. But even more can be done to reduce the length of specifications without losing critical information. While some things may need something approaching a complete sentence, most requirements can be reduced to what amounts to a checklist. Each item begins with a subject, followed by a colon (defined to mean "shall be" or similar term), followed by the relevant property. For example:

Air content: 5 to 8 percent.

Insulation: ASTM C578, Type IV.

If the property is evaluated by a reference standard, insert the standard and qualifying requirements before the colon.

Compressive strength, ASTM C109, 28 days: 7,000 psi.

Note that this checklist approach translates very well to properties found in BIM objects.

It's fairly common practice to eliminate the articles a, an, and the. In most cases, this works well, but I retain the article when referring to the Architect, the Contract, the Contractor, and the Work, to take care of those situations when those terms occur at the beginning of a sentence. Otherwise, there is no way to differentiate between the contractor identified in the agreement (Contractor) and a contractor working on the same building but under a different contract.

Even though streamlining is relatively easy to do, many firms - and even commercial guide specifications - do not use it as much as they can. Another common problem is lack of coordination: specifications that conflict with each other and with drawings, drawing notes that appear to have been written without any understanding of what's in the specifications, and drawing notes that ignore the basics of writing specifications. If that's the best we can do, and it appears that it is, we haven't made much progress in the last hundred years.

Consider these words of wisdom regarding PageFormat, and consider applying them to everything we do:

- excerpts from the CSI Manual of Practice, June 1974

Although specifiers can have an influence on drawings, let's look at how specifications can be changed to improve communication with the contractor. Let me start by saying that there is no excuse for contractors who don't look at the documents; "We don't do it that way" is a non-starter. On the other hand, it's not uncommon to hear "I didn't see it!" as an excuse for non-conforming work. It's easy to point to our rules and principles and say, "Too bad for you!" but in doing so, are we ignoring the problem? There is no doubt that some contractors just do what they're gonna do, but there are many occasions when I can't help but sympathize with a contractor who's trying to do a good job, but doesn't understand the way we do things.

A couple of responses are possible. We can go out of our way to educate contractors, subcontractors, and suppliers about the intricacies of our various formats and standards, but other than saying contractors should join CSI, not much of that happens. And, truth be told, many in the design professions, including our own members, don't follow the very principles we espouse.

Another approach is to reconsider how we do things. At a recent convention, Nashville, perhaps, there were a number of presentations that took this approach. There was healthy discord and disagreement about the proper use of the "Section Includes" article, and about other aspects of writing specifications, as well. Unfortunately, as far as I'm concerned, those discussions did not continue.

Why isn't this concept applied to all construction documents? Until the day that a significant number of contractors are not just CSI members, but CDTs, we can't just sit back and expect the rest of the construction team to understand what we do. If we're interested in progress, if we truly believe in improving communication, shouldn't we consider changing what we do for the benefit of the rest of the team?

This will be a bit off-subject, but bear with me. How many of you use what appears to be a standard format for meeting agendas and minutes? You know, the one with a lot of blank space at the top for the date and subject, followed by a list of those invited or those who attended, which can run to two or more pages, followed, finally, but the information you're really interested in?

If you think about it, that's a dumb way to organize agendas and minutes. The day after the meeting, will you really care who was there or who wasn't? Especially if the agenda or minutes were sent out under a transmittal form, which duplicates the same information?

Why do we write specifications in the same manner? Instead of starting with the important stuff - what's in the section - we ramble on for a page or so, talking about procedural items, then sandwich the good stuff between that and the how-to information. I know, the "Section Includes" article usually has a generic comment or description, but is that what a contractor is looking for? In most cases, the title of the section tells the contractor about as much as the "Section Includes" article.

What if we rearranged things to make it easier for contractors? Keep "Section Includes", but state what's in the section, including basis of design products; then go on to talk about performance standards, options, and the other stuff that directly affects the contractor, subcontractor, and installer. Follow that with special instructions regarding installation (shouldn't be much unless you know more than the manufacturer), then end with an appendix of information about submittals and other procedural matters. If it's easier for contractors, it should be easier for architects and specifiers.

Agree? Disagree? Leave your comments at http://swconstructivethoughts.blogspot.com/