Accelerate Project Delivery: Standardizing Cloud-Connected BIM Coordination

RONALD LOGGEN: Welcome, my name is Ronald. And thank you for joining this Autodesk University class on standardizing cloud connected BIM coordination.

Joining me today are Alex and Bushra from WSP. In this class we walk through the journey WSP and Autodesk have done on accelerated project delivery for standardization workflows, including all of the ups and downs, and all the things that went wrong. Bushra and Alex will tell all about you, all about that.

I'm a senior consultant at Autodesk. And I've been a registered architect for the last 20 years. And I've been working as a BIM consultant for the last 10 years.

The last four have been with Autodesk. My primary expertise is data management and collaboration. The last two years focusing primarily on BIM 360 workflows that could include BIM 360 Glue, Navisworks, and, of course, BIM 360.

I've been supporting WSP for the last four years across the globe on all things related to BIM 360 and cloud collaboration workflows. Let me continue by introducing both Alex and Bushra from WSP, which whom I've had the pleasure of working with for the last three years.

ALEX LALUMIERE: Thanks, Ronald. On my end, I started-- been in the business nearly for 10 years now. Started on the production side. Started with content creation on Revit, helping teams here and there, and slowly but surely made my way to BIM management.

I've migrated to industrial and building a couple of times in my career so far. Made a pit stop in architecture. So seen kind of an all around when it comes to Revit, BIM management, and all.

And for the last year or so I've been joining the digital practice team that WSP has created. And I've been taking care of BIM 360 and BIM planning side of things for over a year now.

BUSHRA ABOELEZZ: Hello, my name is Bushra Aboelezz, the national BIM lead and the BIM manager at WSP Buildings Canada. I have over 30 years of experience in building industry. I'm a licensed professional engineer in Ontario, Canada. But my prime expertise is really Revit and BIM 360.

I'm very passionate about advancing engineering solutions using innovative BIM processes that can effectively bridge the gap between engineering and drawing production, which is always, I found, there is a lack of integration between those two, especially with my background as a structural engineer.

I joined WSP eight years ago, focusing on the development of BIM standards for the national team, including BIM execution plans, content creation, templates, and all the stuff that goes with BIM.

I'm really committed to staying up to date with the new technologies. That's why I've developed a great interest in BIM 360 and joined the BIM 360 committee, being one of the expertise in it, often pushing these boundaries a little bit higher level. I also play a BIM coordination role in many projects where it gives me the opportunity to explore new techniques and new tools.

RONALD LOGGEN: Thank you, Bushra. In this class we'll show a couple of things. We've broken it up into four major parts. The first part will be on Canada's journey on how the BIM 360 workflows have been used and integrated.

We'll show you some learnings and some best practice from that journey. We also show how we standardize, and what we've standardized, and all the things that we've learned, and all the things that both Alex and Bushra have experienced on working with these standards on their projects. And in the end, we'll show you the value of what actually helped WSP accelerate project delivery.

ALEX LALUMIERE: Thank you, Ronald. First, maybe a quick intro to who's WSP, if you don't know us. So WSP is one of the world's leading engineering professional service consulting firms. We're a technical expert who design comprehensive and sustainable solutions and engineer project that will help society grow for lifetimes to come.

So we have a pretty good international agility as well, over 40 countries. We have around 47,000 employees in 550 offices. This is giving us a lot of experience and a lot of depth to what we're creating, because we're trying more and more to get in touch with other offices around the globe and see what their experience is, the work that they've done so far, and how we can join forces to create new standards and improve our practice.

So inside Canada, we have multiple business lines, including transportation, property, and building infrastructure, energy, industry, and resource, and environment. We are 7,800 employees. And within the property and building, we are 1,700 employees. We touch areas such as commercial projects, educational projects, government, health care, hospitality, transportation, and others as well.

BUSHRA ABOELEZZ: Can I add a few things? Work sharing is really very important to us at WSP, as we draw expertise from all over the country. So some of the BIM solutions that we're going to share with you on this class, it really is imperative to ensure the success of this work sharing strategy at WSP.

