What does a specifier do?

When asked by someone what you do for a living, how do you answer them? How do you explain to the general public what a specifier or specifications writer does?

The best approach I have found is to relate specifications to their understanding of the drawings. Most people would associate architects with drawings, which is not incorrect.

So: whenever a building project is designed, there is a set of drawings and a set of specifications. Specifications contain requirements about products, standards, and procedures. Buildings are far too complex nowadays to develop with only drawings in mind. Drawings and specifications go together as part of the construction contract documents.

It’s very similar to what I tell architects, actually.

I write the big book the contractor uses to prop open his office door. :wink:

I say something similar, in stating that a construction project requires specific documents to be built, graphic part which is on the drawings and the qualitative or written part of the documents called a Project Manual. As a specifier I write and compile the Project Manual for the construction project.
Most seem to understand without too much of the eyes glazing over.

This is both a simple question and a complex question. It depends how you expect your “public” to understand your answer. They may want to know how I spend my day, or they may be highly curious about the field of architecture (as it really is).

It’s simple to state that I write, but mostly edit, technical documents to describe the work results (defined term) including products, materials and systems for architectural projects.

I could also list a series of procedures taken to accomplish this including research, drawing reviews, evaluations, etc. and the tools we use, computers, internet, etc.

But, as an architect specializing in design accomplishes the design work primarily by some form of drawing, and I don’t describe design in drafting or drawing terms, even for the general public, nor do I don’t describe my work in terms of technical writing.

I tell people, meaning general public, I’m an architect who specializes in technical consulting to other architects. I rarely mention specifications until a persistent person wants more information.

I just tell them I provide written descriptions of all the products used on the building and I provide all the information needed to make sure the building is built right.

I rule the roost and make demands of all around me-- no, no no-- in fact many there pay no attention to me at all!!!

In addition to the above, I would explain that on those occasions when the contractor does pick up the book :wink: I create, that what he/she will find is a lot of information, all of which is necessary and important to the project, but cannot be located on the drawings; most is virtually impossible to portray graphically. And in addition it includes a lot of information that adds to, or further explains what is on the drawings.

As noted, I’d emphasize the thought that BOTH drawings AND specifications are required to build the project.

I tell them the Architect’s drawings are the where, and my project manual is the who, what, when, and how.

It’s interesting to see a focus on products of service. Most other professions would not describe themselves through the products of their services: teachers, doctors, lawyers, would say inspire, heal, defend respectively. We make drawings and specs. hmmm.

I wonder what anon’s motivation was in asking this question? Just need to tell future father in law what you do? or something more interesting?

I explain that I get to tell the contractor what they can use and when and how they can use or install it - and they can’t argue with me! (The architect can tell them where to go with it)

“I basically work as a consultant to other architects doing research and technical writing about products and procedures for constructing buildings they design.”

Work on Saturday.

My Microsoft buddy calls me a “Technical Writer” which is a fair generic term for the unitiated to describe what we do.

I wrote an article for the Feb 07 CSI Leader that is available to all at
http://www.csinet.org/s_csi/docs/14100/14002.pdf
under ‘Membership’ titled “The Importance of Specifications” that gives a more lengthy but still imcomplete description of what we do.
Check it out.

When I drew unemployment following a layoff, many years ago, “technical writer” was the closest the bureaucrats had to what I did.
Now, I tell architecturally uninformed people that “I write the book that goes along with the drawings, which says what to build the project of, and how to do it to be acceptable to the owner”.

I tell non-construction adults that I’m an architect, but that I’m in charge of the written part of the design documents.

I tell kids that I write the instructions that go with the drawings. Kids who build models or use Easy-Bake Ovens know exactly what I mean.

And I tell construction professionals of various sorts some variant on what the rest of you have said, usually something like “the specs control the quality and the process, things that are hard to represent in drawings.”

Actually, I tell the architects that the spec is like the instructions to an Easy Bake Oven too, most of them seem to understand that. Talking about process and quality confuses them.

You should hear the conversation when I try to tell them where babies come from.

“When a mommy loves a daddy VERY much…”

I like this article in Archi Tech magazine about specifying and cost-estimating with BIM:

http://www.architechmag.com/articles/detail.aspx?contentID=3624

Is this what specifiers can do, or will soon be doing?

I saw that article, too. Interesting, but I disagree with the conclusion that a single program won’t be able to do the modeling, generate specifications, and prepare estimates.

I saw susan’s presentation of basically the same information. As one who has dealt with Large Revit files I believe the interoperablility is much preferable. AND Revit is not made to deal with text not to metion the spreadsheets for estimates.