The Future of Specifications

Archive of Older Topics Archive - Specifications Discussions #5
21

In my experience, “automated specification systems” will make the tasks of product identification, evaluation, and selection easier for an experienced specifier (which includes architects who may not do this full-time, but have the responsibility on their projects. These systems also greatly facilitate the production of the specification documents themselves.

None of these products are “specs for dummies” (not my quote, but a good observation nonetheless). You still have to know that sand if fine aggregate, that concrete, mortar, grout, and cement plaster are essentially the same product, and that such products will usually shrink during the curing process. You also have to know the difference between “glazed CMU” and structural glazed tile units as well as the difference between face brick and paver brick. These are all relatively trivial bits of knowledge (TBK) that can become critically important if one does not understand how that TBK can affect a particular part of a project and perhsps cause a failure of a critical system.

The automated spec systems out there provide the right buttons to do the research necessary to find out how these issues might be important. Of course, after practicing for 20 or 30 years, some of those TBK kinda stick in there and you don’t need those particular buttons. There are, however, always more stuff that will require you to press the buttons.

It has become more common for people to bypass the research/evaluation/selection steps in the design process before it even gets to the spec writer. I have had to tell designers that they could not use something that had already been accepted as a part of the design by the Owner because it was in some way inappropriate.

The Reviteers make the same mistake that the CAD monkeys have made for the last 20 years; skill with a software program is mistaken for real design skill (off course we had that before with the guys that could draw circles around the rest of us, but did not really understand what they were drawing).

I like that idea that has been proposed by a number of people that the traditional “spec writer” has usually been a knowledge manager and a keeper of the flame of corporate technical memory). The loss of that position in mid-size firms is a real blow to the firm’s knowledge base since that person usually “touches” every project.

There is an old computer maxim: GIGO (garbage in; garbage out). The corollary in the CAD/BIM world is that if you have a mess, automated systems will automatically generate a bigger mess faster. Someone has to ensure that the system inputs are not garbage. On a large project, this is not a task you want to delegate to someone two years out of school just because they understand the software.

22

What are comments of those who attended the Orange County CSI presentation of past, present and future specifications?

23

Scot’s “Specialization in any profession can lead to unstability in terms of job security” The process you suggest is great for a small firm, but is tough to pull off in a large firm. You need to know a lot about everything to produce good specifications in a large firm.

We all specialize. The question is do you specialize vertically or horizontally; a small firm that sticks to residential for instance, or a large firm that serves multiple commercial, industrial and institurional work. Recently both took a tumble and both specialists and generalists were hit. If you are in the construction industry, there is little long term job security just by the mere nature of capital projects. Both you and your firm need to be needed.

24

I completely agree with Richard Hird. It would be much more difficult in a large firm to minimize specialization. However I was responding to the observation made by Richard Howard that contended that full time spec writers suffer layoffs in greater numbers (% wise) than others in the field.

It would be very difficult to diversify your talents in a large firm (one reason why I have prefered to work for small to mid-size firms) but i still believe it would be advisable to try and develop a well rounded set of talents and contributions for your firm.

25

I recently heard of a CSI Forecast/Study that was done in the mid-1980’s that forecast that within 30 years, specification writers and construction administrators would begin to greatly decline in numbers (near extinction). I would like to see the study and what it actually forecast - is anyone familiar with this or know of a location where it can be viewed (ideally online)?

26

There was a seminal study done by CSI and the Stanford Research Institute in 1967, titled “Survey of current practice in the use of automated techniques for specifications and detailing practices: a research study” by Charles E. Diehl. Ken Crocco referred to this in his presentation I mentioned in my 9/21/12 post above.

The Rosen/Kalin/Regener specifications book also makes reference to this document, so perhaps Mark or John know of a source. I don’t know that you can find it online.

27

So this “seminal study” is 47 years old (about as old as MasterFormat) and the mid-80’s forecast of decline within 30 years is about 30 years old…

I was in in architecture school in 1968 when Paul Ehrlich, a famous professor on campus, wrote the book “The Population Bomb” predicting worldwide starvation due to the population explosion in the 1970s. Didn’t happen.

28

The Stanford study was seminal in the sense that it set the guidelines for CSI’s development of SpecText and was a precursor of the other automated systems that followed. And that mid-80s forecast was prescient enough, if you believe the ratio of specifiers to others dropped from 1:20 to 1:100 between then and now. Those numbers seem to paint a fairly accurate picture of what happened.

It’s hard to get predictions correct, and I’ll admit to being gullible when someone smarter than I makes a educated sounding prediction. I’m still waiting for my flying car…

