Resuming the lessons learnt post series, I want to move onto the topic of data in BIM models. More specifically, the data that we add to our BIM models in software like Revit, ArchiCAD, Tekla, etc.
When I first started working with Revit workflows, I was very cautious as to not limit the potential of BIM projects and potential use cases even then it was relatively clear that use cases would not apply to the specific project. Therefore, I overloaded my BIM projects (in Revit) with custom parameters to store all types of possible information. While some were really useful both in terms of internal project delivery workflows and automating processes with Dynamo, others were hardly ever needed.
I’m pretty sure that I am not the only one who uses way too many parameters in their projects. I’ve seen Revit shared parameter files that contain hundreds upon hundreds of various parameters. Back then, I would have questioned myself that maybe I am not accounting for something in the projects. However, from today’s perspective, I just have to question the necessity of that. While I’ll share my thoughts below, I would also encourage to spend the time and read the following post: Less is More: The Minimum Viable Data Approach for BIM | OpenDefinery/Blog.
It can be very lucrative to stuff the models with excessive data, as there could always be potential use cases for it in the future. But just because you can does not mean you should. All data needs to be managed, it has to be entered, checked, manipulated, exported and what not. The more data you have in your BIM models the more time you will need to manage it. Even with various automation tools, automated checks and other systems, it still takes time to set everything up and run through the process. When I was working on getting a bridge department to transition from CAD to BIM with Revit as the main software, I got caught up in the potential of the rather far too distant future and just went loose with parameters. With time, I only kept removing them and the finalized workflows required far less effort to maintain the data.
Let’s dissect the custom data we use in our BIM models. First, the mandatory information, to be more precise, dealing with mandated data/information as per the specifications outlined in EIR, BEP or other related documents. Some information needs will be derived from the mandated classification system, be it OmniClass, Uniclass, CoClass, CCI, etc. This is the data that you like it or not, has to be present in the model. There isn’t much you can do but potentially automate some of the data entries if possible.
All the other data, user inputs in your models should be limited to aiding your workflow needs. In the case of Revit that might be something you use in your schedules, for calculations, represent in tags, etc. Then there is the data that you have clearly defined use cases for later in your design and delivery process or even construction process if your company is a contractor and not an engineering/architecture company. And these use cases should not be based on maybe/would be nice to have/potentially. There should be firm agreement on the use cases beforehand. It is an easy trap to fall into. If something is not in the scope of the work, then it is highly unlikely it will be worked on. In other words, there is no need to define every aspect of the element/object in question if most of that information is already present in some tables or text documents that come with the project. What will be the purpose of that data in the BIM model? Unless you are working on drawingless projects, keeping most of the data outside of BIM models in respective text documents is sufficient for everyday projects.
Reducing the data within BIM models can be done in several ways. Identify information that can easily be referenced to an outside source. I am confident that the majority of your data needs can be referenced through a few parameters in Revit. With the source material being in some database, Excel files, cloud solutions for handling data, etc. The idea is similar to what was expressed in the post I’ve linked to at the top of this article. Revit is not a platform to work with data, particularly large data sets, and neither is most of the BIM solutions on the market. With an excessive number of data types and entries, it is far easier to use specialized tools for that. Referencing most of your data out of your BIM software will greatly reduce your time spent on managing data and enable that data to be accessed and used more easily by other tools/solutions. This is what I would consider a true digital workflow in AEC. We often talk in the industry about data, but it has to be out there, within reach to be actually used. If it is all trapped inside your BIM models, it is not easily accessible, and you risk leaving it there forever.
Similarly, think of data that can be derived from one another. Often, some data fields can be redundant, and a certain piece of information can be used to derive other information. An example can be the mandated usage of a classification system. Instead of entering things like object names, etc, having the class of an object can be used to automate other entries with something like Dynamo, Python, etc.
Lastly, an easily justifiable reason to store more data in your Revit models is if it is part of your automation-based workflows with tools such as Dynamo for Revit. Having custom parameters in models that work in tandem with Dynamo scripts can open up more automation opportunities. However, this data is often not needed for the project delivery pipeline. Hence, it is good to think early about how to handle data clean-ups before handovers. Delivering too much data can be confusing, particularly when some of it only used and understood by you.
- Be strict in identifying the absolute minimum required data for your BIM models. If it is not specified in the EIR, BEP or other documents, you likely do not need it.
- All other data in your BIM models should be tied directly to your workflows and required use cases.
- Identify which of your data needs can be derived from other existing data in your models, either data that is natively present in BIM models like Revit projects or data that is already manually recorded. Automate processes through Dynamo in the case of Revit or similar tools for other platforms to ensure there are as little data that must be input by users manually. This saves time in data management later through reduction of time needed and mistakes made.
- Identify data that can be grouped together, structured and stored outside of your BIM software and easily accessed through a single point of reference in the BIM model. The growing digital workflows will only increase the amount of data we have. BIM models are good modelling and documenting platforms, they are not good data storage and analytics platforms. Try and use appropriate tools to maximise workflow efficiency.
- When explaining future implications, be clear about what potential use cases will be restricted and other potential limitations for the BIM process, project workflow when specific data is not collected. It is good to consider not just what you get with your data but also what you lose if you lack it.
Hopefully, this post will give you something to think about during your coffee time. Time is a precious resource, and we should respect it. Just because we have the ability to create and record large amounts of data it is not a sufficient reason to go overboard with it. Think ahead about actual data requirements of the project and the intended use case of the BIM models. If data can be automated, derived from one another, do so. There are quality cloud solutions, data storage and analytics platforms that can greatly aid in dealing with BIM data, leaving you to only reference it in your model as opposed to dealing with its entirety within a BIM platform. Heck, even Excel is more than sufficient in many cases to store and work with data fields that can easily be referenced in something like Revit through a common parameter. Take advantage of different tools as opposed to overly relying on one.
While on the topic of BIM data, there are plenty of good reads to be found. I cannot list them all, but a few I would suggest are presented below: