Still doesn't mean they will be read. Also how small is small? We've done this on 2,500 sf interior build out that had a lot of the finish work done by the owner. If not for the owner work we would of needed a spec . . .

Miles, I actually cut this portion out of the OP because I was trying to keep it brief ... but I saved it because I knew it would get brought up.

Sometimes PMs will suggest we simply put the specifications on the drawings, which might have some merit (and we can discuss it), but my experience is that if the contractor isn't going to look at the specifications in a project manual, they won't look at them if they are on the drawings. It's usually not the location of the information that's the issue.

If it’s on the drawing there is no excuse for ignoring it.

If it's in the specs there is no excuse for ignoring it.  Drawings and specs are complementary and together make the CD's.  

If a contractor is going to ignore the specs because they aren't on the drawings then having them on drawings realistically won't help.   

On a small job you typically have small contractors. Tradesmen, while adept at their trades, are often not particularly adept at - how shall we say - administrative matters. The tradesman wants a picture with just enough notes and dimensions, not a spec book.

A GC should of course be on top of the specs - but let's face reality here: small jobs, small fees, competing interests (other jobs, turning a profit, architects papering the file, etc.) make economics an issue, especially when everything is bid to one foot in the grave and the other on banana peel.

I'm not making excuses here, just pointing out reality based on experience at both sides of the table.

I agree with the statement, and reality, about small contractors and tradespeople not always being adept at the administrative matters. I've tried pitching to these PMs to work with me to better develop the specifications we'd issue for those jobs so they are easier to comprehend and not so daunting for the "not particularly adept" contractors. We can focus on what submittals we really want to see and take out all the other stuff that probably doesn't matter. We can find out what types of products they are most likely to use and specify those instead of our usual. Et cetera, et cetera.

Occasionally one of them will take me up on it. Then they get annoyed when I explain that it will take more effort than a typical project manual. They don't want to actually do that work and we end up with a fairly typical project manual because they won't put in the effort to make it better.

I've come to the conclusion that they'll either spend the effort in CA working through the issues, or they'll spend the effort tightening up their documents. Either way it takes effort.

Ironically, the last job that I did this on, one where the PM actually took the effort to do it, we worked the GC to make sure they understood the documents were going to be pretty abbreviated and they were all for it. It made sense to them that some things were better communicated in writing than as a bunch of notes on the drawings. The examples we showed them really made sense to them. Then the owner decided to fire them and go with a different GC who needed more hand holding than we anticipated. We actually had to add a bunch of stuff to elaborate on the things they didn't understand by simple references or previous assumptions we had agreed on with the previous GC.

Something, something, everyone has a plan until you get punched in the mouth, something, something.

On small jobs we have 3 sheets of specifications that are right in the drawing package. Dont bother with a spec book.

Almosthip, what defines a "small job" for your office? Are they edited to be specific for each project, or are they just copied in without really editing them? How/who edits them for the project? How/who updates the master/baseline version of them for your office? When were they last updated? Are they written like a standard 3-part spec or something else? Organized according to MasterFormat or something else? Do they cover technical specification divisions only (Divs 02-49), or do they have information for Div 01 as well that covers administrative requirements?

I used sheet specs like that early in my career, all for TIs in strip malls. They were standard for that particular corporate client. No one edited them for the projects, they were just included as one sheet in the final drawing set. Occasionally the client would update their material standards and one of us would update it in the master sheet. They were written like a 3 part spec but stripped out the Part 1 information and only briefly would touch on Part 3 stuff occasionally if it was important. No Div 01 stuff if I recall correctly (CA on those project was pretty non-existent, as the client would really manage it on site and we were all remote). 

They probably weren't even necessary. The client had purchase agreements with the finish material suppliers and the materials were sometime specific products only available to that client (corporate colors, etc.). I'm guessing the contractors would get a list of contacts for procurement of these materials and they could probably have done everything just from that, "Hi Company ABC, it's contractor XYZ. Yeah we need to order rubber flooring for a project for Client QRS. Yup, typical product in their corporate color blend. I'll email you the take off info and the delivery address. Great, I'll let you know if there are any issues."

A small job would be under 10mil. We are a multi disciplinary firm and I know that structural modifies their specification for each project. In the Arch dept I revise which sections that are need for that specific project, and remove sections that are not applicable. We use the master spec format, and it includes all the front end stuff that never hardly ever gets modified. I also do drawings for a major food chain and they provide me with updated specs sheets all the time, too much for my liking actually, about 2 times a year. M & E also have their own spec sheets at the beginning of their drawings sets.

Is that 10 mil in fees or construction cost or value at market?

Construction costs

How did your office arrive at that number?

I pushed my last office to try to come up with some type of metric(s) to determine which projects might have specifications vs. which ones wouldn't ... and of those, which ones would be done in-house vs. which ones would use a spec consultant ... and got no where. They were apparently fine with the PMs and PAs "winging it" on every project regardless.

I gestamated at that number. Its really more about the complexity of the project. If its a shop/office defiantly a spec. sheet. If its a school than a big spec book in in order. Really its the decision the PM and the client make. Also probably would depend on the fee we are getting. Small fix fee vs % of const.

My overall question is still the same whether you think the contractors are lazy and dumb, or something else ... why do we let them get away with it?

