Bridge for Design Collaboration // Needs quality control tools

[Chad-Smith]

Introduction

Historically in a non-Bridged project the host has excellent control with dictating the structure of the Design Collaboration Teams and Docs folders. This can all be documented in project standards and even in the BIM Execution Plan.

But under a Bridged environment, all that quality control has been removed from the project host and reallocated to each party’s own project. It appears that this was a conscious development decision.

In Kyle Seyler’s ACC article, he says:

With Bridge for Design Collaboration, design firms and trades maintain their own standards—in their own project setup. This also allows teams to work seamlessly across multiple projects and improve upon established best practices and procedures. No longer do they have to form-fit into the digital environment they previously had to work in.

While the above statement and the current Bridge functionality has merit, as you'll see below it can also work against all teams. This is not just a Head/General Contractor concern, it's a concern for all project hosts who accept Bridged models.

This Idea post is to allow each project to apply standards to all incoming data, such as Team and File naming. This will address Kyle's comment above about allowing "design firms and trades to maintain their own standards—in their own project setup". A comment which is currently not true.

The Problem - Naming Conflicts

We noticed that when naming standardisation couldn’t be applied, conflicts and ambiguity can occur. This is not a desirable attribute in projects.

Take a common scenario of two Teams; Structural Consultant, and Structural Steel Detailer. Each of these teams from within their own project may name their Team the same; Structural. This makes sense.

When Bridging, the first team to share their Bridged package gets the name Structural, while subsequent teams will be suffixed with an incremental numerical indicator (1). Immediately, we can see that each incoming Team has no visibility of other Teams but yet they retain full control over their naming. Furthermore, there are no tools to correct the naming after they are Bridged. 

Another scenario is where a Team may only be sharing in an outgoing direction. In their project they may configure their folders to suit their own standards, which may mean they work and share packages from a folder called Work In Progress. They are after all the only team working in their account, so they have no need to name it anything different. i.e. Work In Progress makes sense from the perspective of their project.

In the below example, Project C, their project uses a Work In Progress team folder.

But when they share their package into other projects, their Work In Project folder and team name is also replicated into those other projects. This creates an even higher level of ambiguity.

In the below example, in Project B, you will see the ambiguous incoming shared package and folder. We certainly do not want this in anyone's project.

Going back to Kyle’s blog article about allowing individual projects to use their own standards, this can be to the detriment of other projects.

This is why each project needs quality control tools to standardise incoming Bridged Design Collaboration information.

[roy_peryea]

Hi Chad, thank you for writing such a detailed explanation for the problems you are experiencing. What you've described is the most common pain point I have heard as it relates to Bridge-related improvements for Design Collaboration. Unfortunately the Design Collaboration and Bridge teams do not have any near term planned efforts to provide a solution to this problem. However, I expect this would be at the top of the list for any Bridge-related improvements for Design Collaboration.