The gist of David Stutzman’s August 2010 blog post, “’Right’ or ‘Not Wrong’ – Choose Your Specs Wisely,” has remained in my head since I first read it. “Right” or “not wrong” is something that I think about as I make my way through the preparation of project specifications in an early design phase of a project. For progress sets in Design Development Phase and early Construction Documents Phase, I always shoot for “right” or “with-lots-of-notes-to-architect.”
In that post, Dave wrote:
“Specifications can be written so they are “right” or so they are “not wrong.” These two are very different.
“Sometimes specifiers are forced to write a “not wrong” spec. This usually occurs when the design schedule is short, when the specifier is asked to start near project completion, when little documentation of product selections exists, or any combination of these. The “not wrong” spec is generic, non-specific. It lists basic products and materials, but does little to address project specific conditions. The detail of terminations and interfaces with adjacent materials – issues that can easily lead to failures – are glossed over or not even mentioned. This lack of specificity can lead to unnecessary, expensive change orders. Processing these change orders increases construction administration costs, and can result in budgetary disaster on a project.
“To produce a spec that is “right,” the specifier must understand the project and the design intent.” ~ David Stutzman
When “not wrong” specs are further edited to be project-specific, and therefore “right,” they can save time and money for the contractor, owner, and architect. “Not wrong” specs tend to push design decisions into the construction phase. Design decisions cost less money when they’re made in the design phases, and specs that are “right” are issued.
Now, from the “Things I Shouldn’t Even Have To Say” file:
“Not wrong” specs are not great, but sometimes I see “just plain wrong” specs. Sometimes such specs actually contain mentions of the wrong owner, the wrong building, or the wrong city. (If the spec section is for an engineering discipline, or audio-visual systems, or kitchen equipment, this is often the only way I, an architect, know it’s wrong.) This is an embarrassment to the entire design team.
I think this happens because of a combination of two factors:
First, in early design, people figure, “oh, we’ll do it like that one project, except for this, and that…” and they think it’s ok to issue, as part of a progress set, the finished specifications from that old project, to make the set look more complete. It’s not ok. Every project is different. If you need a “placeholder,” then consider issuing a complete Table of Contents for the Project Manual, naming all the spec sections that will be included in the final issue, and indicating which sections are not included in this progress issue, but will be included in the next. Do not issue something that is wrong.
Second, many design professionals simply do not understand the importance of specifications. Specs are much more than just a “deliverable” due to the owner. Specifications are an inextricable component of the construction documents, even in early design phases. If someone is estimating the cost of the project (and someone almost always is, even in early design phases) that person is using the issued progress set specs to help to determine what is supposed to be in the project, and therefore, how much the project will cost. Don’t issue a spec section if it doesn’t say what you want it to say. Hint – you must read it before you can know whether it says what you want it to say or not.
“Not wrong” specs can lead an estimator down the correct path, just not quite far enough. “Just plain wrong” specs usually lead that estimator all the way down the wrong path, wasting time and money for everyone.
If you’re not finished preparing your specs when your deadline comes, issue something less, issue something smaller, but don’t ever issue something that’s just plain wrong.