ALEX LALUMIERE: Absolutely, that's a great point.

RONALD LOGGEN: So let's start with the journey. We've met a couple of years ago. I met Bushra at Autodesk University two years ago, live when we still had the opportunity to see each other face to face. And from that moment on, Bushra asked me on guidance and support on specific BIM 360 workflows on a specific project that Bushra was working on. And here today, Bushra is able to tell us a little more on that specific project.

So one of those projects is the Ottawa Confederation Line Extension Project. And Bushra will be able to tell you a lot more on this particular project.

BUSHRA ABOELEZZ: Yeah, so I'll just walk you through some of the interesting aspects of this project. Besides that it's a large project, first, the project name is the Ottawa Confederation Line Extension, which is a light transit project that runs East and West through Ottawa downtown. The client is the city of Ottawa, along with East-West connectors.

In this project, WSP and Hatch formed a joint venture partnership to design and engineer the second stage extension to this line. We were joined by two great architects, Diamond Schmitt and Perkins Will. And as the video is playing, it's just showing you this line consists of-- the extension consists of 16 stations plus light maintenance.

And the storage building. The east extension has five stations. And the west extension has 11 stations, plus the maintenance facility.

So what's so interesting about this project? I mean, everybody has large projects. The things that are interesting to me is that it has 20 structural [INAUDIBLE] that makes up that 11 stations. Also, there is like 32 companies.

It's a multidisciplinary collaboration. There's 32 companies, including the construction managers. And it's 27 kilometers of rail. And the project value is $2.6 billion.

The project consists of a build and design of a 4 kilometer cut and cover tunnels, 20 engineering stations, and the maintenance facility. Although these stations have so many common elements in the design, but they are still different, they consists of stations that are on grade, below grade, and on a bridge. So there are many challenges and interesting aspects in this project that I will share with you as we go.

RONALD LOGGEN: Now, this is an example of how Bushra reached out to me. When we started in 2019 at Autodesk University, she reached out to me. And it was a challenge.

Like Bushra said, it's like doing 17 projects into one. And all of those challenges, from managing permissions, managing a folder structure, how do you exchange so many models, how do you structure that, how do you make that project workable, that's something Bushra, me, and Alex I'm hoping to show you, and all the things that we've learned on those workflows.

BUSHRA ABOELEZZ: That's right. So the first challenge as a BIM coordinator is just to kind of talk and discuss the project with the design BIM leads, and to bring them all together, and decide on the common data environment.

We were all in favor of BIM 360. We all know how to use BIM 360 in many projects. But for a project this size, and how to adapt those workflows, it needed a little bit of serious thinking.

So that's why I had discussions with Ronald. I had discussion with our BIM 360 expert at the account level on how to set it up, what to do, how to make this work. With the initial data that we have, I mean, I knew it's a long project. It's going to go along for four or five years.

It's a transparent project. We wanted a BIM workflow. So we were bringing everybody here, including the construction manager. So how to make this work for everybody?

So BIM 360 was the choice. And what we're showing you here is just some of the statistics after two years in this project. So up to last week we had like 652 project members. As mentioned before, there is 32 companies.

There are 17 buildings with 8 or 9 disciplines per building. So there is a large number of design collaboration teams. Also, we have a 20 model coordination spaces. These models, we have to share them weekly.

And we explored all modules of BIM 360. So model coordination was used. And up to now, we have over 3,000 issues created in this project, mainly on model coordination.

ALEX LALUMIERE: That's a good summary I think on the vastness and the complexity of the project. Let's have a look at how you worked with design collaboration.

What I'm seeing here is a lot of stations and a lot of disciplines. Can you tell us a little bit more about that, Bushra?

BUSHRA ABOELEZZ: Yes, so that was really one of the challenges. I did lose sleep over this. I started with a different approach first. Try to make it simple. I mean, probably you're asking, why so many teams?

Like, I mean, you said, 7, 8, 9, whatever disciplines, even 10. But why do you have so many teams? There is over 130 teams. And really have to think of a way to make sharing and consuming models easy. We want to have an easy way for team members to go through this and figure out which models have been shared, and what to consume.

