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.
Comments From a Spec Writer 
Most wise advise and comment- well-written!!!!
Wish I was thought smart and good [really!!!!!!, seriously]
Ralph W. Liebing, RA, CSI, CDT
Senior Architect- Specifications
Thanks for commenting, Ralph.
I wish I could manage to write every week, as you do!
Great article, you can find example of the ‘Not Wrong’ specification on recent LinkedIn discussion under Construction Quality Control Managers (USACE / NAVFAC)
‘How do you deal with a specification requirement on a building project for USACE that calls for the manufacturer to design a mechanical system? A manufacturer is not going accept this liability.’
There it is clear to me that Owners representative, QA, General Contractors Estimator/Bidder and even Mechanical Subcontractor Estimator/Bidder did not read and completely understood project requirements plan and Specification. if they did the issue will be resolved long before.
Thanks for commenting.
You make a good point about how many people missed that specification requirement that you mentioned.
Sometimes I’m amazed at the questions that make it all the way to me, as an architect’s consultant, during construction. Sometimes the answer to a question is right there in the spec, but a sub asks the question, the G.C. passes it on to the architect as an RFI, and the architect passes it on to me… and any one of those parties could have figured it out by just reading…
I have often dealt with similar situation. Fortunately early on I got QA who review my RFI and if he new the answer is in drawings / Specification responded ” duty of the GC QC Manager is to review Plan, Specification and if he could not find answer then forward RFI further. We re all professionals and we all need to know how to read plan and specification.. After this I always review plan and specification and most of the time information requested is there. Most of my RFI’s are addressing conflicting information, or real luck of adequate information.
As a seasoned architect, I really enjoy reading Liz’ blog, as it is informative and very topical. I do forensic architecture that involves specifications in a literal, legal context. Many spec mistakes I see come from the cut and paste methodology she describes. Many field mistakes result from contractors not reading the specs or complying with them. Very few spec writers or readers are familiar with the provisions of the standards that are referenced in many spec sections. Architects need to understand the implications of naming a standard (ASTM or other) in order to verify compliance in the field. Contractors need to understand the requirements listed in the standards in order to achieve the desired (i.e., contractually required) outcome. There is “right”, and anything else is potentially problematic.
Lee, thanks for the kind words.
I’m glad you pointed out that real BUILDING problems can occur from design professionals’ lack of attention to the specs. It can get so much worse than just the budget busts I mentioned.
Many years ago when I started doing specifications full time I read a book written by a seasoned specifier – I wish I could cite its title and author but I can’t. Anyway, he made a valuable point – if one does not have enough information to specify something correctly or right for the project then don’t specify it – very simple.
That said, after “construction documents” have been “officially” issued, I do issue revised specifications as the information becomes available. Issuing revised specifications is especially critical for D-B and IPD type project delivery – the problem that I’ve had with this is educating and convincing project teams and managers that this is appropriate and necessary, and that that my time should be billed for the work. Strangely PM’s seem to think that it’s OK to make changes to drawings, but not to specs – can someone explain this to me?
Mike, thanks for commenting!
Your question may have been rhetorical, but I think the answer is, as I wrote in this post, that many design professionals simply do not understand the importance of specifications. Combine that with the architect’s aversion to admitting that we issued imperfect construction documents, and the architect’s constant hesitation to ask the owner for additional fees for additional services, and we get architects not wanting any changes to the specs after the bid.
In the case of Design/Build and IPD, if you’ve had this experience with these project types too, the construction side people may not understand the major risk implications of deliberately not changing the contract (the specs) to match the work performed. That’s pretty foolish on their part. (Or maybe the architect isn’t mentioning this to the contractor types, because of the reasons mentioned above, and the contractor types just aren’t thinking about it.)
LIz, I am glad you found inspiration from my blog post. As specifiers, this right or not wrong status is a struggle we face nearly daily.
Case in point: I was called yesterday about a project in NYC that requires two elevators to be modified. (one used mechanical relays controls) The spec mus be done tomorrow. Of course there is no survey from the maintenance company to help with the spec and they are unwilling to help without being paid. So what will we do? Write about what is known and require the bidders to survey the existing conditions and submit a prioritized list. The list will undoubtedly result in a change order. So much for specifications being right.
Sometimes we just don’t have enough info, and “not wrong” is the correct way to do things at that point, when time’s up, and CD’s have to be issued.
When time’s not up (even though we have a deadline it’s just for a progress set, or for Design Development) it’s good to acknowledge that we haven’t gotten it finished yet, we need more info, we still have outstanding questions…
Thanks for commenting, and thanks for the inspiration of that post of yours!