I’m surprised that I have to make a new thread for this, but I’ve searched and searched here and can’t find much on the current efforts to integrate specs production with BIM. So I apologize if this is a tired old ‘been there–done that’ topic.
We’re proceeding with a pilot project, without anything substantial to report yet, on using eSpecs Linx for Revit. It seems that Arcom/InterSpec has the only game in the Revit town, but I don’t find much [any] comment on what I would expect is a common situation: firms dabbling in this area of spec automation. Either my expectation is wrong, or more hopefully, this is progressing without a lot of muss and fuss.
When an informal survey of current specs software was conducted on this forum in March of 07, this was briefly mentioned in one post. I’m guessing in this overheated BIM environment that there’s more going on today.
Hopefully we can share some learning experiences [painful or otherwise] and avoid some as well.
Is anyone else out there using or developing specs-BIM integrating software?
We are evaluating the eSpecs product, but without the Revit link at this time. My view is that the product must be a good, usable tool to produce specs by itself. Linking to drawings and models may feed some data into the specifications documents, but if the usefulness of the basic product is not good, then it won’t matter how well it integrates with models.
I’ve done limited work with it so far. The back end (where final edits are done in a word processing like environment) is not good, but they have just released a reportedly substantial upgrade which I have not installed yet. On the front end, the accuracy of the links is reasonable, but not as robust as I’d like.
in a recent survey of about 20 firms, I found that none of the large firms is pursuing drawing/spec integration because the software just isn’t there yet for that to happen. if I were to attempt it with our software (Digital Project) it could integrate the spec, but only in a PDF form.
since the models we produce are too large to open completely anyway (one of our models is 17 gigs) adding more information to the model just makes it less useable.
I think integration will happen, but its at least five years out, and may be closer to 10 years out. remember that only the general contractor and maybe the larger subs are going to be able to access the model – the guys building the project will be looking at paper just like they always did.
I’d be happy with a simple report that listed everything in a project, once. Full-time specifiers can handle a lot of information, but they have to have it to handle it. Even after interviews and going through drawings a page at a time, an item that shows up only once can be missed. And then there are the things that get added late in the project…
The reports will be limited by the granularity of your BIM model. Does your bim model include the vapor barrier under your concrete slabs on grade? What of the admixtures in your concrete?
BIM won’t include everything, at least not at the moment. Concrete is a bad example; it usually exists in sufficient quantity that you can’t miss it.
I’m more concerned about the one markerboard that appears on only one page, or the things that get added without my knowledge. If I know the project has concrete, I can get the information to decide if I need a vapor retarder.
If I know we have a marker board I can ask what the designer had in mind, but if the marker board in added in a single detail and I don’t know it’s there, it may not get specified.
An important thing to remember is that the input has to be right for the output to be meaningful. For example, many people working on the drawings do not understand the difference between a vapor barrier and a vapor retarder. It’s one thing if it is a note on a detail or a keynote that I check through as I work off the drawings to prepare the specs; it becomes a new kind of problem if the building model thinks it is something it shouldn’t be.
I agree with Richard, and I worry about Sheldon’s idea at this stage of our game. I’m very eager to get the information out of the model in a useful way, but the more I see of how architects use the model the less I trust their understanding of what they’re asking for. If I’m looking at a list, I still don’t know whether the Owner or the Contractor is supplying the one markerboard, and I can’t see that the waterproofing is really a roofing membrane because the drafter doesn’t know the difference.
On the other hand, I’m really interested in the day when the specs are a set of linked chunks of text that can be accessed from the model or from other parts of the specs. Just as the one markerboard in the drawings is a needle in a haystack, so are the important spec provisions (say, that it needs to be fabricated without urea formaldehyde?) buried in the specs. I’ve heard of firms who hyperlink their specs, but this is way too much work from a dumb-text world. I hope to be part of smarter more accessible text linked to smarter models. I just don’t know how we’re going to get there. Til then, I just keep saying it once in the right place and hoping someone knows how to find it once, also in the right place.
I am interested in comments from those involved in projects using BIM. What are the formats and level of detail for specifications at Design Development, Plancheck, Bidding and Construction for a project using BIM?
I am concerned that the indescriminate use of manufacturers’ BIM blocks embedds proprietary requirements in the database which has a way of making its way into the specifications. This may or may not be helpful depending on your point of view. I believe that CAD processes used to develop BIM models force earlier decision making on the part of designers which most people would view as a good thing. I believe, however, that the data being embedded in the BIM model may be less, rather than more, generic.
Moreover, I would suggest that the decision to use a particular product may be based on the availability of BIM blocks rather than a thoughtful evaluation of the produce in relation to the particular needs of the project and the value this particular product contributes to the project. This value may be based on visual quality; i.e., blocks readily available from one manufacturer who turns out to provide fewer options in terms of colors/textures as well as blocks readily available from another manufacturer who turns out to offer (1) more expensive products, (2) no available installers, (3) less desirable warranty protection, (4) all of the above.
CAD jockies (and their kissin’ kin, the Reviteers) are seldom in a position to have any sort of real understanding of the implications of their decisions. The implications may become larger and more complex as the project develops with certain decisions based on availability of BIM blocks forcing the acceptance of unwanted parameters later in the design and documentation process.
I think Peter’s concern is more firm-related than BIM related – most of the firms I’ve worked with discourage the direct use of manufacturer’s CAD and/or BIM blocks without having them edited for content. the idea of selecting products based on the availability of BIM blocks isn’t any more professional than using producs based on the manufacturer having a spec – and then using it unedited.
Be that as it may…the 3D models are making headway in the industry, but its still an issue of Modeling saving money for the contractor and driving costs up for the architect, so its a business decision that seems to be not adequately compensated at the design side.
Earlier decisions are desirable when they allow subsequent stages to proceed quicker.
On the other hand there is often an expectation that the BIM model show a certain level of detail. This can put pressure on the consultants to show more detail than is justified to meet that expectaion. This in turn results in spending more time modifying the BIM model.
None of my clients are into BIM yet, so I am not speaking from any personal project experience but I have been involved a lot of “BIM discussion.” A few comments:
I hear and read a great deal on the topic of BIM and specifications that treats “product information” as equal to “specifications.” I see very little that includes the comprehensive subject of specifications and BIM.
In regard to Peter’s comment above: I would like to see ideas how you deal with the different types of specification information as you go through the design process in contrast to just inserting proprietary information on one product early in the process:
Performance criteria for functional elements (systems and assemblies).
Evaluation of multiple construction solutions for the functional elements (value engineering).
Selection of construction solution for each functional element.
Specification of components of functional elements for procurement/buyout (multiple products if proprietary).
Inclusion of information on product to actually be installed (may be different from product that was used during design analysis). When and who does this - information not known until during submittal process during construction.
Inclusion of maintenance and operation on the product installed. Historically provided by contractor - under BIM, who puts the information in the model?
In other words some ideas of how you deal with the progression of “specification type information” in the design/construction process, not just using product information in the early design process to do analysis of the total model.
We have recently implemented using e-SPECS with our already established use of Revit and I’m happy to report that, so far, communication between Reviteers and Specifiers has vastly improved. The way the system is set up, the Reviteers identify the assemblies they are using based on UniFormat-based ‘Assembly Codes’ which are inherent in Revit. The Specifier, through e-SPECS, then binds specific Spec Sections to each of the assemblies. This generates the list of available keynotes. In other words, assembly components cannot be keynoted without direct input from the Specifier!
We’re just in DD on my current project but have generated meaningful, accurate content. Time saving in production has allowed me to spend more time collaborating with the Architects in working out systems, details, and holistic continuity. Reminds me of the old ad “Not more tea; more tea flavor”. The value added by the Specifier is much more meaningful and much less reactionary than previous methodology since the project cannot proceed without the Specifier’s direct involvement.
Of course there was a learning curve but now that I’m up and running this seems to have the potential to be a very useful tool. I’ll try to keep you posted as we proceed.
We had one client attempt to use e-SPECS on two different projects with two different design teams a hospital addition and a new corporate headquarters. We were the only common participants for both projects. After generating the first draft of the specs, our client abandoned e-SPECS for both projects for the same reasons.
We found that we were constantly asking the designers to insert elements into the model so the model would generate the request for all the spec sections we intuitively knew would be needed for the project. These requests turned into burdens on the design team. They did not want to spend time inserting detail into the model during DD phase. Perhaps we spoiled our clients because we always create a table of contents, often with our proposal. So they do not understand why the model must generate requests for spec sections that we already know are required.
I see Project Description as the more valuable link between the model and the specifications. I purposely refuse to call it a Preliminary Project Description as CSI does because we maintain the description throughout the design process, updating the description for each design submittal. We generate the Project Description based on UniFormat using the same number assignments as the Revit model. The UniFormat number association then becomes the link joining the model, the description, and ultimately the spec.
I believe that directly linking the model to specifications will be difficult because the design process is iterative. Asking designers to know the exact composition of a wall during early design stages is unreasonable. The designers can distinguish between interior and exterior walls, which may be all that is required to link the model to the Project Description.
We just finished our DD set. As anticipated, there was quite a bit of learning curve involved as well as inherent positives and ‘issues’.
We found that modeling a large amount of information during DD made sense for our structural and architectural teams, not just for the purpose of coordinating with specifications but for communicating within the team.
Realistically, there will be numerous items that will never be modeled, even when we complete CDs. By the same account, we found that based on the laws of diminishing returns (econ 101), there came a point during DD when we were no longer benefitting from ‘binding’ specs to the UniFormat Assembly Codes within Revit. For the sake of speed, accuracy, and economy, we chose instead to allow the specifier (me) to populate the keynote.txt file with the proper keynotes. Close, ongoing communication with the architectural and structural teams was essential. The TOC is now based on the keynote list (and vice versa). With that said, there is no reason to go back and use the Binding Manager that I can tell.
There were IT glitches encountered that we have yet to figure out. No idea what caused the glitches, but I did have the epiphany that all work can be done in e-SPECS without having to export, publish, or otherwise convert my content to some other means for editing. I converted my documents directly to pdf from e-SPECS and was ready to send the project to the printer much faster than expected (once I caught on). Editing within the database was easy in some ways, a major pain in others. Time was not a friend when having to retrieve deleted or altered information in the world of tight deadlines. You need to know how your spec should read and go for it. Don’t worry about ‘Saving’ the files and losing the ability to edit spec content based on the model. That part of the process is a nice thing to have, but expect to do most of your editing the old fashioned way, one line at a time.
Believe me, no one but spec writers want to deal with this. You almost need to understand keynoting more than specifying to be useful to your team initially, but from there you are still generating good old spec content regardless of spec master. Nothing is automatic. This process does not replace the specifier, it makes our role more important than ever.
For me, database editing is a lot easier than using a certain word processing software that will remain nameless.
We use a filterable Excel template that is a master keynote list, with a yes/no/maybe column that the specifier and project architect develop together early in the life of each project to track what is in or out. With a few VB filter buttons the list can be shrunk down by section title only for quick 1st pass, and also by yes/maybe only, or full list. Another set of buttons exports to ADT and Revit formats *.prn or *.txt.
This way the design team and specifier work closely but they do not get stuck waiting for us or vice versa. Then we have a concise listing of what is anticipated in the project to finish writing our specs by.
Christopher,
Are you willing to share your template?
Ken,
Where are you now on adoption of e-specs?
We are preparing to test pilot the program and I hope to learn from the past.
Thank you.