Like we knew we're going to have a large number of models. So how are we going to make this kind of an easy for everyone to do, or to go there? I mean, we needed to use design collaboration. We couldn't avoid that.

We didn't want to do live linking. There is a lot. We have to control when models will be shared, and also give each design team the control of the information that they are sharing and when to share it.

Also for this project, we needed to create a model of [INAUDIBLE] protocol to work with the schedule, the station schedule. So like the architect will freeze the model two weeks prior to submission to give the rest of the team a chance to catch up with the design. So how do we make this easier for everybody?

So I ended up creating a team per station per discipline. And that's how we ended up with this. Also, with scrolling through 130 teams, it's not easy. So we color coded each station just to make it more visible for the team when they are in certain stations to consume or share the models that they want.

So this is really just lowering the risk of consuming the wrong model, or sharing the wrong model. As you can see here, there's over 200 shared models. And so far, I guess Ronald did the math. And there is almost 9,000 shared models version. So also design collaboration.

And this project, it just allows us to have this visual sharing history so we can always go back and look at these versions, and see when this happened, and what happened in that model. So that was something big for us.

One last thing that is very important is we didn't want this space to be only for the modelers to go there and share models, and link, and all that. We really wanted to bring all the team in here. So this was a good place for the non-Revit users to come in and look at the federated models for coordination.

So that color coding too helped us to achieve that. And having those separate teams per station allowed everyone to go to that station to look at the Federation model of that station. So it made it easier.

I was worried about this. And I was worried about introducing this to the team, because I feel someone is going to be really upset at me when I tell them, you got all these teams. But it was very well taken by the team.

ALEX LALUMIERE: And you also mentioned that you were using model coordination. Can you briefly elaborate on what made it special to have model coordination working on CLE?

BUSHRA ABOELEZZ: Well, we wanted to really do the model coordination and clash detection early in the project. We didn't want to wait until the end, until construction, or very close to construction.

So we had a choice. You know, by just going with the traditional workflow, with Naviswork-- nothing, I mean, wrong with Naviswork. It's a great software. But for a team this size, it was not easy really to use Naviswork, and to teach everyone, and show them what to do.

We also wanted something that is more intuitive and engaging. So you're working on this project. You want to be able to look at the clashes right away, especially when major changes are happening. So you didn't want to wait until you get the report from Naviswork. And a lot of time people will leave it aside and say, well, I'll look at it later. So this was a more intuitive way.

But there was some issues with BIM 360.

RONALD LOGGEN: Yeah.

BUSHRA ABOELEZZ: When we submitted this project was on the plans, right? So I have to find a way to work with the plans.

I mean, it's so many models to download them from project files, upload them into plans. That was going to take a long time.

RONALD LOGGEN: Yes, and we'll touch on that in a couple of minutes. We'll show on that how you resolve that with Bird Construction also.

Alex also did a project. It was kind of something similar to CLE. On the other hand, it was completely different. Alex worked on the Energy Service Acquisition Program, also a project inside Canada. Alex, would you be able to tell us a little bit more on what made ESAP for you a special project?

ALEX LALUMIERE: Yeah, absolutely. Thanks, Ronald. I think I'll present this project very briefly, because the challenges we had on ESAP and CLE were similar in a certain fashion.

[CLEARS THROAT]

Pardon me. The client was Public Services and Procurement Canada. We did this project with BBB Architect. And it was a Petrie project as well with Black and Mack and PCL. So it was a very interesting project in that sense.

Other fun fact or complication that we had on ESAP is it was five cooling and heating clients. So it was kind of, again, the problem with having five projects into one. Plus it had a distribution network that were separated models, separated environment as well. And we ended up having over 80 buildings to at least do a portion of those buildings for the heating and cooling distribution to them. Project value was over $1.1 billion, which was a fairly large project for us.

RONALD LOGGEN: And like we said, Bushra's project had a lot of people working on that. You had that same challenge, that full permission, those permissions. Can you talk us a little bit about that?