29

I would think the future of specifications is tied into embedded smart objects in a three dimensional drawing model.
For example… Click on a WALL and it would first give you the choice of:

  • structure (metal stud or wood (stud or post) framing or masonry, etc.),
  • then sheeting (GWB or wood paneling or FRP or…),
  • then choice of finish (paint or manufacturer’s prefinish selection and color-texture).

Someone with experience (a specifier along with and overseeing many product manufacturer technical representatives) needs to populate the smart choices in the model for the project designer / architect to select.
Included in the smart tags are detailed product specification information.

Traditional specifications will focus more on the process of how the building is constructed and shift how construction products are defined and interface to BIM.

That is where I foresee the profession moving towards.

30

Robert,

Where I don’t find a problem with your point about old studies, but the analogy to the population bomb and worldwide starvation is not the best example.

It was during the late 60s, at the time everyone was concerned and writing about the coming population explosion and the fact that food yields were not increasing that one man, James Borlaug, created from cross breading different strains or wheat the high yield disease resistant semi-dwarf wheat. This was happening as the work of one man at the same time the starvation forecasts were being made.

Its first use was in Mexico, and yields soared. This was followed by India and Pakistan. We are talking essentially doubling the output.

In 1970 he was awarded the Nobel Peace Prize for this, for specifically avoiding world famine.

The specifier’s failure to disappear as predicted is just a bad prediction. There was no math, not statistics, just assumptions.

The famine/population bomb was a totally valid analysis, factually supported, not even a prediction. It was avoided by a timely ‘invention’.

There are other issues associated with this particular wheat, but that’s a different story.

31

I am concerned about the scenario that Jonathan suggests. I agree that if sufficient time, expertise and oversight is involved you could include all required information into smart tags. However, I am afraid that the BIM model will fail to address specific and potentially crucial information. Will the smart tags be as “smart” as they need to be? I may just be “to long in the tooth” for this next step as the profession moves forward but I have concerns about the individual producing the model even knowing what is needed to make the tag smart.

Years ago I was putting together information so my boss could do a simple spec for a masonry wall and I asked my coworker about the through-wall flashing. His response to me was: “you don’t need to spec that, I already called it out on the drawings” I asked: “Okay. What type of flashing did you call out”. He looked at me with a puzzled look and said: “through-wall”.

32

Scott, what Jonathan is suggesting that the model be the source that is connected. One point I would like to make is that as long as specifiers continue on the same path as they are (using the same process that they currently use) that study may be prophetic. Using new tools and thinking of more concise ways to get the contractors to even look at the specs. Ask Jerome. The clients are asking to eliminate the specs. In other words, they want it on the drawings. I personally have had 3 projects in my career that they requested that very thing.

Your example is not a good example. There are many uneducated interns today doing the documents and little to no oversight or QA/QC process to catch these kind of errors. There are very few firms out there doing technical research. They instead are researching things of the design. Until quality of their instruments of srevice becomes a main issue they will continue down that path of minimizing their roles. Same holds true for the specifiers.

The future of specs follows the same path as the future architects. In the words of Thom Mayne, “Change or die.” Many times I hear the discussion that the architectural profession is dying. As architects continue to hide from risk instead of managing it, that may be prophetic. When they accept and manage the risk then the importance of the specifications will rise.

The future of specifications means just that. The future. Typically the future requires change and so far there is little to no change in the processes. Specs today are being done pretty much the same way as they were done 30-50 years ago.

All of this is in my humble opinion.

33

Regarding specifications and BIM, this is something I’ve been discussing with others for over a year now.

Contrary to the advice of author R.L.Trask*, I’m going to use a buzzword that is considered verboten: the world of specifications is rapidly approaching a “paradigm shift.” The era of bound paper specifications is coming to a close right behind the bound set of drawings, which has a slight lead.

As the world of BIM expands, the integration of specification-type information into a model is almost a given. The problem is that nobody knows how this specification-type information should be entered, stored, and retrieved.

CSI is poised to be the one (and only!) organization that has the expertise to tackle this behemoth task. I say “behemoth” because the problem is so nebulous that it will be a major task just to lay the foundation for beginning such an endeavor.

The problem we face now with BIM is not much unlike the one CSI members faced in the 1960s when developing MasterFormat, SectionFormat, and PageFormat. The only difference between now and then is the medium for the specification information.

For the nearly 67 years of CSI’s existence and further back, the medium for specifications has been a sheet of paper roughly 8-1/2 by 11 inches in size. The technology that helped us specify on those small sheets have changed significantly over the years, but we’re still producing specifications on letter-sized paper. The problem that faced those CSI members back then was how to organize the information in the manual and on the sheet.

