What are Specs?

Archive of Older Topics Archive - Specifications Discussions
1

It’s commonly known that “specs” are construction specifications written according to the CSI SectionFormat (3-Part format), following CSI’s PageFormat, and conforming to the principles and recommended practices of the CSI Manual of Practice. These are what “spec writers” produce.

But I think there are some significant themes and variations on these “specs.” I think it would be enlightening to discuss what are the alternatives to these conventional “specs.”

I’m thinking about “outline specs” and “shortform specs.” How do they differ from conventional “specs?”

I’m thinking about Preliminary Project Descriptions (PPD’s) that are organized according to UniFormat. PPD’s are gaining in acceptance and cost guess-timators find them very helpful for pricing projects during design development.

I’m thinking about specs that are prepared for multiple prime contract projects. How do they differ from specs for a single contract project? Do these specs establish scopes of various subcontracts and trades, and need they specify who does what and when?

I’m thinking about specs for design-build projects. How do they or should they differ from specs for a design-bid-build project? Are design-build specs really more simple or do they actually require more effort because they describe the work in terms of performance rather than products?

I’m thinking about specs for the subcontract agreement between a general contractor and a subcontractor. It is shocking to me that subs sign agreements to perform work “per plans and specs.” There’s a lot more that needs to be said, I think, such as responsibilities for scaffolding and lifts, for cleaning, for coordination between trades, for jobsite safety, etc. I think this is going to become very important as the design-build project delivery method becomes more significant in public-sector construction.

I’m thinking of other forms of specifications that I’m getting into, such as design guides for a medical center, a school district or a university campus. Even commercial property managers are developing design and construction guides and master construction contracts for tenant improvement projects. I’m becoming aware of increasing interest in having spec writers develop these.

I’m thinking of office design guides for architectural and engineering firms, that record the “corporate memory” for use by designers and drafters so they don’t waste time “re-inventing the wheel” when detailing the design.

I’m thinking of guide specifications published by manufacturers … specs that we would consider well-written and presented as word processing files that are usable.

I’m thinking about guide specs for maintenance and repairs, such as repainting and reroofing specs, where there may be no design professional involved in the project.

I’m thinking there are even more types of “specs” for construction projects that I haven’t thought about.

Does anyone have comments on these?

2

John,
As always you make some good points. This is something I’ve been thinking about as well. It seems that 80% of the builders and clients out there think of specifications as a typical book copied from the last project. They refer to it like a dictionary or encyclopedia, useful only when they don’t know what something means.

Your thought about the PPD-short form approach is a good one. Most of the time, that is all that is needed to get a project built. However, when we reference an ANSI, ASTM, or industry standard most THINK they understand what we mean, but have never read the material. Let alone have a copy.

I don’t know what the answer really is. But maybe the real question is; How do we get rid of the seemingly overwhelming information that comes across as superfluous and causes the target audience’s eyes to glaze over?

3

Specification requirements can be considered superfluous until they’re needed.

In my experience, specifications are used primarily by estimators during bidding, for submittal requirements and review during construction, and by suppliers. If the contractors are doing their job, the project manual stays on the shelf; good contractors don’t need the specifications to tell them how to build the project.

But when there is a problem, then the specifications become silver bullets. And the information that most architects and owners didn’t even know was there, can save their bacon. (Or if it’s not there, they can get fried).

Which segues into one of my favorite sayings: Look at drawings in the field and specs in court.

4

I would agree with Dave – there is so much language that even to me seems superfluous, but I know that its been added in response to our question of “now why would they ever think this was a good idea?” about something on the job site.
I like to think of specs as the verbal equivalent of the “limits of work” line on the drawings – describing intent and scope (quality) of the performance.
As for the target audience’s eyes glazing over – we have a target audience that often cannot concentrate enough to read a newspaper, and there is very little I can do about that as a specifier. Until we have videotapes of the expected performance and products that we want to see on the job site, we’re somewhat limited to the written word.

5

There’s a whole world of opportunity in the design community for something I think could be loosely called “specs” but which aren’t the 3-part format documents we are so very familiar with.

I’m thinking about the recording of design information. I’m thinking in terms of product and system information that needs to be communicated during development of the design, between the owner, designer and builder. It needs to be communicated way before construction contract documents (3-part format specs) are produced.

I’m not talking about any sort of new revelation here. I don’t think I am. It’s just that I have a heightened awareness of the need for such documents.

I’m involved with design professionals who need to record information about the products and systems of a project, in a form that they comprehend (i.e., probably includes pictures and drawings and “stuff”) and that they can use to communicate with the owner and spec writer. They try but the effort is disjointed, stangely organized (according to functional elements of the facility … but nothing too technical like roofing and waterproofing). The process is in dire need, in my opinion, or more integrated thinking.

I’m working with a public university to develop what is being called a design guide. Many universities are doing this (search the Internet). The idea is to figure out what is the university’s way of doing things and to communicate to design professionals what the university’s requirements are. In particular, there are existing products and systems in place on the campus that new construction must interface with, if not mimic. And the university wants to avoid repeating problems with unsatisfactory products and construction practices. This is turning into a very substantial task. The portion about developing prototype Division 1 specs is taking weeks of meetings.

