Skip navigation

Collaborative Working in BIM Processes

Clearly defined workflows and communication structures determine success or failure.

With the advancing digitalization in the building industry, new types and media of communication are emerging for all those involved in design. Building models and associated documents can be exchanged and enriched with information almost in real time, which allows a much more agile form of project execution and not only enables but also requires the coordination of semi-finished design statuses. In extreme cases, however, an excessively high degree of cooperation can be counterproductive, as the designers involved have to process a lot of information in a very short time. This is especially true when different disciplines work together synchronously, as there is an additional danger that one has to adapt to constantly changing boundary conditions and loses oneself in updating one's own submodel instead of keeping one's own design performance in focus. One way to counter this complexity is to have orderly process structures with defined data transfer points and coordination steps for individual submodels as well as the entire project. With regard to the separation into partial models, it has become established to separate the building models from the building services designs and to synchronize the referenced architecture and structural design between the teams at intervals of days instead of hours or even minutes.

As Fig. 1 illustrates, several actors from different trades usually work asynchronously with each other. In addition, they work with differently adjusted view filters in a two-dimensional projection of a three-dimensional building. Accordingly, it seems rather unlikely that errors will not occur. Now, such an interdisciplinary design project, in addition to the large number of teams and individual actors, also poses the additional challenge that there are separate areas of responsibility and competencies. An individual cannot usually solve problems that arise during modeling on his or her own. In order to achieve a perfect result, communication is essential.

Managing and fixing numerous modeling errors quickly becomes a complex and time-consuming process. Today, tools like Microsoft Excel are often chosen for this task, since most of the participants either have basic knowledge or can easily acquire it, and this software is often already installed on their computers, so the introduction of a new tool is not necessary. If you have a hammer, suddenly everything looks like a nail. But is this path also goal-oriented in the long term?

As handling becomes exponentially more difficult as the number of participants increases, spreadsheets also become more sophisticated and powerful. Such a workflow may work in well-rehearsed teams up to a certain order of magnitude. However, the implementation requires a lot of discipline and clearly defined rules of the game. Because communication via comment columns always generates new, necessarily coordinated versions, the actual communication in most environments at this point shifts to external channels, such as email, telephone or even colorful notepads that are stuck to each other on the desks. If this point is reached, then one has potentially umpteen places, where communication can take place, mostly analog, thus not well documentable and mutually alignable. It is to be feared that human errors in such process structures will become the order of the day rather than the exception. A digital spreadsheet is not much better than a handwritten list. It may be easier to send and search, but it does not solve the major problems of recording, interpreting and reconciling information. In addition to all the technical process disadvantages, there is another decisive problem: The spreadsheet has no programming connection whatsoever to your BIM platform. The location of reports on individual model elements can therefore only be achieved through time-consuming maintenance, and the reverse checking of validity can only be done manually.

In order to digitize processes, it is absolutely necessary to store data in digital form. However, digitally captured data is of little use if it cannot be interpreted and searched mechanically. In particular, it can be observed that despite or perhaps even due to more available and transferable information, a feeling of responsibility does not automatically arise among the project participants. One reason for this can be an inadequate accuracy of the fit of the information from the recipient's point of view. What do we mean by that?

In order for information to be perceived and processed both efficiently and effectively, all of the following criteria should be met as far as possible:

  • There must be a certain degree of selectivity, so we expect a minimum level of accuracy and traceability of the information.
    The statement "There is a problem with some radiators on the ground floor" is not exact information that can easily be checked for accuracy.
  • The information must be valid, that is, both objectively true and accurate at the time of processing.
    Collisions between components that have long been deleted are not worth seeing.
  • A certain relevance, that is, a meaningfulness in the respective area of responsibility, must be discernible for the recipient.
    For the architect, for example, information about open ends in the air duct network is not important.
  • A message should not exceed a certain degree of obviousness.
    If an employee is in the middle of constructing a complex potable water system, the information about collisions with other trades may not help him, as he is aware of this and may even deliberately ignore it for the moment.

Now it is relatively easy to meet the requirements for the selectivity of the information with standard solutions on the market, since with just a few clicks machine-processable information such as camera settings, references to components involved and various annotations can be attached to the documentation of a problem. The remaining points, however, require the introduction of process structures on the part of the project coordination and their adherence on the part of the project participants. Before we talk about the actual processes, let us first talk about the first point, because fortunately there are already established and cross-platform supported standards for exactly this application. 

Useful additions such as the BIM Collaboration Format (BCF) developed by buildingSMART allow problems to be reported and organized in an asynchronous design process as they are identified, processed and resolved. This is done easily, without the need to transfer complete (sub) models. The issues in a BCF container can be understood in the simplest sense as a kind of digital notepad, but offer the additional possibility for integral BIM processes to store tailor-made metadata.

When entering issues, it is often not sufficient to simply describe the problem. It should also be located and visually underlined so that processing can take place in which the scope for interpretation is reduced.Take your time when creating and maintaining your issues. Use viewpoints, screenshots, annotations, deadlines, responsibilities, markers, milestones, and meaningful types, statuses, and priorities to deliver crystal-clear information to your team. Continue to work on setting up processes to get the most efficiency and effectiveness out of your workflow. If you do not want to get lost in the flood of emails, chat sessions and notes, then do yourself this favor. They will get the invested time back several times over if your teammates know directly what you want to tell them.

