AUGI World January/February 2009
Here is what I had to say. I hope you enjoy!
As structural professionals, we would always receive what everybody said was this perfectly good CAD file from the architect. This file contained everything we needed to produce our structural documentation, we were told. The thinking went something like this: “They already have the grids laid out. Let’s just trace over them, or better yet, let’s just copy/paste them into our file, or much better yet, let’s just save their file as a new file, delete information that is not needed, and make it our structural file.” In return, the CAD manager would say, “Absolutely Not! We are going to verify every single line, dimension, text, and draw our own information in our file.” Why was this done? Because over time we began to lose faith in the accuracy of the drawings we were receiving. Structurally, we wanted precision set to 1/256" and “they” wanted it set to 1/16" or sometimes even 1/8". Other programs were used to produce napkin sketches of the building during schematic design and those sketches were being pulled into CAD. Sometimes the sketches were turned into nice numbers that were easy to work with and other times it looked like they were just left as sketches. The bottom line is we could not trust the CAD files to enable us to produce an accurate set of drawings that would allow other parties, such as fabricators, to use downstream. Using Revit on a project changes all of that; at least it needs to in order for the whole process to work.
The workflow needs to change
What needs to change? First, everybody needs to start producing accurate models that we all can trust. This means that those working on the project are going to have to step up their game a bit and go that extra mile to make things correct. Without this accuracy in the Revit models you are sharing, you will have little chance of relying on someone else’s model. Second, we need to start communicating again. No more of the architect moving an elevator shaft over 6" so he or she can maintain a certain corridor width and not tell structural it was done. Drawings get issued, it gets built from the structural drawings, and the elevator shaft is constructed in the wrong location. There can be no more of the engineer changing a beam depth size and not telling mechanical. The field guy is installing some duct work and finds out that his duct work does not clear the bottom of the beam. Dropping it would lower the ceiling height. Who wins? I could go on and on with scenarios from all sides of the design team, but right now I would like to talk about how Revit can eliminate this. Using Revit to model your projects and to produce construction documents is a chance to regroup with everyone and change the way you have been doing things in the past. I know that some of you who have been doing this correctly, but I also know that there are others using the undesirable methods described above. So let’s discuss the workflow that can get you started in a new direction.
What do I mean by dependent collaboration? Well, this means that each discipline models only the elements for which it is responsible. Architectural should not be modeling footings, foundation walls, columns, framing, and structural slabs. Structural shouldn’t be modeling exterior finishes and door/windows to show how they relate to a lintel or a foundation wall. And I have to believe that Mechanical does not want to model any of that, preferring to model its own discipline specific elements. Can all of this happen 100 percent of the time for every project? No. You will face challenges that might discourage you from thinking that any of this makes sense, but hopefully as you are reading this, you are thinking about what part of this workflow might allow you to take advantage of the same benefits we see when we work on projects in this manner. Some project schedules might not allow for this workflow and certain structural systems may accommodate this more easily than others. There will always be scenarios that will prevent some of these efforts from being carried out to the fullest degree. But over time, I see this slowly decreasing as the workflow is further defined. At my company, this method of collaboration is what we try to use on the majority of our projects. The goal for all team members is to avoid modeling anything twice. If this can be done, then your model has to be coordinated or your drawings will not be correct. Figure 1 shows a structural section that clearly is not coordinated.
With Revit, you can be dependent on each other’s work, so as long as you are communicating about whose model is correct and you are using the most up-to date models prior to printing, you will be coordinated. At least if your section is wrong, it will be wrong in the same way throughout everyone’s documents.
What does the structural engineer use from the architectural model?
· Doors
· Windows
· Walls
· Curtain Panels
· Curtain Systems
· Curtain Wall Mullions
· Architectural Columns
· Stairs and Railings
What does the architect use from the structural model?
· Footings (wall, isolated, slab)
· Foundation Walls
· Piers
· Columns/Post/Hangers
· Framing
· Slab on Grades
· Structural Slabs
· Roof Deck
Now don’t get the idea that Revit is going to do all of this for you. It will, for the most part, after you determine your settings, but first you need to get yourself familiar with working with the Visibility/Graphic Override dialog box and the RVT Link Display settings shown below. Getting deep into this is another topic for discussion. So for now, if you are unfamiliar with it, check it out.
Also take note that getting started with all of this is going to take a bit more time than you are accustomed to, mostly because it is new method of working and thinking and you need to get past the learning curve. What I see is the time you may have spent on the phone after your documents were issued is now shifted to more time on the phone before you issue. The kick is that your time on the phone is going to be much more enjoyable and beneficial for everyone because you are fixing problems before they are costing everybody more money. If you are just starting out, it will take more time because everyone is learning the new workflow as well as trying to understand and learn what everyone expects to happen on the project. So with that said, the most important thing for you to take from all of this is to communicate before a project is even started. Get everybody’s expectations out on the table and come up with a plan to achieve your goals.
Communicate, communicate, and communicate some more
During this communication process you need to be communicating internally to your own people, externally to other team members, and continue to communicate on a daily basis throughout the duration of the project. Currently, I find that users of all levels from all disciplines are still learning the software as well as the new work flows involved, so the level of communication required to pull this off is key. The biggest thing is to get everybody on the same page prior to starting a project. Decide what is expected and discuss the best way to work within those expectations. To do this, we push to have a Revit kickoff meeting prior to any new project. This means that the minute someone catches wind of a project starting up, someone needs to be picking up the phone to get a meeting scheduled. In this meeting we bring with us an agenda that walks the team through everything that should be discussed prior to starting the project.
What things should you talk about in a Revit kickoff meeting?
· Identify team members and their roles
· Set the expectations and goals for the project
· Identify the workflow process each team will use
· Determine who will be modeling what
· Review how each team will be using Revit
· Discuss limitations each team might have with the software
· Discuss how models will be transferred and how often
· Decide when Revit will be used (some might still use 2D CAD for SD and DD)
· Define the deliverables (Revit model, DWF, DWG, hardcopy, model presentation)
You might also consider creating a separate document that is more specific to your company regarding your own list of expectations in terms of what will be in your model as well as what will be in someone else’s model. Be prepared to manage expectations that are not met. You may be dealing with someone who is new to Revit or a client with whom you haven’t worked before. Either way you need to be ready to deal with the consequences of a changed workflow and you must relay that workflow back to your own team. At least with the BIM/Revit kickoff meeting, you are dealing with these problems up front rather than waiting until the day of a deadline or after an issue arises. The use of Revit gives you the perfect excuse to embrace change and redefine your collaboration workflow. Revisit the accuracy of your drawings, duplication of effort, and how you communicate. Over time I think you will find that it was the right thing to do. So what are you waiting for? Go ahead, call your client or your consultant. Set up a meeting to see how you can use Revit to collaborate on your projects and maybe even change things up a bit with regard to how you work on a project. Who knows, with your next project, you might just be able to leave work on time!
Jamie D. Richardson is an Associate and CAD\BIM Manager at Ericksen Roed & Associates, a Structural Engineering firm based in Saint Paul, Minnesota, USA. Throughout his 14 years of experience with Autodesk products, Jamie has been instrumental in the rollout of several versions of AutoCAD as well as the implementation of Revit Structure. He has been an avid speaker on Revit Structure at Autodesk University and recently co-authored the book Mastering Revit Structure 2009.
I have been reading your blog and articles about Revit collaboration with great interest. I have a question about that:
ReplyDeleteI am trying to wrap my brain around the difference between "Dependent" and "Independent" collaboration. I understand the difference in relation to the actual model, but not in how the model(s) are accessed by different disciplines. In "Dependent" collaboration is everyone "hooked up" to the same model that resides in one server? Or is that server just storing all the different models for everyone to access? Is this scenario using FTP or a Wan? In the "pros" for this way of collaborating in your article from AU you list "No transfer of model files" - that sounds like they are all tied together. If we are using FTP aren’t we still transferring the model files? Does this "Dependent" method still use Copy/Monitor or are we all tied into the same model? Thanks for any help.
Steve Blackburn
Frost Engineering & Consulting Company
Please read my comments below. I hope I am able to answer your questions. Thanks for reading.
ReplyDelete1.)In "Dependent" collaboration is everyone "hooked up" to the same model that resides in one server? We have not been in the scenario where everyone is in the same model working on the same server so it is tough for me to respond to this workflow. I
here differently depending on who I talk to whether or not this works for them. Some say a does, some say it doesn't. I don't know what the
impact of 3 different Revit softwares working on the same model does. Plus I think the models would get quite large. Our structural model tends to
be much smaller than the arch and MEP. This could be handled with worksets but you now have one large file instead of several small files.
2.)Or is that server just storing all the different models for everyone to access? We have had in a few cases where this was the scenario. Struct, arch, MEP each had their own model. We enforced a 100% no doubling modeling rule.
This actually worked out pretty good since our client controled everything and nobody had to worry about liabilities. The all on the same server was at
our clients office and we work through hardware devices to speed up the Transfers.This work well since nobody had to worry about
uploading files. You just had to go into manage links and reload the file to get the latest updates since their last save to central. We did have some issues once the files got so large, but my hope is that technology catches up to eliminate that.
3.)Is this scenario using FTP or a Wan? This is our typical workflow.It works, but you do spend much more time transferring and managing large files.
We set up usually a weekly upload/download. Disciplines are staggered so each one has time to catch up to one another. If intermittent
upload/downloads are required we communicated it with each other. Depending on the where we are at with design we may need to exchange more often. My goal is to get a solution where someone on the team host the server where everyones models exist to eliminate the tedious task of uploading/downloading/managing these large files.
4.)In the "pros" for this way of collaborating in your article from AU you list "No transfer of model files" - that sounds like they are all tied together.
Ahhh... ya that would be for the Dependant collaboration where all files are on the same server which could be the case for an all in one firm. Or
in the scenario I explain about. Either way I would say each discipline still has their own model.
5.)We only copy/monitor Grids and Levels. Typical we get the arch to lock down the levels and grids before we start. We copy/monitor from their model.
When they get our model back, they just monitor their grids and levels to ours. Now we both now what each other is doing. If new grids and levels
are added we communicate it so we can all get the proper monitoring in place. In some cases we have started the model so the roles would be
reversed.