When I think about LEED projects and when I think about commissioning in narrow and broad forms, it appears to me that very substantial documentation will need to be produced. In my opinion, this documentation can be (perhaps loosely) considered specifications. Importantly, I think it means that spec writers need to be involved in developing these documents, and that means there is even greater need for qualified people to write specs.

So, I see increasing need to produce project-specific “alternative” documents such as PPD’s and outline specs. I also see a growing need for campus design guides and office design standards, which express product and system selections. The last thing, office design standards, means involvement with office standard drawing details and even the whole issue of standardized keynotes.

My motive is a hope that by increasing awareness of the need, there will be more appreciation of the role of spec writers, more people will want to write specs, and there will be more educational resources put together to prepare design professionals and others (?) to produce these documents.

6

As a Project Manager, my goal is to simply communicate what is needed in the clearest terms. I do understand the need for covering the “now why would they ever think this was a good idea?”. I appreciate that knowledge and recognize it’s value.

My point is that at some level, we are caught up in defining how many angels can sit on the head of pin. For many users of our construction documents, we reached that point a long time ago. This just furthers the disassociation of Architects from the building process. When an Owner wants to build a new facility in a area where do they typically go to start the process? The answer is, first a real estate broker and second a contractor. Of those that want to call an architect first, most already have one.

There is also little we can do about our audience. For a while now it has simply been a case of dumbing down the marketplace. It is not just the construction personnel. Even the new so-called graduate architects have only minimal comprehension of the real depth of technical decisions required to complete a project. (And that includes Principals!!)

Along this line of thinking, I see clearly what it is that John is asking about. To me it really is the preliminary project description document. It is the only organized tool that grants us the ability record decisions on the fly in a hueristic fashion that a client can understand. It is what I have been using.

How else can I log what the decisions are before they are on the drawings and whether the Drawings specifications are correct? A simple example is; what is the correct Owner approved paint color? Is the one on Drawing the most current or has it been changed?

But, unfortunately most project staff look at this tool as a “make work” task…

7

Rich,

To address one of your particular concerns…

To me it really is the preliminary project description document. It is the only organized tool that grants us the ability record decisions on the fly in a hueristic fashion that a client can understand. It is what I have been using. How else can I log what the decisions are before they are on the drawings and whether the Drawings specifications are correct? A simple example is; what is the correct Owner approved paint color? Is the one on Drawing the most current or has it been changed? But, unfortunately most project staff look at this tool as a “make work” task…
<<<

Myabe you ought to have staff specifiers.

Speaking as one, I find that document of high value, as well as the Outline Specification thru Design Development.

But more than that, what is most appreciated by our Project Managers is a fully developed checklist that they are give when the ask for it, or when a project is first assigned to them. In addition, for colors and finishes, we maintain a document in Division 1 that records every color/finish of every surface. All technical sections refer to this one section for every color. This section is given to the Project Manager in electronic form along with the checklist, and they maintain and update it and send review copies to the Owner for the Project.

Project Managers need tools that work, and tools that as they use them can be handed to the specifier to make their task easier as well.

8

Mr. Pegues,

Thank you for your input. What fascinates me is how as we go from one office to the next these kind of project decisions are handled so differently.

I firmly believe that we have a need for at least four in our firm. We have NO such dedicated personell. We have ONE outside consultant. And that consultant’s fees are a cheap flat rate per book. That consultant requests the decisions about what is an appropriate building system, be made by the inexperienced Project Manager. Mostly what I’ve seen is standard MasterSpec generic drivel. But, in defense of this, it is what has been forced upon this independent consultant by principal partners who think that every building is like the last one. Except…

The net result is that a specification consultant is viewed as slightly more than a typing service. A know-nothing CAD drafting consultant gets more respect and money.

In an era where we handle far too many projects simultaneously with too few qualified staff, the individual project manager must survive by tracking these decisions him/herself. Defering it to a checklist is a good thing. But by the nature of it’s description, and all the versions I’ve seen in 29 years, it would appear to be lacking building assembly content that guides to inexperienced PM to the kind of decisions that need to be resolved. Virtually, every list I’ve run across are little more than MasterFormat headings.

BSD’s SpecLink approaches the concept but it is full of enough detail to fry the brain of these project architects. When I try to explain what it is that we need to work out, the eyes of the staff and even the principals just glaze over. The problem is once you start going into the detail of what is needed to record these professional design decisions, where do you stop?

I believe that is at the core of what John was asking. What we need is a simple facile tool that works for the market category that your practice works in. Your checklist appears to work well for your office. But my question is, why must we all re-invent this wheel?

As for your Division 1 finish list. That is a very useful tool. I use a Section 09000 for just that purpose in the final spec. It is merely a table that I cut and paste from the PPD.

9

Rich:

What I am trying to bring out is that there are more types of documents produced by “spec writers” than the traditional 3-part format construction specifications used for bidding and construction.

Design guides, where products and systems are identified and prototypical design criteria are established, are one type of document. Going through the process of establishing design guides for various project types, for various clients and for various quality levels of construction, would make the processes of drawings and specifications production more rational and expedient (< $$$). I’d include the checklists you mentioned in the contents of design guides.

Uniformat-based documents (PPD’s) are very different from 3-part construction specifications. I bring attention to PPD’s because their format is more consistent with how designers think (building elements and systems). I think PPD’s are project-specific derivatives of office design guides. (Which brings up a big question of how to organize design guides, if they’re used.) PPD’s are or could be documents produced by specification writers during the design development phase of a project. Typically, specification writers don’t get involved in a project until late in the Construction Documents phase.

There are two big issues that I can think of related to developing and using design guides and PPD’s: time and money.

If there’s no time to do design guides or PPD’s, then there will be business as usual, with all the frustrations that have already been expressed. I don’t know of a spec writer who couldn’t express frustration over the design decision-making process in capital letters, neon lights and four-part harmony.

If there’s no money (fee) for doing design guides and PPD’s, then (in my opinion) there will be the typical trial-and-error method of design decision-making and production (including change orders). This way of working is no fun.

I’m not necessarily advocating either design guides or PPD’s, or even office prototype specifications. What I’m trying to do is call attention to these types of documents that specification writers can or do produce. I’m trying to include them in the answer to, “What do specifications writers do?”

My hope is that awareness can be raised about the value of well-prepared design development, pricing (bidding) and construction contract documents. And, my hope is that the talents of specifications writers in producing these documents will be recognized and appreciated.

10

John,
You have the right idea. The only way to accomplish these projects qualitatively, is by the use of hueristic tools.

One of these is the checklist format that Mr. Pegues referred to. I am interested in what their firm’s view of what is included in this and how they use it to interact with the PA. The process he referred sounds like a very good approach.

Many people talk about it, but few do anything about it. Fewer still share the information. I wonder if Mr. Pegues has something that could be shared spelling out this process and specifics fo the tools themeselves.

The approach mentioned leads me to this conclusion: If this kind of a system could be implemented early in the project process, life could be much easier and less time consuming for the PA-PM and Owner. But isn’t that the idea?!

Personally, I like the Uniformat-PPD approach because it uses assembly systems as the descriptive tool. At these earlier phases of the project that is what we need most. It helps to serve the purpose of keeping us out of the unproductive details.

What do other people think…? What other tools are out there, that people are USING?

11

Rich,

The checklist is very comprehensive and has 2 purposes.

The primary purpose is to record decisions, selections, etc. and convey to the specifier. The checklist is written in a very brief question format each section from the master usually takes up about 10 or so lines (questions) some have more, some less, but that is probably about an average. They typically are everything that I need to know to write the section for that project. Understand that there is an interview process, so some of these are leading questions. Depending on the answer on the checklist, that may lead to more detailed questions during the interview.

The PM/PA is encouraged to add any additional notes, or even write in questions of their own. This leads me to refine/improve the checklist over timebut serves to point out specific very special situations for any project.

The secondary purpose is to convey information to the PA/PM from the specifier to prevent them from misunderstanding something, issuing a caution, hilighting an office policy on a particular material or system, or just pointing out potential problems up front that we have experienced.

They get this document very early, as early as they start working on it. Some dont want to start it until after Design Development, some want to use it from the earliest stages.

At a point about 4 to 6 weeks from permit time, they reach a milestone which is on our office electronic calendar system (Outlook) that reminds them they are required to check in with me for dates, give me the job name/number, and a list of sections that the structural engineer, landscaper, other consultants are editing, or if they are writing their own gives them the page format/layout guide. At a point that is 3 weeks from Permit, the calendar tells them we have an interview.

We sit down together with the checklist, only their marked up copy, and the drawings to date. They should have in hand the edited markups from consultants. We very detailed go over everything, I answer their questions, they answer mine, its very interactive.

At the end of that, they will still have some areas that are unknown, indefinite or just not completed. They have a few days to complete that and give it to me. Cut sheets requested from the checklist are attached.

They give me their original, they keep a copy. This is intentional, the copy they have is all black and white. They are then to make any changes over the next couple weeks on the checklist in COLOR.

As I create the project manual and come to an area where I need more answers, I seek them out and ask. Typically, I make a pass through of everything that is complete, then start back on open items. By then, they will have more markups from theirs that they can convey to me. Or, sometimes some sections have open holes in the that the project at that point has not addressed.

At the time the Permit is submitted for, I publish a draft. This draft then becomes a replacement for the checklist. The PM/PA records all the open subjects from the checklist to the draft and a markup of it will be what is given to me. He still uses the checklist for reference as it contains all the questions/comments that are essential to any section, he just records the answers in the draft Project Manual from then on.

We have been doing this since the mid-1980s shortly after I set up the specifications program here, and it really works well. Does this system break down - not yet in all this time. That’s a benefit of having an inhouse system - it becomes office standard, no exceptions.

There is only one of me, the specifier, we are an office of just under 100 here in DC and another 15 or so in Dallas, TX. We do design and contract documents ranging across commercial office buildings, high rise residential, corporate headquarters and high rise hotels, with a smattering of other types of work.