The problem facing us with BIM adds an entirely new dimension to specifications–linking that specification information to BIM objects. Storing specification information in a database is nothing new, but current specification databases are tied to the old specification paradigm (sorry, that word again).

A Building Information Standards Task Team was established a couple of years ago and determined that OmniClass was the best tool for organizing specification information in BIM. That’s fine, it’s a start, but it didn’t go far enough. Selecting a organizational tool that is concealed behind a software platform is like running electrical power to and through a building, but not providing any convenience outlets to allow people to plug in and use it.

CSI must grab a hold of this opportunity before the software companies take it upon themselves to develop it and force feed it to us. And, most likely, each company will do it in their own format without any consistency in structure between them.

Sorry for the length. You’ll be hearing more about this from me in the future.

*Mind the Gaffe, 2001

34

Great post Ron.

However (I say with tongue in cheek) according to every e-mail I receieve from one of the leading providers of construction specification software, they has solved this delema. Helping project architects author the spec manual fully coordinated with the BIM models throughout the entire design process.

How come everyone in my reqion does not “know how this specification-type information should be entered, stored, and retrieved.”

My goal for fiscal year 2015 is to figure this all out.

I look forward to your future posts. I need all the help I can get.

Wayne

35

Alan; I agree with what you are saying and I understand the intent of making the “model be the source of the connection”. I was just trying to say that I am concerned about the goods and services of the architect while this process is being implemented.

When CAD drafting first appeared many of the early efforts included drawings that lacked the information that hand drawn plans did. As the programs improved and (more importantly) as architects got a better handle on the use of the programs the “product” improved. I foresee a similar slip in the area of specifications as this new “paradigm shift” (apologizes to Richard for plagiarizing his point) is implemented.

I completely agree that we must change the way we produce our goods and services. I am not fighting that change but I remain; concerned. I apologize if I made is sound like I am fighting for the status quo.

36

I suspect that one problem with linking information to BIM objects is the same problem we started experiencing in the early 90’s when drawings started happening entirely in CAD. At that time, the experienced architects, who mostly did not work in CAD, could no longer see the drawings until the drafters printed them out, so their ability to walk around and look over shoulders was reduced. It took a long time to adjust, and then BIM came along and more adjustment had to happen. A lot of firms never got really good at supervising the drawings and mentoring the people drawing them, once the paper came off the drafting boards. Supervision has yet to experience its own “paradigm shift”, in my observation; it’s just gotten difficult and poorly executed.

In the same way, linking the spec information to the BIM objects offers the opportunity for the information to be hidden in the BIM, unless we’re very clear and careful about how it’s cataloged and reviewed. Since we’ve already established, in others’ posts, that the people drawing don’t always know what information should go along with the drawing, this hidden information can easily be incorrect or uncoordinated. We need some really good practices for supervising staff and coordinating digital information if our BIM-based spec information is going to work in the real world.

37

Good point, Vivian.

I envision specification writing for BIM to be very similar to the way contractors and estimators do scheduling and estimating, respectively, for BIM–they use a third-party application that can read the model and allow the attachment of additional data to the objects.

Thus, with my Spec-o-matic Version 1.0 (to modify John Regener’s product), the software would allow the specifier to interface with the model, review the ‘preliminary’ selections that were made and revise as needed, and insert the additional requirements/data that only a specifier can add. The specification data may be directly imbedded in the model or could be a separate database linked to the model.

The data entry may be via text fields, dropdowns, checkboxes, etc. based on what is being specified. The format may loosely follow SectionFormat, and the content will be heavily streamlined (i.e. Subject: Data/requirement).

This is just my current image of BIM specifying, which is coming from a complete BIM novice, but one who understands databases to some degree.

38

“the content will be heavily streamlined (i.e. Subject: Data/requirement)”

That’s the way specs should be written anyway; it provides a convenient checklist that makes it easier for bidders and for CA when the submittals arrive. If you look at a section using that simple format, you’ll see that it won’t be difficult to translate it to the properties table of an object.

One of the problems is describing properties in a way that allows competitive bidding, assuming that’s what you want. The danger of simply plugging in manufacturers’ properties is that they have a tendency toward sole-sourcing.

39

Sheldon, to a great extent, yes, specifications should be using the streamlined method.

I’m thinking that it could even be more so to the point that the data/requirement part will be very succinct–possibly breaking what may have previously been written in a single paragraph into several ‘streamlined’ phrases. This makes it easier to work with a relational database.

40

Yep.