Naming is something I’m passionate about because when you get it right it makes everything on a project easier.
Here I will explain the ISO19650 standard (the international standard for Information Management using BIM) on naming. Having a standard for naming is really helpful, and on the surface, it makes it seem simple. All you have to do is create a naming standard, right? And then follow it. But how do you put that into practice, with all the nuances of a project? And how do you work out what that naming needs to be? How do you communicate it to all the different people who work on a project and then get their buy-in? How does this naming work practically with all the different software used and the different processes a container needs to go through? Now that is anything BUT simple!
Below I will cover:
- How developing a naming convention is harder than you might think and how just when you think you have it right a curve ball appears!
- Problems you might want to consider or think about when aligning how you work with the naming convention.
- Is the naming practical when you think of its use in different software?
- What to do when the menu is too big.
- Setting up systems that help everyone know what to do.
So, let’s start with what ISO19650 says
When I first read ISO19650, it used the term “Information Container” which I think is a pretty good descriptive name now I understand its meaning but I don’t hear many people use that term, so let’s start with this.
An “Information Container” is just something that holds or contains information. It could be a model file, a drawing, a PDF, a schedule, a database or a report. But the idea is every information container in named with a unique identifier and that’s where container attributes or naming come in.
The graphic below shows what the Australian standard says about naming.
The ideal world
So now we understand what the standard says, let’s explore some issues you may face in implementing it and the solutions to solve these issues.
In an ideal world the appointing party (client) would define the naming. They own the digital asset at the end of the project and need it to work with their systems. It’s the appointing party communicating what they want and how they need you to deliver their assets to them. We need ensure the data is produced in a way that can then be retrieved for the ongoing life of the asset. There is also no better way for the client to help appointed parties to work together and collaborate efficiently. A win-win!
However, what happens when that naming structure doesn’t quite work? Or needs adjustments to suit your project? That can become challenging (more on that later). On the other hand, not all clients follow BIM standards or have an established naming convention. This is where developing your own internal system for those projects comes into play.
Issue Number 1: Too much on the menu
Having too many options for people to choose from causes confusion and the team won’t be sure what to pick. Even if you have locked down your naming in your Common Data Environment (CDE) it can be tricky. The last thing you want is to have to create detailed registers, diagrams or micro managing everyone working on the project to get the naming correct. It’s not an efficient way of working.
So, my advice is to keep the menu simple, the list of choices as short as possible and set some examples for the team to follow. I’ll call this your “à la carte” menu!
Issue Number 2: Let the naming do the work
When designing your naming, it’s important to think about how you want all your information containers to read together. For example, think about a drawing package – ideally you want all the drawings you create to sit in the order you want to read them. Or, if you are printing a full set to create a combined PDF package, you don’t want to have to reorder manually every time. When you have hundreds of drawings or documents on your projects there are bound to be mistakes, not to mention the inefficiencies if you have to rely on manual processes! This is why it’s worth spending time to think about number and alphanumeric order up front when you decide your naming convention.
Issue Number 3: Have you covered all the bases?
Consult your team – you don’t know what you don’t know! Discuss with your team if the naming is going to work for every:
- phase of the project or the lifecycle of the asset from concept to design to construction to operation
- discipline
- information container type that discipline might need to produce
- software and the way that software is used.
Think about name length – is the code descriptive enough? Will dashes and spaces work with your software? Have you built flexibility into the naming? Think scope changes and variations.
Issue Number 4: Communicating with the team
So, you’ve agreed on your naming but now you must implement it. How do you communicate the naming, engage the team and make it easy for them?
The easiest way to implement your naming is to use a CDE and set it up with a fixed naming convention. But the real trick to this is to engage someone who has a deep understanding of how projects work and not just someone who knows how to use the software (hint hint, reach out to Marvel Engineers).
Next, you need to communicate with your team. If no one knows what they are meant to pick or how to use the CDE software people start squirrelling away the information containers in all kinds of hidey holes, on their desktop, or create new folders! So, create naming guides and add to the BIM execution plan (BEP). Refer to it regularly, use it as a live document and have it somewhere easy to find. Talk to the team, show them, engage with them as you’re setting up the project and provide examples. Sell the importance of the process and do what you can to unlock doors for them. Get that buy-in early and regularly.
Start with your à la carte menu, but be ready, open and nimble enough to realise there will be some things that have been missed. Revisit the naming and be ready to add in what’s missing in a timely manner – people can’t be waiting during a live project.
Learn from each project and refine that naming. The first project might be difficult and time-consuming to set up but once you are done you just need to tweak and your team will become more familiar with this way of working. It builds efficiency because you’re not reinventing the wheel every time.
Issue Number 5: It seems impossible for the Appointing Party
I believe this naming should ideally come from the appointing party as it allows everyone across the industry to be able to collaborate and work together, but it may feel like an impossible task for them to get it right because of, well, all the above!
Design teams need different naming to construction teams to operations teams – all have very different needs. It can be hard to make one naming convention work for all without the menu becoming too large. And this is where the Information Requirements (IR) and BIM Execution Plan (BEP) really help. This was covered in our previous LinkedIn posts so check them out on our LinkedIn page.
Conclusion
As you can see, naming correctly is a powerful tool for efficiency but it also takes consideration and collaboration to get it right. In essence, to quote from Operam Academy – it’s all about helping “the right people, get the right information at the right time”.
If you want to understand more on the naming and BIM, then have a read of the ISO19650 Standards or do a course like Operam Academy.
Read more about BIM in our blog BIM demystified: Making sense of the acronym.
Please reach out to us if you’re seeking support to meet your BIM requirements.