The main reason we've been doing things the same way for the past hundred fifty years, is - that we've been doing things the same way for the past hundred fifty years. It's human nature to keep what's comfortable, even though it may no longer work, or even if something better is available. I'm fairly certain the original versions of the contract documents we use, and the way we write them, made perfect sense when introduced, but is that still true?
Along the way, there have been many changes in building products, construction techniques, communication, and other technologies used in construction, perhaps the most significant being the expanding use of computers. If we were starting over today, with the current status of products,
industry and government standards, and the increasing application of
powerful computers, what would our construction documents look like?
There would be some similarities, but I suspect they would not be what
we have today.
Today, much more work is fabricated off site, in controlled factory conditions, making today's materials and products far more reliable and consistent than they were a century ago. We often hear about the great quality of bygone days, and there is some truth to that, but the reality is that today's products are generally superior.
Project delivery methods also have changed. Design-build, historically the most important method, was set aside, at least in the US, in favor of the design-bid-build method. The value of design-build is again being recognized, and it, along with CM, have been taking increasing numbers of projects from what we consider the "traditional" arrangement with owner, designer, and constructor as three separate entities.
The resistance to change is understandable, but it can stand in the way of progress. For example, the advantages of a metric system of measurement have been known for a long time, yet we refuse to implement it. Thomas Jefferson proposed a metric system as a US standard a few years before the current metric system was developed, but it was rejected. Later attempts at metrication were somewhat successful, but we refuse to put it to everyday use. A more recent example is the proliferation of online magazines, which are analogue versions of the printed magazine we get in the mail. Typical website navigation tools could be used, but instead, we look at an image of a paper magazine, complete with pages that turn.
The documents and formats we now use similarly are tied to historical ways of presenting information - on paper. Before the advent of computers, we had no choice but to print everything, as that was the only way to record, convey, and confirm the information needed for construction. CSI's contributions - MasterFormat, SectionFormat, and PageFormat - brought order to that information, and made it easier to communicate. CSI's Manual of Practice (MOP) offered uniformity for the way specifications were prepared, and the way ideas were stated.
All of these things suggest specifications should be shorter. However, specifications are longer than ever, and seem to grow with each new version. One of the main reasons is redundancy.
Despite all that is offered by commonly used general conditions, CSI's Formats, and the multitude of standards, specifiers appear to be weak in faith. A casual review of published project manuals shows a surprising disregard for those standards. Complex sentences, redundancies, vague terms, inconsistencies, and conflicts within the project manual, and between the project manual and drawings, are common. Why is this?
There are two reasons for not following the standards we espouse; good intentions and laziness. I'm optimistic in believing most of the problems we see come from an honest effort to make sure the job gets done correctly. Drawings often contain unnecessary references or explanation simply because the person working on the drawings isn't sure if the required information is stated somewhere else, and so enters it wherever it seems appropriate. Similarly, specifications often contain information that is on the drawings, but the specifier isn't sure. Example: The number of trees is commonly shown on the drawings as images that can be counted, again in a schedule on the drawings, and once more in the specifications. Example: Elevator specifications commonly specify the number of floors, the number of stops, the locations of doors, the type of door operation, and the travel distance - all of which can be ascertained from the drawings.
A hundred fifty years ago, when the architect actually approached the status of Master Builder, the architect was in control of the project, and was expected to tell the contractor what to do. That would seem to require lengthy specifications, yet those printed then were much shorter than they are today.
Since that time, a number of things have happened, which, if anything, should make specifications shorter. We now have countless industry and government standards that dictate minimum requirements for nearly everything. Proper use of those standards should eliminate many of the redundancies we find in today's specifications.
Time to do some housecleaning
First, read what the general conditions say about the responsibilities of the architect and of the contractor. In essence, the architect is responsible for showing the final result - what the building should look like, and what materials should be used where - and the contractor is responsible for pretty much everything else. Note there is nothing that requires the architect to tell the contractor, or manufacturer, or installer how to do their jobs. In fact, it states "The contractor shall be solely responsible for and have control over construction means, methods, techniques, sequences, and procedures and for coordinating all portions of the Work…"
This makes sense; the contractor knows more about how to run a job, the manufacturers know more about their products, and the installers know more about their work than the architect can possibly understand for all the thousands of components of a building. So why do specifications delve so deeply into these matters? Why do they tell the contractor how to schedule, how to install, and how to coordinate?
Now, add the recommended paragraph to the supplementary conditions, to formally make Division 01 apply to everything else: "Sections of Division 01 - General Requirements govern the work of all sections of the specifications." Make sure your Division 01 sections include those aspects of construction common to all sections. State requirements for selection of materials, for storage, for resolution of discrepancies between applicable standards, for installation, for following the manufacturer's instructions, and so on.
With that beginning, we're well on the way to reducing the length of specifications. It requires faith, but it is logical, defensible, and enforceable. The basic rule is, if it's in the conditions or Division 01, take it out of the section. It is quite common to find a requirement that materials be stored off the ground and protected from weather in Division 01, and then again in most other sections. Similarly, requirements to comply with manufacturers' instructions are scattered throughout many project manuals. Now remove all references to Division 01 from the specifications; we took care of that in the supplementary conditions.
Part 1: Use "related work" as intended, a way to help the reader find something that normally would be expected in this section but is not. If used otherwise, to mention all sections that are somehow related to the work of the section you're in, logic suggests you would have to list every other section.
Part 2: If you have specific products in mind, state what they are. If you're open to competitive products, specify the performance. Don't specify things that are not essential, or may not be the same for all products.
Part 3: Unless you know more about installation than the manufacturer and the installer, there isn't much to say. But do specify field quality control measures to ensure you're getting what is specified.
Know your reference standards. If you specify insulation as ASTM C578, Type IV, there is no need to go on and specify the thermal resistance, compressive strength, water absorption, or vapor permeance. On the other hand, if the standard you are using has options, be sure to indicate which are required.
When you specify more than necessary, you enter into the "means and methods" area, and, in so doing, you assume the contractor's responsibility. If something goes wrong, the contractor can say, "I did what I was told" and you're on the hook.
With faith in the documents, it should be possible to specify almost anything in half a page (at least for architectural products, though I suspect mechanical and electrical specifications also can be reduced).
Using roofing as an example, if you state the wind loads, the required fire-resistive rating, the type of membrane, applicable standards, required options, warranty, and field quality control requirements, what else do you have to say? The manufacturer's instructions cover all the related materials, and how it gets installed. You will have to include exceptions; if the manufacturer's standard flashing height is four inches, but you want eight, that must be specified. But think how much easier it will be to find that exception, compared to digging through eight pages of specifications, most of which are common to almost every project.
The result? Easy to write, easy to bid, easy to enforce.
Links to other articles in this series:
What happened to the master builder?
What is a Master Builder?
What have architects given up?
What happened to the architect?
How have the architect's responsibilities changed?
What lies ahead for architects?
© 2012, Sheldon Wolfe, RA, FCSI, CCS, CCCA, CSC
I must say, this is bold, honest, and a must read for anyone who writes specifications. In my opinion this is invaluable insight and an excellent approach to writing specifications. For once someone actually takes to heart what we are always preached: "Say it once, do not repeat." In this regard, the phrasing of being weak in faith is absolutely appropriate.
ReplyDeleteYou mention two reasons for not following our standards, and your optimistic view. Allow me to provide the pessimistic view: I am utterly amazed, in general (not just specs), on the lack and disregard for standards and procedures, of rigor, in Architecture. There seems to be a general lack of accountability: if standards are even created in the first place, then they are rarely enforced, to the degree that I would take pride in calling myself a professional, hired by an Owner to do a job.
Here Sheldon is trying to get back to a rigor that one can and should hang their hat on - kudos. It's knowing what you're doing, why you're doing it, and striving to do that better.
I'm in an interesting position at the moment, which gives me a perspective I haven't read yet. I'm a construction administrator, who has to check the specs to ensure what the GC is submitting on is what we specified. I feel like half the time I'm on an Easter Egg Hunt, 1) searching for requirements in our own specifications, and then 2) searching for where that requirement was met in the submittal. Really? This harkens to Sheldon's point about what we are producing, and if that is the best method. In this day and technological age, why is MasterSpec still generating singular word docs, and not creating a database of fields? Why can't we attach a checklist of 1) the submittals we are looking by running a report, that finds all of the submittals we are requesting? Why don't we go the next step further and create a checklist form that has the specifications we are looking for, and have the GC fill that out when submits on a product?
From my perspective, even being on the same team, I say "hear! hear!" to the shorter, concise, half-page specs he speaks of. In my mind, it really goes to knowing what the hell your doing, and not just getting by by doing what everyone else is doing...