BIM Busters - ISO19650 enhances communication

About the engineer's dream of solving communication issues with a common language. Read more about the issue and a proposed solution.

I don't believe in God, but I believe that our ancestors had a lot of wisdom and translated it into stories.

You might know the story of the Tower of Babel. God punishes the people of Babel for their hybris to want to reach heaven with their collectively built tower. The punishment is that they don't understand each other anymore and fail.

My interpretation of this metaphor is that we still live in the times of Babel. We still don't speak a common language, and every attempt to create one -that would enable us to reach heaven - is punished again.

That's because every unified standard we create adds another layer of complexity and confusion. The punishment continues.

About ISO19650 terminology

So, my issue with ISO19650 is that it's overcomplicated and does not speak an understood language. The overcomplication separates even more than it connects, and people get put off. Therefore, it's counterproductive, bringing us further away from heaven.

One of the comments on my linked posts to this topic goes so far as to call it "a rare junk, stylistically written by an alien preschooler". And gives this example:

At least some of the planning for information delivery should be carried out by the lead appointed party or appointed party before appointment, as this should form part of the review carried out by the appointing party.

Calling it written by an “alien preschooler” may be an extreme formulation, but I do understand the underlying resentment.

I have been teaching classes about BIM management/project management with digital means for five years and have interacted with more than 200 great people from different disciplines, ages, and experiences. Some of them have already worked with BIM, and some have never seen a model. But all of them have practical experience in their jobs. So sometimes, I have 150+ years of combined building experience in the room.

NOBODY told me that the ISO19650 terminology was helpful and a language they understood. Again, this isn't very objective, as I introduced the ISO after spending four days teaching principles and techniques. And these core principles are the same as ISO19650 wants to convey!

For example core principle I try to convey with discussions, role plays, and my teaching is:

You must communicate your needs as somebody who wants to do something with the data. Everybody is allowed to formulate needs, and everybody who expects data has the obligation to formulate their needs, regardless of their hierarchical position. The needs can come from the construction company, client organization, facility management, or project team.

For example, let's assume you have a construction company doing concrete work and want to use BIM on site. So far, you have received plans. Some were better, some worse, but you had enough experience to work with them.

Now, you receive BIM models. Every engineer follows another standard and uses other attribute names and values for concrete type, formwork quality, and reinforcement steel... Moreover, some engineers create one model, others only export the building, and others every single stage.

Your on-site team can't work like that - they are inefficient when exploring and clicking until they find the information they need.

So the solution is to have some kind of standard and there are two paths to get standardized models:

1. You do them yourself, according to your needs, either by modeling everything again or by wrangling the data to the format you need.

2. You talk to the engineer and ask that they export according to your standard.

Both strategies are valid, and I recommend a mix of both. But the core message is:

The company that must use the data, is allowed to communicate their needs!

The other party is allowed to ignore your wishes; there is no legal obligation to fulfill them, but as they have the job of planning so that something gets built, it would be nice if they listened.

The lean management principle addressing the same is called "involving the last planner" the person who does the work.

Unfortunately, this concept is foreign to many people in the industry, and many look at their own silos. Many construction companies even got socialized with a mindset of not wanting to ask because we won't get it anyways and don't like to offend.

Translated to ISO19650 "speak" this sounds like this:

"The appointing party needs to communicate their data requirements to the appointed party lead and the appointed party. To do so, there are different documents:

OIR – Organizational Information Requirements  

PIR – Project Information Requirements  

EIR – Exchange Information Requirements  

AIR – Asset Information Requirements

My issue with this is that:

1. Appointing and appointed parties are phonetically very close. So it's very easy to mix them up.

2. 2. It's easy to believe that you have to have a contractual requirement to formulate a relationship for information exchange. In project reality, this is often not the case, and information has to follow channels other than the contractual ones, e.g., the planner—construction company. Therefore, the term appointing party is misleading as it implies contractual relations.

3. 3. OIR, PIR, EIR, and AIR are often interpreted as documents a client needs to prepare. And many people believe because it’s written in the ISO that without these documents, BIM is not possible.

   The ISO's spirit wants to create awareness that requirements come from different levels. (To see them as separate documents is a great hook for consulting companies selling client organisations these documents.)

Another core principle of my class is:

The client should formulate WHAT is needed, as well as the deliverables and the quality. Explaining the WHY helps the team find better solutions for the root problem.

The project team's job is to formulate HOW, WHO, and WHEN they solve the problem.

To give an example, the client does not have to tell the team to use BIM. They just have to formulate their data requirements either for handover or for the project’s quality management. So instead of ordering “clash detection,” the client should ask the team how they ensure geometric coordination before starting to build. And when the team should be held accountable to this!

Translated to ISO19650 speak:

The lead appointed party answers the OIR, PIR,EIR and AIR in a BEP (BIM Execution Plan).

I was socialized in a pre-BIM era and worked on projects with a "project handbook." I learned that just having a document does NOT help in project management. It's all about implementation and how you foster collaboration in the team. The document can help, but only when you foster a good culture. So, I would always prefer to work on a project without a formal project handbook / BEP but with a great culture!

Proposed solution

What I just did was sneaky and manipulative. By giving you these examples I explain some principles behind the ISO19650. And the underlying principles I wholeheartedly support! I just believe there are better ways to communicate these principles than a norm. For example, directly talking about the core principles instead of hiding them behind a vail of obscure language:

1. The entity issuing a job or needing to continue with other people's work is responsible for defining the specifications/requirements.

2. The entity executing the job is responsible for fulfilling the requirements.

3. The entity receiving work results is responsible for checking if the deliverables match the specifications and requirements.

No rocket science and nothing completely new! Having a norm is just the engineer's dream of reducing complex human relations to a rule-based (complicated) system that can be described. Many comments mentioned this: “ISO19650 may not be the best, but it's a starting point, and it helps us communicate to the clients the need to get active."

I want to propose a different approach - a psychological one:

Let's get better at communication and embrace meta-communication—the communication about communication.

In other words, we need to learn to listen and ask about the needs of the other person/organization. And the flip side is, we need to get better at the communicating that we need.

So, to escape God's punishment for continuous misunderstanding, we should not fall into the pattern that created the problem in the first place. We should not succumb to the hubris of wanting to reach heaven by building another (ivory) tower—in this case, ISO19650. Instead, let's focus on the fundamentals: communication about communication.