Top 7 Worst Epic Fails in Revit

Usually, this blog is used to convey ideas and protocols that have been tested and perfected.

That might paint a false picture of what the BIM manager life is actually like. A lot of the time, the processes can be messy. In my 9 years as an architect and BIM manager, I witnessed multiple epic Revit fails. Everything that was supposed to happen miserably failed and the fancy protocols we developed were of no use.

Epic Fail #1: The Floating Floor

The project team arrived in the morning. We were all drinking coffee and chilling while our Revit models were opening. We were all working on a major hotel project with big deliverable in the coming days. Suddenly, an audible sigh of horror emerged from a nearby colleague. A major floor element was floating in the middle of the model. Somebody had moved the floor by mistake.

On a small project, that’s not a big deal at all. On a big projects with 13 users working simultaneously, it’s quite a big deal. Maybe there are tags, dimensions or hosted elements that were affected? Should we recover the backup? Or just put the floor back in and hope nothing important was affected?

We went around and asked all colleagues which person made that mistake. No one admitted their horrible sin.

Lesson learned: From that point on, we had a policy to pin all major elements in the model. If you want to get really sneaky, you can use the “Who did that??” tool in the pyRevit plugin. It will tell you which person last moved a specific element.

Epic Fail #2: Update the Revit File Version Without Notifying the Other Consultants

An intern decided he wanted to work on the project during the weekend. The new version of Revit was just released, why not use it? He proceeded to update the model and advance major parts of the model.

The following monday, everyone was confused… Wait, the file is now in Revit 2021? Then you have to make a decision: revert back to the old version, discard updates to the model. Or convince our consultants to switch to the new version? Never a good decision in the middle of a project.

Lesson learned: Agree with consultants which version of Revit is going to be used. Create a BIM execution plan and indicate the version to be used. Make sure everybody on the team understand the importance of not updating the file.

Epic Fail #3: Different Worksets, Different Phases, Different Groups, Different Split Faces

In a major project, we created groups for repetitive hotel interior elements. These groups contained elements in different worksets. They also contained elements in different phases. They also contained walls with split faces.

Most BIM managers are laughing reading this description. Because that’s how you create chaos. The groups started to have problems and inconsistencies. The phases were all messed up. The split faces were deleted automatically, or they just started to randomly move around.

Lesson learned: Don’t use too many groups. If you do, keep it simple. No elements of different phases or different worksets inside the group. Don’t use worksets for visibility (except for linked models). Use filters and view templates when creating finishes plans. Avoid split faces.

Epic Fail #4: Rendering Props Showing up in Construction Documents

One of our interns really liked to create renderings directly in Revit. To embellish his renderings, he imported multiple families of birds, glasses of wine, dogs and plants.

The problem is that he didn’t do anything to control the visibility of these elements. One day, we sent the client a set of construction documents with birds, glasses of wines, dogs and plants just laying around. Maybe the client enjoyed our lively documents, but we realized we had to be more careful with these useless props.

Lesson learned: If you have to import such families, make sure to turn off the Entourage family in the Visibility/Graphics menu. To be really safe, you can create an additional “Renderings” workset and put all renderings related families inside of it.

To be even super-extra safe, you can create a linked model containing the entourage elements.

Epic Fail #5: Model-In-Place Madness

We thought it would be a good idea to model a complicated railing element using model-in-place.

Think again.

Any time you try to copy and paste model-in-place elements, things get weird. Positioning elements is complicated as movement is restricted in certain directions. Then, we would synchronize and the model-in-place elements would randomly start moving around. When we moved one of the model-in-place element, another one would also move. For some reason, there were hidden geometrical constraints between these elements.

Lesson learned: Model-in-place is a terrible tool. It is awkward to use and should be avoided at all costs. Use families instead.

Epic Fail #6: Plan Notes Confusion

In one of our popular blog posts, we described a plan note system that uses generic annotations and note blocks. The system has been perfected and improved over the years.

The initial version of this system had some major issues.

Whenever a note bubble had the same number as another bubble but with a different text, the text description disappeared in the note block schedule. We had multiple issues of plans with empty note descriptions.

Lesson learned: In the note block schedule, sort by note number, then sort by text. This way, you will never get empty rows instead of descriptions.

Epic Fail #7: Detail Groups Insanity

We used to create detailing using 2D Detail Groups inside views. That allowed us to use the same detailing for views of multiple scales, you just had to copy/paste the detail.

Ugh, nightmares.

Groups are just buggy. Elements would start to move around. Groups would be inconsistent. You would get warnings like in the image below:

Lesson learned: Details groups are garbage. Create detail component families instead. Don’t detail big scale views. If you really have to use detail groups, keep them small and simple.