Detecting and managing clash issues is one of the most common tasks that a BIM Coordinator must perform in his work. When you work on large projects, you will definitely be dealing with many project stakeholders involved. The number of models that you will have to manage, check and exchange can vary from a dozen, several dozen to even several hundred depending on the size of the project.
In complex projects, the entire process of coordinating all models and managing their clashes is a real challenge.
The collision detection process itself in theory is quite simple. We merge trade models into one federated model. Then we set up rules in the coordination tool, we “press start” and the software searches for collisions for us.
The next step is to assign specific clashes to a specific trade, person, or project group that will be responsible for a given clash. This is where things start to complicate.
As a BIM Coordinator, you won’t always know which project party is responsible for a given error. More than once I’ve assigned a collision to the wrong group or person. Sometimes it also happens that more than 2 disciplines are involved in a given conflict. So who should resolve a given collision? Who takes the responsibility for these?
To deal with this problem and to manage clashes on a project more efficiently, I like to use two helpful “concepts”.
What are these concepts? I reveal it in this post.
System Hierarchy
The first is the Systems Hierarchy. There is a certain hierarchy of systems that occur chronologically one after another during the construction of the building. This hierarchy is nothing more than a way to divide the various building systems in order, from those that are most difficult or expensive to move to those that have the greatest freedom of movement.
Depending on the type of project we are working on, we may have a slightly different order of such hierarchy, but in typical construction projects, it may look like this:
1. First, we create structural and architectural elements as the core of any construction. This means that at the core we have the objects which have to be designed and executed in the first place.
Architectural and structural are considered frozen, so all trades will need to go around them. They will not move unless there is a major issue, in which case designers need to be brought to the table for discussion.
2. Then we have components and systems that are closely correlated with the location of specific rooms in the building (e.g. toilets) as well as the main mechanical ducts. These are often objects of large volumne and little possibility of relocation in the later stages of design.
3. Further down the hierarchy, there are all kinds of smaller systems that have a greater ability to adjust their position in relation to other elements. Such systems may include plumbing or smaller ducts and pipes.
4. And last comes electrical systems, fire protection, and other minor systems which are flexible and their placement can be fairly easily adjusted.
Examples of system hierarchy
The diagram shown above is just one example. I’ve also seen other ways to break down the system hierarchy. It is often tailored to the characteristics of the project. Below are examples of a slightly different division:
This hierarchy is created conversely – Top of the triangle is the highest priority.
Clash Matrix - general
Once we have a defined hierarchy of systems, now we are able to build the so-called Clash Matrix. Usually, we create such a matrix in the form of a table, e.g. in a spreadsheet.
It allows the project team (and the BIM Coordinator) to make quick decisions on which elements of a particular system should adapt to another system in clash cases.
Such a matrix might look like this:
A clash matrix shows which disciplines take precedence based on which ones are furthest to the top and left of the matrix.
It is easy to see that the matrix reflects the system hierarchy presented earlier. So, first of all, we have the architectural and structural trades, then HVAC, plumbing and electrical systems.
In our table, each discipline is responsible for the internal coordination of its disciplines and we mark it with red numbers. Then the next numbers appear. The numerical order specifies the order in which clash detection occurs. So, first we check structural and architectural models.
This will give us a good idea of whether elements that have a direct impact on the location of other building systems are okay or not. If not, these collisions should be considered a priority and reported to architects and structural designers for correction as soon as possible.
Following this line of reasoning, the collisions that will occur in the area of our matrix marked in the figure below will be treated with a higher priorty than….
… those which occur among these trades:
Creating a clash matrix and such a visual representation of how we will check for collisions helps the BIM Coordinator a lot in several ways:
1. Firstly, we may know which issues are a priority and which models we should fix first,
2. Secondly, we don’t have to guess which branch is responsible for a given collision. Clash matrix helps us with this. Each trades is responsible for all checks from its column.
For example, the plumbing trade will be responsible for fixing clashes with architectural, structural, and mechanical models (as shown on the picture below):
3. Third, by looking at the clash matrix, we know what checking rules we need to prepare in our coordination programs.
Clash matrix - detailed
The above matrix gives us a general overview of multidisciplinary collision check. For larger and more complex projects, it is a good idea to plan the clash detection proces more carefully by breaking down specific “numbers” of the matrix into detailed ones.
For example: Let’s take the number 9 from our matrix, which is a check between the structural model and the plumbing one. Instead of checking the entire models, we can break down the structural discipline into individual object categories i.e. ceilings, stairs, walls, columns, foundations, etc.
You can also do a similar decomposition for each category of the object in the matrix.
Such breakdown is a level higher in planning clash detection. It is especially helpful in checking large, complex projects with a large number of model elements and requiring very precise checks.
Changes in hierarchy
Remember that the system hierarchy and the clash matrix are “concepts” which should help us facilitate coordination process. They aren’t rules carved into the rock. Certainly, during the development of the project, there will be various changes that will require a special approach from us.
Consider the case where the design team decides they cannot change the height of the ceiling, but there is a plumbing roof drain pipe that collides with the structural beam. If the ceiling cannot be lowered, then in some special cases the structural designer can design a penetration around mid-span of the beam for the roof drain pipe to pass through.
This is just one case, but you will certainly encounter many in your daily work. In this example, the hierarchy has been changed and that’s okay. The most important thing is to communicate the issue to the rest of the team, understand the problem and design an appropriate solution.
10 TIPS TO IMPROVE YOUR BIM COORDINATION PROCESS
All registred will receive 
GIFTS
MIND MAPS AND WORK FILES
To Sum up
I hope that after reading this post, you got a few ideas how you can improve the coordination process on your project. I am quite curious about your ways of managing clashes. Maybe you know some interesting new tools or ways that you would like to share with others. If so, feel free to write in the comments below this post.
In the meantime, we see each other in the next article about BIM Coordination. If there is a topic that interests you in particular, feel free to write to me at [email protected]
If you would like to learn BIM Coordination from me, I invite you to sign up for my online program. Just follow this link: https://becomebimcoordinator.com
As an owner’s Project Manager, I have been frustrated with the clash detection done in the model prior to the drawings going out to tender, even though clash detection was claimed to have been done with the design disciplines. With clash after clash found during our VDC process, it was ineffective. I cannot point my finger at a specific reason for this inefficiency. In your opinion (no pressure) what is the hierarchy of CONTRIBUTORS TO FAILURE of the process? Worst at the top and lesser degrees of worse to follow….
Hi Tracey,
It’s quite a complicated question to answer. Since I don’t know your project specifics which is key here to understand what is wrong with QA / QC process, I would guess first
that the team doesn’t prioritize fixing those issues.
You ask – How much time is enough? It depends on how many issues do you have? How big area are you guys checking? How many people work on fixing those issues? There are a few questions that you should ask your team first to get the right answer.
Awesome post as always guys! I have been following basically the same approach ever since I was commited to perform my first coordination, its very logical actually. Btw, which software are you using to create the infographics? I am developing a BEP and including images its a must!
Hi Juan,
Thank you for your comment. We are using Canva.com to create infographics.
Hi Ignacy, thanks for this its great as I am currently preparing an EIR for an owner. Just a query regarding the matrix itself, are 8, 9 & 10 in the correct locations. Under Plumbing its showing as 10 8 9 and red 7. Thanks.
Thanks for sharing