The standard to rule them all is fantasy

The standard to rule them all is fantasy

I developed a few modeling standards already in my life. It started during university in AutoCAD when I continued to Revit, Microstation, and Vectorworks as an architect. When working as a project manager and owner rep, standard development continued from the perspective of data transfer and making IFC useful for quality assurance. My main philosophy has always been that I, as a project manager, want to be able to answer questions quickly without having to ask the project team for every small inquiry - freeing up their time to do more value-adding work and not having to wait for every single answer.


Why Standards and workflows?

Let's start with the question of why we need standards and workflows. It boils down to becoming more efficient and automating tasks. E.g. A quantity takeoff, an area calculation, handover of FM data... This can be true internally in one company or as a professional owner organization or building permit organization that does not want to adapt to different modeling styles all the time.?

And that's the catch! We do have technical standards like IFC, but they are not enough to work efficiently - you need to know what to do with the data. That was simpler when working with plans because we had more experience; we did not have to think about the workflows - at least not so much. Moreover, imagine a client project manager who works on several projects. This pm won't like to work with different CDEs and won't like to adapt to different modeling styles when interacting with a model. He wants to be efficient. Conversely, imagine any planning or construction company working for various clients. They don't want to adapt their working style to every client - they want to work efficiently.?

So there won't be one standard that fits all the needs! This pipe dream won't be fulfilled in the foreseeable future. The answer is simple we need to build ower own efficient workflows on the foundation of technical standards. And we need to learn to translate one standard to the other automatically!


How to develop a standard?

To develop a standard, we should keep a few principles in mind:


  1. A standard needs to be simple, minimalistic, and focused on the model user's needs.?
  2. You need quality-checking rules to guarantee consistency.?
  3. The person in front of the computer is only allowed to enter data they understand. Otherwise, data quality will suffer.?


Unfortunately, I see different approaches too often. Nogos are:

The modeler has to manually enter a data/classification system irrelevant to their work. In Switzerland, this is often eBKP, an element-bas ed cost classification system. Comparable too DIN277. To avoid this, I see two possible strategies.?

  • The classification system is automatically calculated based on some basic attributes. E.g., With the IFC attributes PredefinedType, IsExternal, LoadBearing and some logic to calculate what's above and what's below ground.?
  • The second strategy is to agree on a standardized list of understandable human values in one attribute, e.g. In the description of every element. The advantage of the second approach is that the user only needs to manage one single attribute. The rest could be automated.?


Too many requirements without any clear need. The idea is, let's just ask for the data. The more, the better - especially clients are guilty of this. Unfortunately, this is not true. The more data, the more potential for garbage. To avoid too much data, I usually encourage non-modelers to ask these three questions:

  • For what do I need the data??
  • How do I design a quality assurance Workflow??
  • Can I calculate the data based on some other input??


Long, complicated, and incomplete Excel lists and high-level Word documents to communicate the requirements. When designing a quality assurance process, we can avoid this by considering the data need and the best user-centric way to communicate requirements. I like to work with a database and:

  • build up the definitions from the bottom up.?
  • share the quality assurance or at least some SMARTviews to make the data usable for non-modeleres.
  • not only communicate the technical data requirements but some modeling guidelines. The best case scenario is to communicate with pictures!


All these thoughts were triggered by a standardization project I currently work on. I'm looking forward to hearing about your approach toward standards and workflows.?

要查看或添加评论,请登录

社区洞察

其他会员也浏览了