Maybe you don't let them get away with anything. Kudos if that's the case, but I bet it's not the case all the time. I let some things slide so I don't have to deal with the headache. Also because I'm not usually the one running CA and they've already let a ton of things slide by the time they call me in.

A bunch on semi-connected thoughts:

• I think they way contracts and liability work plays a big part in it. In CA, we're just, like, an opinion, man. 
• The contract is between the owner and the gc, and if they've already fucked shit up (they always have!) it's either a cost or time setback, both of which the owner usually wants to avoid. On projects where the owner stands firm (I think beta's example in the other thread was great) we have a fighting chance. Without that, forget it.
• Doesn't matter if I want to let them get away with it or not. I stood up to a GC/ sub on a a totally substandard item 6 years and 2 jobs ago and it is still being litigated because the client agreed with me, thought design was important, and wasn't going to roll over for them. 
• Anytime I'm doing CA, I think about Miles Jaffe's adage that "if the lawyers are involved, it's already too late." So when the GC does have trouble, I'm there holding their hand, suggesting means and methods, reminding them what sheet things are on, finding the cut sheets for them, and all the rest. I didn't get into this business to draw drawings, write specs, and talk with shitty lawyers, I got into it to design capital-A Architecture and get that shit built. 

+++ The old man taught me that the most important job is getting the project completed despite the owner and the contractor.

^probably the reason I let more things slide as I've gained more and more experience. That said, it doesn't make my job during CA any easier if we just ignore the specifications. If all the parties involved cared to follow the agreements they've made with one another things can go quite smoothly.

"... you think the contractors are lazy and dumb, or something else ... why do we let them get away with it?"

Most often it's drunk or hungover but that's probably in the something else category.

I would say, we should not take or put up with bullshit excuses. However, we have to sort of pick our battles, sometimes. 

Rick, no ... stop. Don't embarrass yourself anymore. Do yourself (and the rest of us) a favor and unplug your keyboard while reading this thread. If I thought like you could add anything to the discussion I wouldn't say that. You want to continue to post about things you know nothing about, go continue what you started in the Laws across USA thread that recently got necroed.

The contractor being drunk or hungover is partially true but meant more as facetious humor. However, I am more serious about the part that was saying not putting up with bullshit excuses but also that we need to pick our battles, which for a variety of reasons may be more practical.

Oh damn. Here we go. It was a good thread while it lasted EA.

Fine, you made your point. We all agree that we should not put up with bullshit excuses and that we should pick our battles. It's already been stated by many people here. Those people have a lot more experience than you do in dealing with contractors' bullshit excuses and picking the right battles during CA. We don't need you to restate what others are already saying just in your own words so you can seem important. Just give those people a thumbs up or a thumbs down and move along.

Do not balkinize my thread.

Rick needs to pick a different battle.

Our spec software defines what all of those ASTM standards are. Part of the issue is architects just using 'standard' specs without knowing what is in them. Specs should be written with the project. Just not at the end. Staff should be able to reference the specs during CD's to determine how to detail / draw / note something.

I'm not even sure where to start with that type of a take? What else should the specs be ... generic suggestions?

The BIA recommends I should use G90 coated steel studs for a masonry veneer backup wall. Do I just write the specification and say, "Steel Studs: In accordance with brick industry recommendations you probably aren't even aware of," and hope for the best?

I don't really care if the GC or the sub knows what G90 means. They need to know enough to ask for it when they put together their submittal and buy their studs. Communicating that to all interested parties through standard terminology in accordance with a recognized industry standard is actually one of the simplest things in the specifications and I've probably done them a favor.

Your example spec paragraph makes no sense, but it's not because it is written as a specification (though it probably is a poorly written specification). It just makes no sense (maybe it's just out of context). Where did that paragraph come from? Is the typo part of the original, or from your transcription? What type of testing is it even talking about? I'm guessing if you look up the (unspecified) testing standard that describes the procedure (whatever it is) it would address the substrate requirements. My hot take is that paragraph is probably not necessary.

My spec example was from just a generic sealant; Just a random pull from a manufacturer spec. What you are saying is a big part of why spec books are trashed. Who is specifying the metal studs? Normally the structural engineer, not architect. Did you pass this along? Do either of you know why it would matter or not if your studs were galvanized to G90 or G60, or even not galvanized since they are buried in your wall assembly? If you don't know... why would you think your mason, who may not even have a solid grasp of english much less a formal education, go ripping through a spec book for metal studs specifications to verify the framer complied with a G90? Are you even verifying in the field? Are you double checking this was coordinated with your subs and on the shop submittals?

And don't get me wrong, specifications are important... but even I know they are often ignored. It's a problem of too much information which most, including the design team, don't really know what it means or why that is in there because they are often written by the technical folks who are intimately familiar with their products. With larger GC's using suppliers, those suppliers will coordinate with the specification to ensure the material they propose meets the spec. But with smaller GC's using more of the Home Depot and lumber store suppliers... those guys pitch the specs. Personally on small projects I tend to use more detailed notes on the drawings or a small uniformat project manual (descriptive narrative vs technical spec).

I think we basically agree. Perhaps I would state it as the specifications became too bloated with technical information, but I think the underlying issue you're describing is that we don't know what is in our specifications, why it might be important, and whether or not it should be there for any particular project. I agree that those are issues, but I don't think the problem is in the specifications, but rather the specifier and/or architect who prepared them.

