Blog

This is the first post of a planned series of short reads (compared to my previous posts). With all the lockdowns and overall uncertain times upon us, I found myself deeply thinking about my personal experiences with BIM implementations, workflows, and BIM in general. Some thoughts are just random interesting discussions with myself, others relate to my experience in implementing BIM for infrastructure projects (bridges, tunnels, etc.), particularly the first two major pilot projects. I thought it might be worthwhile to share these thoughts as a series.

To start off, I remember 4 years back, when I was still working at the largest infrastructure designer in the Baltic states (Kelprojektas, UAB), my colleague and I were responsible for the first BIM pilot project within the bridge department. We had a goal to establish a future BIM workflow for the department. Hence, it was important to get a lot of things “right”. Considering that it was a live project without much time to play around.

We were using Revit for the project, thus I had to think of ways to better approach the creation of the rather complicated self-anchored pedestrian steel suspension with CHS elements instead of cables. This included identifying the best Revit practices and expected ways of working with it.

The more work we got done the larger the obstacles we started to encounter. One of those was making modifications to the model, essentially rework. It was common to hear back then how BIM projects are easy and quick to modify, you don’t have to redo your drawings and schedules. Which is only partly true, even to this day. The common CAD workflow in the office at the time relied on constantly reusing drawings and schedules from previous projects that fit the current one. With hundreds of projects available as references, it becomes a difficult benchmark to beat. When dealing with BIM projects, one of its strengths such as relations between the various objects within the model can quickly create new problems. As every Revit family is basically hosted or related to something else, any change that requires the modification of those “foundation” families can have profound impacts on how much will have to be remodelled or adjusted, not to mention cleaning up and annotating the drawings again.

I found myself using more and more workarounds in Revit and disobeying common recommendations read online from Revit experts and Revit purists. I used various placeholder elements to provide certain surfaces to host other geometries. The instances were then placed in their respective worksets and hidden. Among these were simple adaptive families with 3 point faces and 4 point faces that could be placed manually or with Dynamo at specific locations or coordinates. This did break the Revit relationships of certain elements, but it was particularly useful when we knew that a specific part of the bridge could potentially change but other parts will not.

Similarly, I used placeholder elements just for schedules where needed. As an example, we often need to have identical quantities in shop drawings as in the initial technical project that was used to take out the construction permit. With our poor regulations, it basically means that if say a beam ends up with 1812kg of rebar but the technical project (which often does not show detailed rebar layouts) says 1850kg, in most cases it will save time and avoid unnecessary explaining if we just create a placeholder object in Revit, call it rebar tie wire and give it 38kg weight and place that sole schedule below the rebar schedule on a sheet.

We wanted a more Lego like approach to creating BIM models, where with time, the office ends up with more and more Revit assets that new projects could be quickly assembled from in a very short time. Assemblies in Revit do not really serve that purpose, groups were partial solutions as well. What I found best and still see it viable in many cases is to use nested families. There are certain issues that come with that, particularly when exchanging data but there are workarounds that suited us. With a bit of Dynamo scripting it is possible to create quite lucrative workflows targeting increased productivity. One thing that I do think is missing in Revit from an engineering standpoint is the option to save a “super family” in Revit. Something like an actual project of certain objects that are often reused. As an example, bridge girders, precast concrete beams already with all the rebars inside and all the views, schedules and sheets that could be inserted just like a family into a project. The current ways to go about this are not adequate in my opinion.

I know I will contradict my preaching of how it does not matter how you work with Revit, but please do not use model-in-place Revit families. Reusability was and is one of the aspects why I really dislike model-in-place families in Revit. That is beside the fact that they always lead to some sort of problems down the line. If the geometry will not get messed up accidentally during the project, then something else will come up, Dynamo scripts not working properly with those elements, some weird quantities and whatnot. The answer I get when I ask why someone uses them usually revolves around having a live preview of where you are creating the model-in-place family. Having a reference for those pesky elements with weird geometry or one-off cases. That got me to create a Dynamo based solution to partially solve this. I think I will share the script in a brief tutorial for the next post of this blog. I still find it rather strange why to this day Autodesk has not enabled proper loadable family creation within the project environment or at least with the project in the background. Short rant over.

Asking the right questions

As much as I attempted to stay true to the Revit way of working, with time I inevitably committed more and more Revit atrocities that I started paying less attention to them. I do believe my experience as a bridge structural engineer can differ wildly from the architects’ who have been using Revit far longer than most engineers. Regardless, I suggest instead of thinking if you are following “good” Revit practices, to focus on answering these questions:

• What are the use cases of the BIM model? Identify them. Does any of the current modelling aspects impede with these use cases? If no, you have no problem.
• Will your BIM model have sufficient information for those use cases? Can the data be extracted from the model? Make sure information is workable with.
• How will BIM data be exchanged? Will you be using IFC files? If yes, your Revit categories do not matter much, just reassign, as necessary.
• Will the current way of working have conflicts further down the AEC supply chain? Identify and mitigate them, as necessary.
• Is the reusability of BIM assets important? Identify the bottlenecks to reusability and work around them, use Dynamo if necessary. There are significant efficiency benefits to be had but requires keeping an open mind.
• Does the current workflow conflict with any BIM related regulations?
• How satisfied are the teams using this workflow? If all is good and people are used to it, then it might not be worth the risk in forcing “good” Revit practices.

Sometimes we need to take a step back and take a broader look at what it is we are doing and where we are in terms of the AEC supply chain. Autodesk Revit is just a single ecosystem within a much larger AEC ecosystem of how projects get delivered and constructed, etc. These things matter. As long as your way of using Revit ensures the end goal, a standing physical building, bridge or whatever structure it is you are designing, the Revit workflow you have is good enough. It might not be the most productive one but at least you know it works. Having mentioned productivity, if you do think you could benefit from some efficiency-focused tweaks to your workflows, drop us an email, we might be able to help.

Stay open-minded, do not get caught up in details that might not be significant in the overall scheme of things. Lastly, remember that while Revit is not perfect software, it is very versatile once you begin thinking out of the box.