In my previous blog, I discussed the clash prevention process and how Haskell is using that to advance our designs and deliverables. Our process is one that we have found provides useful information to the design team to improve our projects’ constructability and improves design team coordination. The value that clash prevention brings hinges on how useful the clash report is to the team.
Prior to developing our internal process, contractors would often provide our team with lengthy clash reports that would take a lot of time to review and determine corrective action for each clash. We found that most of these clashes either were not true clashes or were merely symptoms of other issues. For example, if a roof leader is routed through a concrete beam but that location is coordinated between structural and plumbing teams, it is not a true clash. Conversely, if a clash is a symptom of an issue, that means that multiple clashes are related. For example, if a single cable tray runs through multiple ducts, then the issue is that the ducts and cable tray are not coordinated. This is where the clash report can be optimized.
Each clash report that Navisworks generates follows specific rules that determine which systems/elements are being reviewed. If a test was run against all the models at once, there would be too many clashes to be manageable. By breaking the clash test down to more finite parameters, such as structural members vs. mechanical ducts, the results are more targeted and more easily reviewed.
Once the test is complete, our team sorts the clashes by level to review each level at once to help identify issues in the model, such as the cable tray and duct issue. To refine the report further, each issue is presented as a clash rather than itemizing each clash. This allows the report to be more focused and allows the team to move through the discussion more quickly.
The final step is to conduct a virtual walkthrough of the model to ensure there are no problems that wouldn’t be considered a clash. On a recent project, the team found a structural brace that crossed in front of a door. Since it didn’t touch the door it wasn’t a hard clash and was not identified in the Navisworks report (see below).
By following this process, we distill the clash report down to the true clashes and issues that need to be resolved to improve the constructability of our projects. This saves our project teams time that can be directed toward improving the design and the deliverables. While no model can be truly clash-free, we endeavor to be fully coordinated to ensure the quality of the BIM model and thereby the constructability of the project.