To your other questions about the steel studs ... non-load bearing cold formed metal framing is something our SEs will typically not take on in their scope of work so the architect does usually specify them. I have some ideas, but no, I cannot say for sure why BIA recommends G90 over G60 ... but I can say that I'm pretty sure that if you were to try to establish what the standard-of-care would be for this, it would be to follow the BIA recommendation for G90. I could also probably make a phone call and figure it out in less than 30 min.

I don't expect the mason to be responsible for verifying the framer complied with G90 coatings ... that would be the GCs responsibility. Before we get to the field, we've verified in the submittal that they would be planning on using the correct stud, we'd also usually see it called out in their shop drawings ... that's typically part of the architect's job in reviewing and approving submittals conform with the design intent communicated in the documents. Yes it can also be verified in the field, though that's typically not the architects job. We aren't going to the site to inspect the construction. We are going to familiarize ourselves with the progress of the construction and to observe whether or not it generally conforms to the contract documents. These observations don't relieve the contractor of their responsibility to ensure compliance with the contract documents and to build in accordance with the approved submittals. Unless I suspect there is an issue with the studs on site not being what was required in the documents and what was submitted, I probably won't verify if they comply ... I can trust the contractor.

That said, if I did suspect something and I did want to verify, it should be quite easy as the framing standards required by the building code, and I would have required compliance with those standards in the specifications for my project, require that all metal studs are imprinted or otherwise labelled with identifying information at not more than 8 foot intervals that would include the coating designation.

While most of that stud stuff is probably an unnecessary flex in response to a random reference to a G90 coating, it does get to my point about how we should know enough about these things to do our job effectively. The specs shouldn't be filled with random things just to make them look complicated and technical. They should have the necessary information to communicate to the contractor the requirements they need to follow. Part of that is coming from the building codes or industry standards. Part of that is architect or client preference that might be above and beyond anything the codes may require. But it does need to be communicated if we want to ensure it happens. So I'm not worried that specifications are technical, but I do agree that they have probably grown bloated with overly technical information over time and we should work to strip that stuff out and that probably means we need to be better educated about the technical requirements of our documents.

In my experience, architects get nervous about deleting language they don't need when in reality it is more about editing down to the bare essentials. MasterSpec masters are meant to cover a large variety of options so yeah there is a ton of language in there that probably isn't relevant to a good portion of projects. Instead, architects see the MS master as "well MasterSpec is recommending it and it looks correct, so I should keep it in." Basically, if you don't know what it means, look it up or delete it, and put in your own requirements.

The approach MasterSpec takes to spec editing being a subtractive process can be problematic if you don't know what something is there for, and why you might need it. We are too nervous, as you point out, to get rid of things that we don't understand (and may not be necessary for the project).

BSD flips that and has their whole process be an additive approach which makes sense to a lot of people and they have their own avid fan base because of that (IMHO). You can usually end up with a much smaller set of specifications using BSD than you do with MasterSpec.

That being said, I have problems with the lack of information and the poor writing with BSD and can't handle it from a technical point of view. I've seen so many issues with BSD specs that have cause problems because someone didn't know what they were doing. Worse yet is when a consultant is writing the specifications using BSD. If an architect is reviewing their specification to coordinate it for the project, they sometimes need to see what options they might have available so they know what to ask the consultant to add, but the consultant doesn't add it unless the architect asks them to, and the architect doesn't know what to ask them to add if they can't see it, so it's the blind leading the blind in a vicious circle.

That said, in good hands, both can be used to create really tight, well-written project manuals. They key is knowing what all the stuff means. 

We only use MasterSpec because of that exact reason. For us, it is easier to forget important language or standards when it is an additive process like BSD uses.

Also it seems that even the most knowledgable architects that I work with (in terms of materials and detailing) have very little idea of how the spec should read, how to review a spec efficiently, and what info should be in the spec and why its important. I’m not sure what the solution is to remedy this. I’m thinking of giving an in-house tutorial, but given many are senior to me, not sure how it would work out. I’m curious if/how you have dealt with this, EA, or others out there.

I think it depends on what you want your remedy/goal to be. I've pretty much given up on trying to teach the "old dogs new tricks" when it comes to understanding and coordinating specifications. I'll help them get better documents where I can in the process of doing my job, but my focus isn't on teaching them unless they come to me wanting to learn (and some do after working with me for a while and seeing that I can help them). I'd rather focus my efforts on the younger architects and aspiring architects in the firm. They are the ones doing the documentation on the drawings most of the time anyway, and the ones that will be reading the specs to review submittals and answer RFIs for the most part. And they'll eventually grow up and train other young architects, etc.

I had a supervisor that would sometimes suggest that if you had to, you could always flash your credentials to get the "old dogs" to fall in line. I never did, but thought about it at times ... it's kind of a dick move TBH. You have a CDT and a CCS though, right? If you had to, you could potentially point those out as something that might get them to respect your expertise in this particular subject if they are reluctant to trust you. I doubt that it would really work effectively though. If they are of the opinion that the credential doesn't really mean much in the real world, you'll never convince them otherwise. If you do try this, I'd recommend doing it subtly rather than throwing it in their face ... "You know, when I was earning my specifications credential, I learned that you should _______. What are your thoughts on that for this situation?" ... make it about the solution or the application rather than the credential.

