Whether BIM will live up to its promises in the near future is still open to debate. The process of adopting BIM is something that we have to deal with now. The big challanges have to deal with defining the working relationships between the various parties, defining expectations of what is delivered technically, and how this impacts the work load on individuals. I believe that we will find that a number of otherwise productive individuals will not be able to make the transition to BIM and will be displaced.
Those who remember the transition to CAD will probably see a number of similarities.
The question is how do we survive the bleeding edge.
I attended a BIM seminar in December 2005 where Francois Grobler, Research Engineer, IAI Technical Coordinator, US Army Corps of Engineers spoke. The room was full of prominent agency officials and A/E community representatives. I had snuck in since I was a speaker at another session on the mundane subject of construction specifications. Mr. Grobler asked, “What is the BIM?” Several answers were given and it quickly became apparent that there was diversity in understanding of what was the BIM. Yielding to my smart-ass tendencies, I quipped, “It’s an elephant.” That is, it is like the story of blind men describing an elephant. To one who encountered a leg, the elephant was like a tree trunk. To the one who found its side, it was like a giant wall. To the one who found an ear, it was flat and wrinkled, like parchmant. To the one grasping the trunk, it was long and flexible like a snake. Mr. Grobler commented, “That’s right.”
BIM seems to be what one wants it to be, and that’s determined by how one interfaces with it.
So, does anyone have a complete understanding of what is the BIM? When we talk about the BIM are we talking about the same thing? I’m concerned that there is an elephant about to be loosed on the construction industry, called the BIM. As in India, the elephant can be a most useful, intelligent beast who enables men to do work more productively. I’m concerned that without proper management and control, the BIM elephant could be getting loosed in the china shop of the construction industry which is ill-prepared to deal with it. The consequences could be very messy.
I don’t think we can reach consensus understanding of BIM until
we realize that true design team collaboration is at the heart of it;
we read case studies of successful projects to see how they worked; and
learn to use collaboration tools we already have but seldom use, such as UniFormat. I don’t think we can learn to work in a BIM framework if we don’t know how to classify project criteria in terms of performance values in uniform terminology.
Regarding collaboration, as much as we want to be included in early design stage activities, many of us in small firms have had to develop working skills for getting things done on our own. Collaboration skills atrophy in these circumstances.
A lot of what is written about BIM does more to define what it is not rather than what it is. I found a few good resources online that helped me acquire a better, but still vague understanding of it.
First, I suggest reading the Wikipedia entry on BIM and following the links to Jerry Laiserin’s website. Next, read the case study in the December 06 CS written by Alberto Cavallero, AIA, titled “Comprehensive BIM Collaboration: Integrating A/E/C Implementation for Building Information Modeling.” Case studies give me more information than theory pieces, although theory peices are important and should continue to be developed. Finally, Roger Grant published an article titled “Unifying Global Building Information” in the January 2007 CS. These resources have helped me a great deal. I hope they work for you as well.
What I’m seeing in my current office is that using 3D modeling puts the architect back in the “adult” position in the project team. The contractor is using OUR information to generate pricing – not his interpretation of our information – and that means that we have to be responsible for the veracity and coordination of that information. We provide the drawings that are used for fabrication and do the quantity take-offs (or rather the program does it). Do we still have disputes with contractors – of course.
it does mean that our internal process has to be more rigorous but what I’m seeing is that the architect is back at the table again as a full participant instead of being on the defensive.
The recently concluded CSI SHOW (& convention) was obsessed with BIM. Rightly or wrongly, it was topic No. 1 in the education sessions … or at least in the education tracks I was interested in: specifications and contract documents.
I’m interested in reading what others thought of the presentations. How shall we respond to the clarion call, “The BIM is coming! The BIM is coming!”
Since so many firms have taken the initiative to embark on the BIM path, and many owners are now mandating it, I’d say its already here. Sure, there is a long learning curve and some bugs to work out (much the same as there was with CAD), but that does not seem to have stopped those who wish to remain on the cutting edge as leaders in the industry.
I was struck by the strong indication of linkage between revised/upgraded manufacturer’s information being directly imported into the BIM database, without any “filterin” by, say, a specifications person.
And there seemed to be a benign innuendo that somehow a single database was in the offing, unless a firm gets full-bore into BIM-- a costly and very long process.
Not really sure we are gaining that much-- except more work and profit for software comapnies. Wonder why they sought to develop all this with so little input from the construction side,and why they did not think it through-- i.e., how a BIM design is worked into and utilized as construction information.
I attended several BIM sessions at the 2007 CSI SHOW (and convention). I did not gain a sufficient understanding of how specifications production works with the information base that is at the core of the Building Information Model. The tout is certainly presented that BIM will solve drawings/specifications coordination problems and that somehow specifications production will be automated. In fact, the whole issue of construction contract documents was missing from the discussions, including Bidding (Procurement) Requirements, Conditions of the Contract, the Specerfictations and the Drawings.
Did anyone learn what we can expect for specs in the future, besides new numbers and titles?
Now for specs, but maybe pink slips for spec writers.
I heard no mention of them-- seems the route of documentation is from the manufacturer to the BIM database, without any sort of asessment or filtering. And all thatis based on good,proper, and perhaps overly [needlessly] extensive data from the manufacturers.
the push for 3D modeling is coming from the contractor side, almost more than from the owner side. by having one file, you can find conflicts faster, and see the coordination between the various pieces on the model.
I think we’re a ways out before the specifications get integrated into the 3D model, partially because in most cases, the set of documents is both in 2D and 3D. different types of information occur in the 2D and 3D sets.
Until we design buildings that are entirely composed of manufactured components, we’re going to need specifier-generated specifications. the installation requirements for cast in place concrete will vary from project to project (for example) and have to be carried in the project manual.
Remember when “computerized specs” were thought to relieve the spec writer from actually having to think? I think this is analogous to that. what happens with the 3D model is that more decisions have to be made earlier, which means that the specifier gets busier a lot earlier in the process.
I agree with Anne’s assessment. I think the notable aspect of BIM and and specs of the future is evolution of a spec to a database structure. E-SPECS Linx and BSD Speclink are databases that produce text when processed. (The degree to which they resemble a database for this discussion not being particularly pertinent.) That does not mean that a specifier is not needed, it only means the tool is different. Analogous to moving from a typist to a word processor, perhaps.
Once you have specs represented as a database, there are opportunities for connections with a building information model since, in it’s higher form, a BIM is a database. This does not mean that a specifier is not needed either, it merely means that the 3D model of the building and the written representation (specs) are sharing the same database. I say model because one of the more promising near-term uses of BIM is to share the “drawings” as electronic 3D models rather than paper 2D drawings. This is going on right now.
The extent to which specs and models are sharing information at the moment is small, but the promise is quite large. So for example, in the model a door has a size and swing (as it always has had on drawings and schedules), but it can also have characteristics such as fire rating (which it might inherit because it “knows” it is in a rated assembly) and egress component (which it might inherit because the means of egress could be a component of the model). The written “spec database” can then look at this and know that fire-rated egress doors are required. The spec can become informed about aspects of the design that up to now have had to be manually extracted. The model will have information in it that does not affect the spec. The spec will have information that will not affect the model. Both are part of idealized BIM, which also could include what cleaning products to use on the floor, and when the last time the fan belt was changed. Those things aren’t in our documents now either.
To me, the most important thing for a specifier to be doing regarding BIM is to maintain a basic understanding of the possibilities of BIM, become aware of what some are doing on the cutting edge, and keep ones finger on the pulse so that when client’s ask for it, or we see it reach a point where it adds value and fee, we can be ready.
we are starting to set up linking between points on the BIM and some areas of the specs, primarily as a time-and-cost saving measure. by the time I answer the question of “where is this in the specs”, we probably have six hours into it (between various people in the office and myself) and that’s too much just for a reference function.
In terms of how the project works – I’m still using Masterspec, and we’re still coordinating between the drawings and the specs. at the moment, an issue with 3D model distribution is the lack of familiarity with the software below the general contractor level. On our projects, its a requirement that the GC use our software (and we will train them) but we cannot require the subs to use our software. Rather like the early days where we required the contractor to have a FAX machine that interacted with our FAX machine.
in addition, the current widely used software (Revit and the like) simply cannot handle the files large enough to encompass large complicated projects, so there are still implementation problems at the large project level.
I certainly yield to my BIM-fluent colleagues, but the following seems like a fairly lucid discussion, overall. Not very detailed, but several red flags that may or may not be valid.
I think the most important line in the whole article is “BIM is not a panacea for poor project management”. indeed, a badly developed project will almost show up faster in a 3D model than it will in 2D drawings.
I don’t think that using this software will add fee; what it can do, if the project is properly coordinated, will allow more accurate cost estimates from the contractor and does promise the concept of collision avoidance between overlapping systems. With today’s software, I think anyone who thinks that a single data base will hold drawings and specs is delusional. we’re not there yet, and I think it will be a while before we get there.
it does take a strong personality, but it also takes one who really knows how a building is put together and is monitoring the whole project – much like any other project.
It was everywhere at the CSI Show. Well, everywhere except the product exhibits where the intoxication of Green still ruled. I understand BIM was a big topic this year at the AIA Convention.
My editor at John Wiley & Sons called me because I’m working on the 6th edition of Construction Specifications Writing: Principles and Procedures. He said, make sure to include BIM in the new edition (huh??). I asked him for a copy of the new book Wiley has published on BIM. I got it and looked through it.
In the BIM book, I checked the Index for references to specifications. There were three. I only found one actually in the text and it was just a mention of specifications in passing.
I attended EcoBuild in Anaheim last month. I listened to a BIM guru from Lawrence Berkeley Laboratories say (to paraphrase), “When someone says this software is BIM, it isn’t. As soon as something is presented as BIM, it isn’t.” It just reinforced my notion that BIM is vapor. At most (in my opinion), it is a practical application of collaboration and project management for design and construction, with some nifty, universal translator software.
What did anyone learn about BIM and specifications at the CSI Show and the AIA Convention? Especially, what can be said about BIM and specifications? Is BIM a version of the Emperor’s New Clothes?
Real BIM software allows the attachment or embedment of data other than that necessary for the generation of 3dimensional geometry. In fact 3D geometry is not a necessary or sufficient condition of a BIM. Therefore Revit out of the box can HELP create a BIM; Sketch up is not because you cant embed or link to more data.
BTW: A pdf of an entire facility with database accessible tags placed on scans of floor plans might be the core of a BIM
Specification data (all varieties material covered in Parts 1, 2, and 3) could be part of a BIM
Other life cycle and maintenance data, work orders, etc. NOT part of the original spec and generated through the life of the facility could become part of a BIM.
BIMs become REALLY valuable when data can be gathered that has a connection to geographic reality. Thats why GIS has become such a large industry. Its BIM for cities it exists, and it works. Ive advocated GIS for building type facilities for years.
Therefore when specification data is linked (I firmly believe that it will not actually be in the same software data file but in allied data files) we will be able to query it and get some really neat quantitative secondary data.
When we ask these questions and get the answers; what will the format of the output look like? How much will be text and how much will be graphic? How will qualitative requirements and data be expressed when not connected to a model number or material specification?
Specs in a BIM will be the result of questions to the databases making up the BIM. The format of the data that allows for the efficient construction and maintenance of the facility will still be an area that CSI can champion.
See my new thread “Your software could be a BIM if:”
in addition, I don’t know ANY firm that is actually linking specs to drawings effectively, and I know a lot of firms (mine included) who simply aren’t going to go there for a while. the only way we know of to link the specs is to link a pdf – and what’s the point of that? the models are large enough as it is that no one can open them entirely (we have one project where only 1/10th of the model can be opened without crashing the computer)
And, we don’t call our stuff BIM – its the “3D model”. I don’t know anyone in architecture who is actually using “BIM” and neither do the folks at Gehry Technologies – and they get paid to monitor this stuff.