ALEX LALUMIERE: Yeah, absolutely. I think the permission issues were something present in the project. At first where we didn't really know which direction to take, we had over 340 project members.

We were wondering if we went with companies, if we went with roles. At the time we-- well, we still can't merge companies and role to give permission. So that was kind of a challenge within our folder structure.

And we were using the issues as well. So we wanted to make sure that everybody had the right permission to create the issues, review the issues, and all of that. We decided to go with an approach aligning with ISO 19 650, with the work in progress shared, published that we called submission for everybody to understand on the project and the archive workflow.

So this facilitated a bit the permission setting [INAUDIBLE] folder. But still some challenges there.

RONALD LOGGEN: And looking at, for instance, a design collaboration, did that workflow change from Bushra's ESAP and the CLE project? Or was it kind of similar?

ALEX LALUMIERE: It was similar, but different, I guess. The challenges were, again, the same at maybe a smaller scale, having those multiple projects in one.

I think the main difference that we did is instead of going one color per plant, for example, we went with one color per discipline, simply to-- for us it was to lower the risk of consuming under the wrong discipline if permission weren't set correctly, or if in an administrator was tasked with doing the consumption or sharing of a model.

So it was a bit of risk management there. And with some feedback of the user, it was easier for them to find their discipline. We had a proper naming convention. So it was easy to manage the plants in themselves.

So that's the main difference, I guess, that we have in the two projects.

RONALD LOGGEN: And looking at model coordination, I can understand because it's a plant project that you would have to do some advanced tweaking or advanced workflows on specifying and filtering out all those different piping networks. Can you tell us a little bit more about that as well?

ALEX LALUMIERE: Absolutely, without going into too much detail, because we're going to touch on that later on in the presentation, but at first we tried the approach of BIM 360 with what I would call the standard approach, clashing one model against another.

Which raised more eyebrows than anything, because you see that big, scary number of 5,000 clash or 6,000 clash. And everybody gets confused. The coordination meetings are endless.

And at one point I discussed with Bushra. And she presented what she was working on for CLE. And I thought it was a very, very clever idea. So I simply adapted it to our reality in our project.

As you can see here, we couldn't just clash all the piping against all the ducting. We needed to be a bit more granular and go by system. We had some chilled water piping, for example, where the pipes were almost two meter in diameter.

So we had to do that interdisciplinary coordination as well. We did consider using Naviswork at one point. But it wasn't as accessible to the project team member. And one of our goals within ESAP was to deliver a clash free model, that famous clash free model based on a clash free definition.

So we really needed every actor on the project, every people working on this project to be proactive when it came to clash, and not just wait for a monthly report or a weekly report of clashes.

RONALD LOGGEN: Sure, sure. So if we recap, if we take all those learnings, and all of those challenges, it basically covers these four parts, having multiple projects into one, managing the permissions, managing the folder structure, and managing the limitations.

And I would like to go over all of those limitations very briefly with you. So the large projects and large project into one, we could have chosen to basically create 17 separate, maybe 50 projects.

That on its own would make each of those separate projects easy to manage. But then you wouldn't have any collaboration. You would have had difficulty exchanging files or treating it as one big project.

So both Alex and Bushra chose to create one singular project. And inside of that BIM 360 project, they've created 17 mini projects as a folder inside of that work in progress shared published and archived ISO standard.

And one of those things that becomes a challenge is two things. It's managing permissions and setting a folder structure, because those two are related. Could you tell us a little bit more, Bushra, on managing that permission? What's the biggest challenge for you on managing permissions?

BUSHRA ABOELEZZ: Yeah, so managing permissions. Until this project, we were always using companies to manage permissions. It was easy. You know, you have one discipline from each-- one company per each discipline. So it's very easy to use companies.

But then for this project, I knew this is not going to work. So after having some discussions, we decided to go with the role. Because even for the same company, we wanted different roles for the people who are in the same company.