Edit to add that you have to pick your battles too. Sometimes it's just not worth the headache. Dig in on life safety stuff. The rest of the time it's probably going to be ok if you let it go. Do what you can, but don't let it get to you.

Damn French language keyboard setting messing up auto fill.

I personally like Uniformat on small jobs. I did run across an interesting project manual on a high end residential case. This manual had all the details in it, product cut sheets, and generally the front end (submission type stuff). Even included appliance cut sheets and renders of specific elements like the fireplace mantel. Sort of a weird mix of taking drawing detail sheets and moving them into the book. Oh... and everything was hyperlinked back to the drawing set and manufacturer webpages for installation instructions.

We don't eve bother saying 'per spec' or 'ref spec'. It's understood that the specs are part of the construction docs and don't need to say that. We'll just use generic terms like 'exterior sheathing' to mean OSB, plywood gypsheathing, ect.

So which is it?

I don't use abbreviations for products on my drawings. If there is not enough room to write things correctly, then change the detail scale. The only ones I use such as O.C., A.F.F., U/S, and so on are listed in a definitions drawing on my first drawing page so there is no confusion.

Chad - I only write "per spec" because I've previously had contractors tell me that I "didn't tell them what manufacturer to use" for the liquid flashing (or whatever), so they picked their own, requiring me to then review submittals after I'd already done the legwork of specifying the product. So now I write everything "per spec" so there's no excuse not to look at them.

My assumption is that if I did residential I wouldn't worry about specs and everything would be on the drawings. Personally, I wouldn't expect a residential contractor to know what specs are, unless they do really high end work. I would push for some level of drawing and spec literacy from a small commercial contractor though.

To the other points being made about referring to specs from the drawings, and abbreviations on drawings ... the CSI Project Delivery Practice Guide covers it as follows (emphasis mine) ...

"Because the drawings and specifications complement each other, the same terminology should be used on the drawings as in the specifications. Text should be kept to a minimum and should only identify an item and its extent or location. Specific product characteristics and installation requirements should be described in the specifications. Phrases such as 'See specifications' or 'Refer to specifications' are obvious and should be avoided."

"In general, construction documents should include an edited list of abbreviations that are tailored to the project and not the long, all-inclusive list of widely used standard abbreviations. It is recommended that abbreviations used on the drawings be listed on the drawings rather than in the specifications. It is recommended that the use of abbreviations, especially for words of five letters or less, should be avoided."

EA - Yes, but then again, residential contractors (even for large, high end homes) need that extra push. I always try to take the approach of less is more when it comes to my CD set annotations, but ultimately, I either idiot-proof my drawings with "per spec." on text note callouts, or I pay the price later in CA when I have to hand-hold the contractor through every product. I personally choose to spend the time in annotating my CDs so I don't have the hassle during construction.

Miles Jaffe wrote:

"So which is it?"

It will say in the specifications.  Duh

I must have been working with good contractors my entire career. I've only on 2-3 contractors who 'missed' something in the specs. I've never had a contractor who didn't read the spec.

I feel very lucky.  That or I've just had preconstruction meetings with the GC.  Could be both.  