For our liNear Desktop for Revit, the proven Desktop concept was adapted to collaborative work. In future, you will also be able to manage several topics with reports and interact with the model under one interface. In particular, the discipline-dependent administration helps you to display only the processes that are relevant to you in your current area of responsibility at any time.

In addition to the possibility of linking external BCF sources to your project, most liNear modules already transfer their reports to corresponding topics. This is particularly useful for the systematic processing of modeling errors that were discovered during an analysis (e.g. open line ends or missing performance values in network calculations), as well as for detailing and passing on cross-discipline topics (e.g. collisions of overlapping components in the architectural model). 

Using the example of another common BIM case of application, slot and void design, we will discuss in the following how efficient communication structures based on BCF can be established in the design stage. 

Slot and void design is a popular example of an integral BIM process, as it is inherently collaborative due to the actors and roles involved. In many cases, the overarching coordination process provides for the MEP officers to draw up sensible proposals for structural measures in order to remedy the collisions with the building disciplines already known at that time. As input of the process there is a list of collision issues, as output there is a coordinated model with slots and voids. The MEP designer is usually not permitted to place provisions for voids directly in the architectural model. In order to counter this rights problem, it has become established to first communicate proposals to the building coordinators in the form of provisional placeholders (provision for void, in the following for short: PfV) for further classification. Ideally, the proposals will be accepted without any change requests, but usually several outlets will be necessary in order to achieve an optimal coordination result. 

The design solution of liNear gives you the freedom to decide with which means you want to implement the coordination process in your project. If you would like to work completely in Revit, then it is a good idea for your project partners to install our free add-in liNear Void Manager, which uses a BCF to classify the PfVs in your building model and simultaneously constructs the accepted provisions for voids.

If you prefer a different or even open workflow, you can export an IFC document with a graphical representation of your PfVs1 in addition to a BCF archive. This can then be placed in the platform of your choice over the model to be coordinated. Individual PfVs can now be enriched with information via BCF files and conveniently accessed and classified in the target platform. For an optimal workflow, your architecture authoring software should support the direct conversion of the PfVs from IFC into provisions for voids.

Whichever way you choose, our decision to use BCF consistently as a communication channel for slot and void design enables you to provide valuable information beyond the actual classification task for the actual process. Each PfV can be accompanied by any number of screenshots and comments. You can also freely design your subprocess in the liNear solution. Let us take a closer look at this point below.

While the partial tasks of the PfV placement by the MEP and the classification or transformation by the building trades can always be traced back to the same craft activities, the general project organization differs, for example, depending on the concrete composition of the design team or the complexity of the building project. Tools that accompany the design process should optimally be able to adapt to these structures by now, not vice versa.

For example, in the context of slot and void design it may occur that instead of a simple classification process by a person responsible for the building, a multi-stage approval procedure for the conversion of the PfVs into actual provisions for voids has been agreed (see Fig. 8 for an example of a two-stage subprocess).

The BCF standard allows the free assignment of statuses. It is therefore easily possible to depict the structures shown in the form of microprocesses. However, the concrete realization in commercial solutions requires the observance of a certain discipline by the users. The liNear solution offers its users a suitable view of the process steps that affect them. This is achieved by assigning a fixed meaning to individual statuses. Furthermore, it is possible to give a name to transitions between two statuses in order to better structure the workflows on the part of the usersin order to ultimately reduce careless mistakes during the execution of your processes. Such a transition leads to a series of work steps in the interface of our Issues and tasks, which are always adapted to the current status of your issues.

Closed issues can also contain information about the solution to the process. For example, it is conceivable to clearly name the different stations in a multi-stage microprocess in order to then use the status information to coordinate their slot and void design.

Because the new slot and void design integrates with our proven view control model, we can show and hide coordinated void proposals based on their classification status. This also allows us to continue to benefit from the available information after coordination with the building model. For example, the information about rejected void proposals is also helpful later if changes are to be made to the systems. In regions that have already been rejected, approval of structural measures remains unlikely in the further course of the project. This can save you valuable time if you try to find an alternative cable routing. Also, the inclusion of accepted void proposals allows the subsequent verification of the submodels and the identification of potentially redundant voids.

Some providers who specialize in collaborative platforms do a lot of marketing with the option of synchronizing their submodels live with the cloud anywhere and at any time. This quickly gives the impression that modern working in the cloud is designed in such a way that every participant can and should be informed directly about all processes affecting him at any time. But as tempting as this may sound: Too frequent adjustments will lead your employees to unstructured work, as they may perceive new issues with inappropriate importance and urgency if they arrive at you individually instead of collectively. Furthermore, if there is uncertainty about responsibilities, there is always the risk that two users will simultaneously process the same process, which makes it unnecessarily complicated to merge the data into a common database. The transmission of issues should therefore still take place when defined process steps are reached and the transmitted BCF data should be versioned and archived for the purpose of process documentation. In this context it is of course possible and sensible to rely on specialized (cloud) solutions or conventional version control systems. This memory is the central data source you can trust within your higher-level process.

With this in mind, let us conclude with an appeal for orderly process structures that have been approved in advance.

Christian Waluga

1 As IfcBuildingElementProxy with pre-identified type PROVISIONFORVOID


Header: CoreDESIGN/Shutterstock