We didn't want to give everybody from the architect the same role. And we didn't want everybody from the structural team to have the same permission to these folders. Because yes, we did want a transparency, but we still wanted to maintain the integrity of models, of the Revit models. And we want to make sure nothing is going to happen to them. So that's why roles made more sense.

But then looking at the role that came out of the box from Autodesk, there wasn't enough roles there to set this project. Because we have two different architects. We have two structural engineering disciplines. We have two mechanical and electrical. So we needed to come up with a way to create those roles.

So that's where I started working on how to create those roles, and what kind of roles we wanted to create. Also, the role was important, because the permissions to the folders starts with the main folders and gets inherited to the subfolder. So that was another thing that we needed to think about.

And just like Alex mentioned, we couldn't really mix companies and roles. So it was a little bit easier for me to go with the roles.

RONALD LOGGEN: And, of course, another combination of permissions and folder structures is that link to the folder structure. Like Bushra said, it's a challenge. Do you have a folder structure which has a side building discipline structure? Or do you have a folder structure which has a discipline inside building folder structure?

And having run these two projects, we've come to the conclusion that that's a difficult decision. That's something the project needs to determine. Sharing information, the relationship between design collaboration and teams, the number of different disciplines, working with different parts of the project, the number of project teams, that all influences if you choose a specific folder structure or not.

The main challenge is it's more or less a BIM 360 limitation. The limitation of permissions, unable to be grouped. And the company and role permissions. Inheriting automatically a folder permission makes it challenging.

You can always increase permissions. You can't decrease them. So those limitations kind of determine what kind of folder structure you need.

Like Bushra said, model coordination also had its challenges. Also has its limitations. When we started with CLE there were like 10 model coordination spaces. Bushra's project had 20 stations. So we really, really needed the ability to create 20 coordination spaces.

Also, model coordination was available in the plans area. It was very difficult to get those files over there. Bushra, together with Bird Construction, created kind of a workaround using a Revit file as a container. Which in the end proved to be very valuable. That container fill allowed both teams and a lot of projects to kind of curate, and to manage permissions better.

Lastly, design collaboration. Having 100 teams is a challenge in scrolling. And of course, the limitation of only being allowed to publish once a week was also a limitation.

What we saw was how do you learn from these projects? Whenever you do a new project, how do you learn all of the things that we've done on these large projects? And if you want to create a new project, how do you keep that knowledge? And how do you keep that expertise?

It has to be scalable. It has to work on a large project. It has to be efficient. It has to be tested on those small and large projects.

We needed to have that documented. We needed to accept certain limitations, but also find workarounds on those limitations. And this is where both Bushra and Alex, and the committee that we created really excelled. Because we learned a lot of things.

And we noted all those challenges. And we tried to standardize. We tried to standardize on how could we create a workflow that works on big projects, works on small projects. What else can we standardize?

And, of course, having me in that committee as Autodesk allows me to give both Bushra and Alex, and all of the other teams insight into what was possible. I could talk to the product development team and say, what's on the roadmap? What's coming up? And allow project support.

We had a weekly meeting where both Alex, Bushra, and all the other team members from that committee asked their project support.

ALEX LALUMIERE: Yeah, absolutely. That's a great point, Ronald. I think we cannot take all credit to ourself. We had a great team within the BIM 360 [INAUDIBLE] with Marita, Gurinder, Marita Maluku, Gurinder Raka, [INAUDIBLE] McLean at one point.

And really we just-- it was a team effort. And with Autodesk support, with your support, Ronald, it was really key to how did we get there.

BUSHRA ABOELEZZ: Yeah, and we really argued about a lot of these topics. And Ronald was the one here like giving us an insight.

And I mean, it was all with passion, and all for good reasons. And that's why we ended up with something really great.

ALEX LALUMIERE: He was often the mediator.

[LAUGHTER]

RONALD LOGGEN: And talking about those standardized workflows, these are the four parts we decided to standardize. Like we said before, it had to be scalable. It had to work for a large project. It had to work for a small project.

So we decided, what are the things we can standardize most easily with the least amount of effort? And we walk you through all of those four parts, the BIM 360 project setup roles and project setup.

