Shared BIM library objects
The objects in a shared BIM library
A shared library is a system that relies on tangible content, such as 3D files. But it also relies on intangible elements such as processes.
Here’s a list of everything it may contain:
- Recommended and mandatory classifications
- Recommended and mandatory properties
- Graphic objects shared between designers
- List of properties by object type (shared between engineers)
- Object documentation (rules for using objects for example)
- Processes & governance
- new object requests,
- existing object updates,
- user invitations, etc.
Basic and optional BIM objects
In reality, a shared library is rarely so comprehensive. Depending on your culture, your model projects and your BIM maturity, only certain elements are relevant. There are 3 levels of BIM maturity (with the lowest maturity level being the most common):
|Basic level||Advanced level||Advanced level|
|Tangible elements||A shared library contains:||
|Intangible elements||Made by:||1 or 2 members of the design team||A dedicated modelling team||All project teams and partners|
|All the design teams:||All the design teams||All project teams and partners||All project teams and partners|
*Object model = properties of transversal requirements by product type
This is a common data structure defining the properties (the product’s essential and non-essential characteristics such as being fireproof or the colour) describing any type of product in a way that will result in a credible and usable 3D object.
The BIM maturity levels described here are inspired by the BEW & Richards diagram. Organisation is essential for intangible elements, as this enables you to determine the interactions required for the tools and the valuation of the activities associated with the tangible elements:
How do you set up a shared BIM library?
At BIM & CO, we see the creation of a shared library as the creation of a new model (and not as a project with an end date). Like any model, it must meet the needs of a given target (project management, operators, facility manager, etc.). It must also add value over time.
The keys to getting started: building the framework of your shared library
The first step is to establish an inventory of how the teams work. You also need to clearly identify the problems that can be addressed. Once this analysis is complete, you need to define and prioritise the objectives, set the scope envisaged and last but not least, set and share the success criteria for the shared library.
Main questions you need to answer to properly create the framework for a shared library:
- What are the project teams’ needs? What support elements have they requested?
- What is the scope? How many models or teams should this library enable you to align?
- What are you going to put in the shared library?
- Who are you creating the shared library for? How many people will work with this library?
- How many existing models will be impacted by the shared library?
- What technologies should you use?
- What type of classifications and properties do you want to share communally between the various models, professions, and project phases?
Progress step by step
Once the objectives have been defined, we advise you to set an initial scope that your shared library will address. Like a model, restricting the scope and tangible elements you integrate will enable you to deliver and iterate quickly. This means you get fast results and easy fixes. You can add to this scope over time, making sure you always keep in mind the objectives you set and the criteria for success.
For example, if you are managing various different models and what already exists in terms of objects is already a lot. It is unrealistic to want to cover everything in the short term.
A prerequisite for defining the shared library’s scope (and convincing people of the need to make one) may be to take an inventory of what already exists. This means listing the different types of objects (recurring) and sets (phases, jobs, types of projects) used in the model. Each member in your various teams (designers, as well as business engineers, for example) can contribute by providing screenshots to exhaustively catalogue what already exists. The inventory will enable teams to:
- See the inconsistencies if there are any.
- Identify the items that can be reused.
- Prioritise what will be developed first.
Establish the creation principles and technological choices
You have to set out the creation principles as a foundation first, before you even think of starting the property set creation phase. These principles will guide and inspire your designers and engineers. For example, if one of your core principles is to maintain a specific use of reference lines in Revit, all your objects might want to contain a screenshot of what’s in the RFA to make it easier for the BIM experts to confirm compliance. Any items that do not comply with this document will need to be improved before publication.
The question of technological choices is key when initialising the shared library. But it should not be a constraint on your shared library. Your shared library must be technologically agnostic, e.g. it needs to be designed independently without a specific technology bias, while remaining compatible with all the main technologies in your business. This helps to create an experience that is recognisable with and suited to various different software programmes. To put it simply, it is up to the library to drive the choice of a centralised space and not the other way around. Also, consulting and getting a Technical Director (CTO) as well as business experts to cooperate on this is essential, and this needs to continue well beyond the first implementation phase.
Find out how to set up the human organization around your shared BIM library and how to measure the success of a BIM object library in the third part of this blog !