"When something is made idiot proof, they will just make better idiots." --Stephen Hawking (or so I've seen it attributed ... I couldn't verify if it's true or not)

One thing I've learned over the years is that when you ask people why some note or language appears in the documents that doesn't make sense from a technical, contractual, or best documentation practices standpoint ... the answer is usually that someone got burned on a project once or twice and added the language to CYA or make it idiot-proof.

There have only been maybe a handful of times I couldn't find where we already have something to address that in the documents and the person that got burned just didn't know where to look. So their additional language wasn't really making the documents idiot-proof. Rather, they were just showing that they didn't understand their own documents. Instead of taking the time to add in a bunch of language and make things more confusing, spend the time to understand the contract documents so you can better enforce them.

What will you say to the contractor that finds the one detail where you didn't say "see specs" and complains that they did it as shown on the drawings and didn't look at the spec because the drawings didn't tell them to?

"We do argue about the scope as defined in the specs vs what they planned on doing based on the drawings they reviewed when bidding (which I think is what you're getting at)."

It's not, but that's ok, I struggle with this on every project it seems regardless of the specifications. We've got one right now where the GC is sending us submittals for things they need to order because of long lead times due to the pandemic and we haven't even issued the pricing set of documents (drawings or specs). The project is still being designed, but we have to return those submittals in order to keep the schedule. Not sure what they expect us to review the submittals against. No, they didn't provide us with a time machine to go into the future to get the not yet finished drawings and the not yet started specifications.

I do agree with your other points too. I'm bringing this up not as something where I'm trying to win every argument by pointing to the specs or something (more so if the owner won't back you up or care). I hope that's not how it's coming across.

I bring it up probably more to shed light on how we can best communicate our design intent to the contractor. I believe that if it was easier to understand and interpret the intent, they could better bid and construct the job. Then they don't need to make so many assumptions during bidding that leads them to needing to "balance their sheets in the background."

I've noticed a significant increase in "covid tells us we can't get this in less than 51 weeks, so here's our substitute" and I've personally pulled homedepot, fergeson, daltile, etc quotes/invoices etc to prove them wrong.

Huh, that's funny, daltile says if I order today I'll get it in 4 weeks.

it took daltile 5 weeks to send me 4 samples.

freebies different than invoiced stuff !

A problem compounded by financial imperatives on all sides.

Absolutely. An unfortunate reality we have to deal with.

It's also a reality that is compounded by the desire to meet unrealistic deadlines, often at the expense of adequate QA/QC. The people doing the drawings are usually not the people looking at the specs. And the people writing the specs are often not reviewing the drawings. Instead both are done in parallel with only loose email correspondence and redundancy/contradictions show up all the time because there isn't the built-in fee to cover the time needed to review the two against one another

I develop as you go. So, it is broken up essentially by assemblies like super-structure, sub-structure, exterior, etc. Below that, you break it down further like ‘Type A” exterior wall assembly. Then as you get into DD, you break down farther into the components of those assemblies. We found it was also easier to insert graphical information like the kitchen designer equipment spec, interior design, and sort of how you want it to work operationally (think interconnected doors). We’d even put in “design intent” statements to clarify what we were trying to achieve. It works a lot like drawing progression; starts off big picture and develops down to the nitty-gritty details like an outline with subheaders. So on the storefront assembly, you might also just identify the sealants, flashings, fasteners, door & hardware, and everything else you detailed on that assembly in one place like Exterior Envelope, Wall Type A, Storefronts, …. (or whatever the division break out is in uniformat… been awhile since I’ve written one). We never fully developed it to a ‘complete’ spec per sea…. We only did this with repeat development teams. So it’s much stronger than a ‘builder set’ but does have a lot of holes if a GC was so inclined to find CO’s. It is just sort of a given that whatever product we listed met our performance requirements and the GC would install per manufacturer requirements; so no reason to list surface prep, performance certifications, raw material blends, etc. Any substitutions would have to be approved anyhow and our front end dumped that analysis onto the GC/sub before sending it to us.

I think it was Miles who said this years ago about agreements/contracts (maybe it was someone else, if so I apologize for not remembering correctly), but it sounds like the effect is some type of "memo of understanding" organized according to UniFormat without getting overloaded with the technical details that might scare away some contractors.

Organizational format may not matter as much as the communication of the intent in language the contractor can easily grasp and understand, but UniFormat is pretty intuitive. I've never had a contractor complain about a PPD in UniFormat even if they aren't intimately familiar with the organization.

I think more important would be the relationship with the contractor as you pointed out. With the right GC I could see this working really well. With the wrong GC who is trying to find the COs ... it would probably be a nightmare.

Looks like I was partially correct about the "memo of understanding" thing for agreements. Carrera was the one who mentioned it, but Miles backed it up and has called it a letter agreement. 

https://archinect.com/forum/th...

https://archinect.com/forum/th...

Apples and oranges, although the structure of the agreement influences how the work is executed and therefore how information is prepared.

This is the kind of shit that kills me. Can't count the no. of times I've received a submittal for a completely different system or product than what was called out in the drawings / specs at bid (often, the GC's answer is 'that's just what the sub. bid in a rush' :eyeball:). But, I'm also usually the Owner or acting as Owner's Agent too, so I hold them to the coals over it (and they can eat the liquidated damages if there's a missed milestone date too). How exhaustive are you guys in clawing back the cost differences when this happens?

double post...

We don't claw this back, at all. Drives me nuts.

We also frequently get contractors ordering $hit (i.e. structural steel!!) before submitting revised shop drawings, and then they beg us to approve later shop drawings because it's already on the way to the site or something. I really want to tell them too bad, not my problem, but that's not being a team player...Ugggghhhhh

Wow - I feel your pain, but facing that top-level indifference / attitude would have me switching firms :/ You've probably pointed this out to your people, but most Owners would be happy to pay for a little extra T&M contract review at the end if it means keeping $100k from the tail-end retainage - just sayin'!

So many people think that just saying AESS will get you what you want ... it won't. So many things that need to be coordinated for it.

Same can be said for "architectural concrete." You can't just call it out that way on a drawing and expect to get something like Tadao Ando's projects.

Did a project where the lead designer wanted to have some lines cast into it that doubled as the control joints. Sure. I figured no problem. Then I got educated by the concrete sub just how they cast concrete slabs and why it was no simple thing to have a bunch of grid lines within a foot of each other that weren't saw cut during cure...

AISC reads as they're farming bitcoin? But I think ASIC.

The concrete discussion is a useful paradigm to view this issue through. Most subs have their own way of doing things so even when we try to do our research and do find out and take the time to understand the AISC/ CSI language and specify a CSC4 wall with exhibits for specific form ties and finish, the sub is like "uh, what does this mean, ya'll want it smooth or rough?"

This. I've also heard they can pick two, but in that case it's always Fast and Cheap.

here . . .

‘Better and cheaper’ is a fallacy. Time = money.

Miles - Agreed. Can't remember the John Ruskin quote, but to paraphrase, "You can always pay more and get something higher quality, but you'll never pay less to get something that functions just as good."

This was super interesting to read, and food for thought about how I might try to look at specs in my office (especially the checklist and builder details parts)

Given your other posts showing the resi projects you do, I'd say your method is clearly working. Still, I don't see how I could replicate it on low-bid k-12 schools

yeah i don't know that it works outside of Japan, tbh. That said it's a system I learned while doing schools and hospitals, so maybe its about the industry as much as anything...? FWIW, we used the same system for low-income housing...in that case we had to make use of a proprietary wall finishing system, so that was simply added to the checklist. I would say that the entire process works better when we are doing large buildings, because the builders are professional. Its the smaller projects where it gets problematic.

It sounds like the differences that allow this sort of approach are more fundamental - cultural, legal and economic. Japanese culture is easily fetishized or stereotyped, but I think pride, specifically in work and craftsmanship, is not a stereotype. Or at least not an incorrect one.

I've done the deep dive into especs and other tools that connect to Revit for information to populate a specification. They all suffer from the same issue: garbage in, garbage out.

You want to use the "I" in the BIM to help automate the specification process? You better make sure that information is near perfect and that everyone touching the model knows what they are doing. That means everyone from the student intern all the way to the old architect that still has to ask IT how to print an email after they sent it to the printer on the other side of the office accidentally 3 or 4 times.

Not to mention no one is paying us to put that much information into the model. At least not until the model becomes the contract document, at which point don't the specifications become obsolete anyway?

This is our issue as well. We do specialty custom work so 75% of our families would have to have someone build them and add in all of the relevant info.

The rest of my post is missing (?)

I was trying to say that, in my experience as a spec writer, there is something to be said for a human doing this work.  Specs aren't static.  Sometimes products are specified in one section and sometimes it is somewhere else.  By that I mean, if I am writing for a mech replacement job where there is 1 hollow metal door with panic hardware, that is going to become a single section that includes HMD, hardware, and finish requirements. There is no reason for such a small part of the work to be 3 sections.  But I sure as hell make sure the drawings say something about providing door, hardware, and painting. If I have another project that includes 10 HMDs all with different hardware requirements, then of course, I'll break it into multiple sections. IMO there is no reason to make it look complicated when its not.

why do your specs become obsolete EA? my experience is that the spec is what you use to hold the contractor's feet to the fire during CA.

curtkram, in this case I was referring to the specs being obsolete when the BIM becomes the contract document. BIM would include both the drawings and the specifications as the modelled content and the associated metadata. Technically not obsolete, but the format of specifications in written pages bound into a project manual would conceivably be obsolete. The contractor and their subs would get all the necessary information from the model rather than needing to read a set of specifications.

Have you read the thread from the beginning? The whole thing is me trying to argue that specs are important for administering and enforcing the contract during construction and that I think we've let the contractor get away with too much for too long and we should all "hold the contractor's feet to the fire during CA" more.

@EA In my current office we use 2 specs being

typed a long response and somehow it's disappeared/ weird ... never mind.

Probably boilerplate, nobody was going to look at it anyway.

@MJ ...whatever that means..

luvu, I'm curious to know what you were going to say.

@luvu, sorry you missed the humor in the metaphor.

I chuckled Miles

And jumping back in... I understand these specs I was talking about would still require custom. But some are "boilerplate" (lol at MJ's pun) that would be in your family groups; gypsum assemblies and accessories, rated assemblies, etc. It's doubtful you change a lot of the basic building blocks with each project and in the case of specific UL rated assemblies, those are pretty much hardspec and wouldn't change without violating the certifications.

mightyaa, I won't disagree. It can be done as you describe using Especs for Revit and BSD SpecLink.

What is the business justification to do it though? If you're addressing basic building blocks that don't change much with each project, and you've put together a set of office master specifications incorporating standard products for those projects ... why do you need some fancy specification software to look at the model and tell you what you already know?

If you're using it to pull specific and variable technical information from the model and populate a specification to match, you'll need to build that information into the model and map it to the specifications. That's a lot of effort to save ... what exactly? The office "spec guy's" salary? You'll still need them to update the specifications and map new connections to the content, etc. They also will still be needed to review the specs and make sure the content is still correct as it comes out of the model. What advantage have you gained with this approach?

I feel like BIM is useful for certain project types & an unwanted pain in all the rest of them. I have 0 interest in modeling projects in 3D during CD's.

I should add, as it seems like I'm against using specification software ... I'm not against using specification software. Like I said, I've done the deep dive on them to figure out if my firm should use one. We use especs, but not with the Revit connection as we don't think it is worth it at this point for the reasons I've discussed above. If we decide we need it to connect to Revit in the future, we can make that adjustment. The software does help speed up the specification writing and editing process without a lot of upfront time investment. Its working well for our firm, YMMV.

i'm guessing the benefit to connecting specs to the revit model is to back-check that you have all the right spec sections included. what i've seen in the past is the PA takes the material keynote list and hands it off to whoever is writing the spec so they know which sections to include. maybe one project is EIFS and brick, the next is alucobond and stucco. linking the revit model could be a useful way of making sure the spec writer is on the same page as the designer, assuming they're different people and they don't communicate well.

You could do that curtkram. The tools will help you (at least I know especs will, I'm assuming BSD will too). Especs points out these two bullets on their website I linked above:

• Run the e-SPECS Validation Report to ensure accuracy between the model and your specs
• See Drawing Reconciliation Reports to get a complete overview of all Revit® elements that resulted in project specification sections

I can't tell you exactly how that might work or look in practice as it will vary on the information contained in the model and the mappings to the specifications ... but I can tell you that if your model content isn't correct or accurate, it's a worthless exercise. 

An example from a few years ago: I was reviewing drawings and specs for an interior fit out for a large corporate client once. The drawings hadn't called out for a rated partition where I thought we might need one. On the off chance that someone in Revit was paying attention, I decided to look at the properties in Revit for that partition. It was modeled as shaftwall. We didn't need shaftwall here, but maybe the modeler used it because it had a rating. I checked the properties for any rating ... none. Hmm. Maybe this one partition was a fluke. I clicked on another and checked the properties ... also shaftwall. So I clicked on another ... also shaftwall. 

Every partition on the entire floor plate was modeled as shaftwall. Did anyone in the model even know they were using shaftwall everywhere? No. All they saw was two lines in plan representing a partition. The information didn't matter to them, only what was going to get printed on the final sheet mattered.

So did I want to rely on the accuracy of anything coming from that model in some type of report to validate or double-check what was in the specification? Absolutely not. 

the hardest part trying to implement something like that is managing expectations. it's software, so it's not smart enough to know or understand what you want it to do. a lot of people end up frustrated that it doesn't do what they expect it to do instead of what it actually does. in the end you will still need someone who knows what they're looking at and can do it the old fashioned way.

That's exactly right. The software will do exactly what they say it will do ... but it's still garbage in, garbage out. The software won't magically make your documents better. You have to put in the effort to train and educate your staff. If you're not going to invest that time and effort, don't bother investing in the software. That's how you should be managing your expectations here, the first step is to take a hard look at your models and determine whether the information is accurate and usable, and then decide what it would take to get it there if it's not.

After you’ve baked a couple of cakes you don’t need to look at the recipe ...

In this bakery, every cake is unique

@EA The issue that we always have is that the builder always want to change our "recipe". Materials substitution is a common practice and we have to find the right balance to navigate through this. At the end of the day it's the clients building and you always have hope that they will have your back throughout the build process.

Back to you original topic , I've never come across any builder that wouldnt read  our specs / on the contrary , they would try their hardest to twist/change what we want into something that makes them more profitable .

I've had something similar. PM that doesn't want to use hardware sets in the door hardware section, but has it listed on the door schedule with individual columns for every single piece of door hardware. Add the complexity that we often have more than one type of handle or lockset, and it becomes utter bedlam. In theory, it is a decent idea, if the project only has 10 or fewer doors. When we get to projects with 100+ doors, I want to jump out a window.

The definition of "better cake" often varies between architect, client, and builder. The architect wants it to be a better cake. The client wants a better cake at a cheap cake price. The builder wants it to look like a better cake but make it as cheaply as possible.

Miles, but what if the baker has already made several shitty cakes?

Walmart shoppers like cheap cake.

...but the client gets the cake specified in the legal tender docs regardless of the contractor's reading skills. 

I don't get how y'all get jerked this way by GCs. If it's in the bid docs and not buried in some obscure way, that cake is getting baked and frosted (with extra sprinkles) the way I asked. Might not be the same cake the GCs did 10 times before, and I don't care. Those were not my clients' cake then, but it is their cake now, so follow my recipe or you'll be forced to bake more than one cake on your dime.

The real issue isn't that the contractor won't read the recipe (they will if they have/we force them to regardless of what their preference is), it's that the architect never learned how recipes work and so they can't be bothered to read, write, or otherwise look at them. They come to me saying it's an issue with the contractor so they can deflect from their own incompetence.

The PM in my example isn't really afraid the contractor won't reference the specs ... the PM is afraid of the specifications and is using the contractor as an excuse.

Ah, then your problem is that you have too many chefs writing parts of your recipe book... in different languages, and some are still using crayons.

It doesn't help that in chef school there was only a small portion of the curriculum devoted to recipes ... really just enough to satisfy the accreditation team. The vast majority of the training was on the presentation of the food regardless of how it tasted. It was all about fondant for the cakes and various techniques to plate the food.

I fucking hate fondant... worse thing to happen to cakes since they started hiding carrots with cream-cheese frosting... and walnuts.

Yeah, but the problem with the recipe, is that generally speaking, no one cares who makes the flour, all that anyone cares about is the type, and quantity.

Canadian bakeries care more about the cake. In the US it's all about the frosting.

@NS ... but the client gets the cake specified in the legal tender docs regardless of the contractor's reading skills.

I'm not sure I'm following your question here square. I'll throw this out in hopes it answers your question, but I'm not entirely sure of what you're asking...

I think specifications will always be a part of communicating the design to the contractors. That may not always be in the form of a 3-part specification in a separate project manual, but it will always be a part of delivering a project. Even "putting things on the drawings" is a form of specification ... just not a very good one when you get into any complexity.

Maybe in the future everything is in the BIM. Maybe it is pulled away from architects' services and becomes the services of some other player involved in the project. Maybe we ditch MasterFormat and move to UniFormat. Maybe we just reference industry organizations and standards rather than trying to spell some things out in more detail. But at sometime during the project delivery process, somebody needs to communicate the contract requirements for materials, equipment, systems, standards and workmanship to the contractor. If not, we simply let the contractor do whatever they want.

Is there a way to do all this without endless minutia and paper pushing ... I think so, but it starts with architects taking specifications seriously and that's proving more difficult that I expected it to be in the profession. We've gotten too comfortable with only drawing pretty pictures and ignoring the important technical and performance aspects of our work.

yes, good answer for an abstract question. lots of food for thought.

A large part of the problem is a system where competing interests are at odds with each other. Design/build helps simplify the process and minimize those conflicts.

Huh, square. Not sure how your firm does things. But, drawings show location and quantity. Specifications show what and how to install. I know for small jobs it feels like mumble jumbo. But when you have a dirty public bid GC, the detailed requirements in the spec is your last line of defense that holds them responsible. Got a GC tried to get out of preparing the shitty poured concrete slab. If it wasn't the floor finish spec's 1/8" per 10' max sub surface requirement, the slab will end up a ski ramp. However, we also have developer clients with their partner contractor. No spec book, just sheet specs, not even much CA work because the developer wants to reduce fees. At the end of the day, it is all about how much you trust the GC. The spec is your contract. If it is a design build, I bet even the drawings and details can slack provided the GC is good.

If architects actually knew more about specs they wouldn't be afraid to use them the way they are intended. I tell people in my office to think of specs how they think about drawings. If you don't care what it looks like, you don't draw it, or at least not to 1:1 scale. Same with specs. The more you care about it, the more detail you need. If it is not of a major importance to the project, use a shortform section. This would require architects to know what that is, and unfortunately most don't even know its an option.

jay- not asking what a spec is, or how they are used today.... more of a hypothetical if anyone can imagine the possibility of not needing them in some way. just remember, they weren't always around. i certainly fall into this as well, but i think often we're so embedded in the way things are today that it's hard or nearly impossible to imagine that it could be different, and standards today aren't necessarily inevitable or immutable.

i think ea's suggestion about bim is an interesting one; maybe eventually revit is actually smart in some way and automation can begin to work around some of these more "manual" and laborious methods of instruction writing. like miles said design build also seems to serve as a work around, but i'm less familiar with that method.

I think what Miles is saying re: design-build works at smaller scales, but it gets messy when you get to larger and larger projects. On smaller design-build work the designer and builder can usually be the same person/entity/company and those competing interests naturally get sorted out in house or within the design-builder's head ... "Gee, I'd really like that tile, but I know I don't have the budget for it and I've actually been pretty pleased with the quality and finish of this cheaper tile so I'm going to go with that and adjust some of the other finishes around it to work with it."

On larger design-build projects where the owner hires the builder/GC, who then hires the designer/architect separately the same competing interests always seem to come up. The owner still wants everything faster, cheaper, nicer; the GC still wants everything cheaper and doesn't really care about the design because they don't understand it; the designer still wants to have everything look great so it will get published in Arch Record and can't be bothered to consider a budget that they never helped to establish before the design was really even started, nor do they know where they can best save the money for other more important things and there isn't the time in the schedule to have those conversations with the builder; the consultants still won't coordinate with others and try to avoid anything unique or interesting; and the subcontractors still just want to do what they've always done.

Integrated Project Delivery (IPD) was supposed to be the thing that solved all those issues but I've yet to see a project that I would truly consider IPD. Owners, contractors, and architects all say they like IPD up until it is time to sign on the dotted line and tie their potential reward to the risk of everyone else at the table.

At best you get IPD-lite which is just a fancy way of saying you have a GC/CMc who is contracted for some preconstruction services (i.e. constructability review and/or value engineering services) and everyone still talks like they are all part of the same team but don't act like it in any way when there is even the slightest hiccup in the process.

ha, ipd! forgot about that one.. does seem like that's died off a bit, or at least has under-delivered like you say.

There will never be a time when all of the information needed to construct a building can be shown on the drawings that the trades are working from in the field. If the day ever comes when BIM files replace paper (or PDF) as the Contract Documents, then the spec information could conceivably be included as metadata in the BIM file, but the information would still need to be in the documents, and someone would still be responsible for making sure it's correct.

(FWIW, there is already 3rd party software to link specs to a BIM model, but they all still require separate apps for the BIM, the specs, and the 3rd party app to link them - conceptually all of that could be rolled into the BIM software, but I'm unaware of anyone actually pursuing that.)

@atelier It's already happened (BIM as a contract document) down the production line of building procurement. I'm working on a 20,000 sqm Mass Engineered Timber bld where the CLT manufacturer we are dealing with wont turn the CNC machine on until they've received a millimeter perfect 3D file of the building, which is a redrawn version of our Revit model using a timber design software ( sorry forgot the name).

One of the reasons I left architecture was the paper pushing. I'm not interested in playing CYA and papering the file. I despise bean counters who think that saving a penny by creating mountains of work for others justifies their existence and can't abide municipal officials who anwser the same question differently every time. ARBs chaired by bored housewives, underpaid building inspectors looking for handouts, clients who have lawyers 'solve' the simplest problems, screw that.

 I make things, that's what makes me happy.

i feel the same miles, it's just wild how inundated arch and building in general is with all this stuff. i feel so alienated from buildings, let alone the people the use them, that some days i don't even know what i'm working on anymore.