We'll talk about document management, the folder structure, and the permissions, the sharing workflows, and teams in design collaboration. And that clash matrix that both Alex and Bushra alluded to in the couple slides before will show you all the details on what we did, how we did it, and how that helped to enhance project delivery.

So Bushra, would you tell us a little bit briefly on the roles and what we did for standardizing roles?

BUSHRA ABOELEZZ: Yes, so first we have to come up with a naming convention that will make it easy for everyone to follow. We knew we're going to have so many roles. We didn't want to really overwhelm everyone when they scroll through this and see so many roles. And we wanted something that they can filter.

And we wanted something that's going to work for us internally and externally. So what I did with CLE, I used the company name and the role, company name, discipline, and role, you know? Or what permission I want to give them.

But when you think about it, I mean, we work with 100 companies. We don't know who we're going to be working with. So that approach worked for CLE because I was just limited thinking about that project. But then when it came to something national, then we needed to come with a different approach.

So we decided to come with a naming convention that's versus the discipline and the role, the location, whether it's internal or external. And because we are in Canada, we're a multilingual country. So we have to use French and English. So that's why we added the language to the end. And this really allows us to filter through these roles very easily when we were setting the permissions.

RONALD LOGGEN: Good, and if you look at the folder structure, Alex, would you elaborate a little bit on how we came about, or you came about with the folder structure?

ALEX LALUMIERE: Absolutely. I think, based on our experience of everybody on that committee, we brought something to the table. And really we all agreed to align with the ISO 19 650, since truly this aligns very well with BIM 360.

And that work in progress, shared, and published workflow really summed up well, and ties in everything together very well. So we went ahead, and under work in progress, we started listing all the companies-- not the companies, but the discipline that we would need on a typical project.

And we tried to do something that would be useful for a small or a large project. So it's easier to remove than to add on your project for efficiency gains. And then inside of all those disciplines, we started tying up our workflows, our intended workflows, and created the folders that would be mark up model PDF and reference. And just go from there.

Within the publish environment, set up our internal submission. And making sure at each step of that folder structure that our workflows that we add in the back of our mind would work with this folder structure, because this is truly the backbone of our strategy and standard.

This is what everybody is going to see when they start a new project. And it needs to have a space for everything that we wanted to have as efficient seeking workflows.

RONALD LOGGEN: And, of course, that ties to the design collaboration. Because those folders and those disciplines are tied to the design collaboration team. So now that we have the permission standardized, now that we have the folder structure standardized, the next thing what we could do was standardize the design collaboration workflow.

So every discipline inside of the standardized folder structure would have its own team inside the design collaboration team. The only thing that interested me, for instance, if there is a design review model team which isn't the real discipline. Could you tell us a little bit more about that?

BUSHRA ABOELEZZ: Yes, just like I said, we learned from CLE that the design collaboration module has a lot of attraction to the engineers. So this is where we wanted the designers be-- instead of waiting for the modelers to give them an overlay of Revit models, and then they can look at it, why not come here?

So to make it easier, so that's where we created this design review model, which is kind of a team that can consume the models for everyone. So instead of each discipline consuming the other models so their team can go to design collaboration and look at the federated model, we created one team so this consumption can be done once for the entire team. And everyone can go there and look at the federated model.

So we really cut the time to a quarter, or even less than that by doing So. And that made it easier to apply to all the projects in this case, instead of just having it with larger projects that allow you to do that.

ALEX LALUMIERE: Yeah, and I think, Bushra, one of the other benefit of that is where we draw a line between the issues that we would create for clash coordination, and the issues that we would create for design review, where in this environment, everybody has access to all the issues that are created within this fake team for design review basically.

BUSHRA ABOELEZZ: Yes, that's right.

RONALD LOGGEN: And now that we have design collaboration, you could also use that team to fill up your model coordination. So what we saw was that Navisworks, as it is a good tool, it's also limited, because not everybody knows how to use Navisworks. It's a disconnected workflow.

So on these projects, you decided to be more proactive, and to be easier to learn there will be a web browser. So you don't have to install or need Navisworks. It's an integrated workflow.

The only thing of interest is, what's the actual purpose of that Revit container file? What does it actually do?

ALEX LALUMIERE: So really the container file, when Bushra presented the idea to me, I thought it was extremely clever. And basically it all ties well very good to the model coordination aspect, where instead of having, again, as I mentioned earlier, one model clashing against another model within Revit, and utilizing the categories and the views that we can now publish inside the project folder, we can create all of those subcategory of views.

So using the category system, model element category within Revit, we can filter in each of these views only the element that we want to see in each of the links of the project. So within that container file, we link every other files. And then we create those views.

And for ESAP, what I had to do is not only use the model category of element, but also use filters. So the neat thing is that filters go through the link. And I was able to recreate the system within our model container file that we had inside our project files, and simply filter the pipe fitting, pipe accessory by the system of those views. So we were able to get something that was very granular and that supported our coordination tremendously.

RONALD LOGGEN: And, of course, another advantage is, it doesn't matter. All of those links, how they are structured, you could use that container file to structure your clashes. And you could end up with the same class metrics every time.

BUSHRA ABOELEZZ: And that was something very important-- sorry. That was something very important for a project like CLE. I could not really rely, talk to Ronald at AU. He mentioned AU 2019, and he explained everything to me about model coordination. And I knew what to do.

But I just couldn't really rely on 400 users to create those 3D views with some kind of naming convention, and guarantee every time they publish the model or share the model they're going to publish those views. So this gave us a little bit more of control over how to standardize this model coordination and make it easy for everyone.

ALEX LALUMIERE: Absolutely, and I think within BIM 360 now we can even create views in the model coordination environment. And we can reuse those views within the clash environment to create smaller matrixes.

So the picture you saw, which was the larger clash matrix, you can actually crop it within one view with five or six categories if you want. And you can pre-define and standardize those views that you're going to create to speed up the process of model coordination on every future project.

RONALD LOGGEN: And Bushra, you mentioned that you had like 3,000 issues, and also that number amount of issues on an Alex's project. I'm seeing here the Power BI dashboard. How did that help you to manage those issues?

BUSHRA ABOELEZZ: Yeah, actually this really added some accountability to the clash detection. Because if it's just a matrix, and it's just a report, it's different. Maybe people will not ignore it or take it seriously. But exporting all these issues, and taking them to power BI, and provide an insight to the entire team-- and it's really very granular here. They can go per station. And they can see even how many issues are assigned to them. So I think this was a very, very good way to hold people accountable to these issues and make sure they have to go and fix them.

RONALD LOGGEN: And Alex, any comment from you from ESAP?

ALEX LALUMIERE: I mean, pretty much the same thing. It was great to see that we could create something that was a bit, again, more granular within power BI that what BIM 360 out of the box offer.

On one project the analytics are still good in the insight module. But when you have multiple locations, you start losing the benefit of using something that is a bit more generic in the insight module. So extracting the issue report, we were able to create those dashboards within Power BI.

And using the cards from BIM 360, we were able to present that to the whole team in a very accessible way. And now that BIM 360 also allows you to create your own dashboard and share it with the team, it makes it even more easy to create those Power BI dashboard and link it to all project members, instead of having everybody creating their own dashboard, picking up the power BI or not so you can make sure that everybody has access to it.

RONALD LOGGEN: Sure, and what did we end up with? Basically it was a little underwhelming, because what we ended up with was a standardized template with a permission matrix. All the roles inside of that BIM 360 template project. And, of course, a lot of documentation.

I know Alex spent a lot of time documenting all of these workflows. So whenever somebody needed an answer or had some questions, everything we did was documented and ready to go.

ALEX LALUMIERE: I think that's a good point, Ronald. You know, you mentioned it being underwhelming. But at the same time, it was so simple. That's the simplicity that we created that kind of make it underwhelming when you present it to somebody that this is now your project folder standard. This is now your permission standard. This is your documentation.

Everything seems, OK, that's it. That's what you've created. And then people start using it. And it's so simple that it's easy to adopt.

And then you move on forward. You have all that documentation, those videos. The project support becomes really, really easy to do that shoulder to shoulder, because you see something standard on each project.

So people sometimes call me. And hey, I'm having this issue. Oh, yeah, I know how to fix it. I don't even have to look at their project. I already know how to fix it, because it's the same thing over and over again.

RONALD LOGGEN: Sure, and looking backwards-- looking back at all the things that we've done in the last two years, this will be, I think, it will be a good summary for it.

Like the journey of adoption of BIM 360 through time, we learned from all of the projects that we did. It was also kind of to democratize collaboration and clash avoidance. Everybody who was not experienced in Revit or Navisworks could actually look at a web page and view all those clashes.

You could see a timeline of all the things sharing, which could trigger QA/QC. The automatic versioning, there was a simple interface to get a clash free model. And it created efficiency. And like Alex said, model coordination, easy to use, hard to master, because you had so many things you can tweak with that container file.

So basically, the last question from my side is we had a standardized collaboration workflow. We now can accelerate project delivery. What's your feeling? How did it help you accelerate project delivery?

ALEX LALUMIERE: Well, I think on my end it was great. We're applying this solution to so many projects now. And we see even some external firms trying to adopt what we're doing.

They're open minded now. They see the benefit, especially on one project where model coordination, they wanted to use BIM Track. They wanted to use Naviswork. And I simply presented our solution. And nobody could really argue that being proactive with the clashes and involving everybody in a very transparent way to clash avoidance, and fixing all those, the noise in the project. You know, where you can remove that noise because your users will be able to take care of it, and your BIM coordinator will now be more efficient, just focusing on the real clash that really needs some effort and judgment to fix, and some communication with the design team, and all of that. So truly, on my project at least, I've seen so much efficiencies just coming out of those simple solutions.

RONALD LOGGEN: Bushra, any feedback? Any comments on this as well?

BUSHRA ABOELEZZ: Yeah, I think the main thing is really the adoption of BIM 360. You know, having all this just facilitated the adoption of BIM 360. So we don't really have to go through this process, you know? I mean, everything is automated, or semi-automated, starting from the request for a BIM 360 project.

So this made it easier. It really cut some of the work that us BIM managers have to do, right? It's made it accessible to everyone to request the BIM 360 project. Before we wanted to have some kind of control, because we didn't know how people are going to send those projects.

But now we don't need that, because we do have this process in place. They ask for a project. They get the folder structure. They get all the permissions set. So we're really here, set to go.

So it's faster. It's easier. It saves time. And pushes on BIM 360 did serve us very well in this pandemic, right? Because we don't really have to be on the VPN, and connected. And it just makes it very easy for us to push this workflow.

RONALD LOGGEN: Good, and last question, of course. Any next steps? I know that from the other regions of WSP we're talking about is other countries and other parts of the region of which were also interested in your workflows. And again, because the technology matures and the technology changes will adapt the standard to other regions as well. Any other last--

ALEX LALUMIERE: I think that's going to be a big part of where we want to go, right? Keeping up to date with the new features that will come to BIM 360. There is cloud construction that is already up and running where we will want to adapt as well and migrate at one point, see which one of our workflow can migrate well to that environment.

And not only sharing with other regions, Ronald. But I think there is even other business lines that are looking at our solutions and wants to adopt it. Because although the design is different, the foundation of those projects can be very, very similar. So there's a lot of experience that we can gain through sharing our solutions.

RONALD LOGGEN: OK, Alex, thank you. Bushra, any last comments on your perspective on next steps?

BUSHRA ABOELEZZ: I guess sharing this with the rest of the WSP regions I think is just going to improve this process more. Like we're going to learn from them. They're going to critique this process and give us some solutions to do this better. So I think, at the end, we're winning by doing this.

RONALD LOGGEN: Great.

ALEX LALUMIERE: I think, Ronald, you had some good feedback even from one of the regions that we were working on something. And you shared that workflow with them. And they said, oh, but we're looking to automate that.