Cloud Collaboration and Successful Integrated Project Delivery

PAUL MCGILLY: Guys, hi. Can you hear me? Thanks for coming along. It's really early in the morning, and I know there was a big block party last night, so you should all get medals for coming along to this this morning. Well done. So I apologize if you don't-- my accent is Scottish, so there will be subtitles at the bottom of the screen. I'm joking.

So my name's Paul McGilly, and I'm the BIM Manager for BuroHappold New York. And I'm also the Regional BIM Leader for the East Coast of United States. And I'm going to talk to you about cloud collaboration and IPD. A little bit of BuroHappold. We're a global consultant with 23 studios worldwide, over 50 partners and 800 employees. And we've been around for 40 years.

We've got offices in North America, Europe, Asia, and the Middle East. So we're truly a global practice. We're a multidisciplinary company. We cover structures, MEP, computational engineering, facades, lighting, and urban development as well.

So we did a survey earlier this year on-- we really wanted the thoughts of our engineers. What was working with the company? What wasn't working with the company? And it was basically a survey. And now, I'm not going to get through all the principles that [INAUDIBLE] back. This is really what we're taking forward with the company and the practice.

But one that stood out was number three. We embrace mature responsibility. It's easy to default to individual success. And teams need to share success and failure in the same way. And I thought it was kind of apt for this project because it is about teamwork, and there is no individual success. We do it together as a team, and that's really important. And I wanted to apply this moving forward in this project at Brown.

So our objective today is project setup of multidiscipline models; and the workflow between ourselves, the other design team members, and the trade partners; and the workflow through design to construction; the coordination, how we efficiently communicated and coordinated clashes and a method of reporting, again, from design to on-site; and asset data, how we inputed shared parameters for asset data to be used in the design model by the facility's management teams.

So a little bit about the project. It's called the New School of Engineering, and it's in Providence, Rhode Island. 80,000 square feet. And the project value was $79,000,000 million. It actually just opened last month, and we're really happy with it.

The team, this is the core team. Obviously, the owner was Brown. KieranTimberlake, architects from Philadelphia, were the architects. BuroHappold were design engineers. General contractors were Shawmut. Trade partners, Arden, Worcester, and Audet. The trade partners when we were moving into construction site are these guys there.

So why did we choose New School of Engineering? Brown is an Ivy League school on the East Coast, but it's one of the smaller schools. So there's less students and less revenue, and they have a smaller endowment. And the client wants to make the money go further.

One of the things they want to do is develop a long-term relationship with the trade partners and the design partners as well. And this is the first of many facilities on the site. So they really wanted to build up a consistent workflow and have a consistent team working on all these facilities. So they wanted to create a set of standards, and they wanted to develop an efficient workflow. And IPD was a way forward, in their mind anyway.

So what are the principles of integrated project delivery? Mutual respect and trust, benefit and reward, collaborative innovation and decision-making, open communication, and I think most importantly, appropriate technology. So what was that technology, and what drove us to cloud collaboration? It can be client-driven, contractually obliged.

And the clients get really excited about this because they thought it was a way, as I said, of building these facilities within the budgets. Integrated project delivery itself, we're moving towards common data environments. We want to access and share data in the one location. And Collaboration for Revit does that for us.

And, of course, we're collaborating with external teams. I'm sure we've all used Revit Server. It works very well internally. However, unless you're using third-party tools like Clarity, it can be very difficult to use Revit Server with external team members, in terms of access, firewalls, and security. And for obvious reasons, you're having all the design teams access your network and your servers, and IT are never really happy about that.

And data exchange as well. Really wanting to try and find the most efficient workflows because we are working, as engineers, we're working with our trade partners, and we're accessing this same information. And, you know, obviously, model uploads and downloads just wouldn't work.

We looked at different options. And we looked at Panzura and Advance2000. These are really high-performance tools, and they work very well. However, they are expensive. And we looked at the possibility of using these. But it was hundreds of thousands of dollars, compared to Collaboration for Revit. Revit Server, we've always used it successfully, as I said, and there's no cost to it. But there are those external access issues, which I spoke about earlier on.

And we looked at actually using the colocation space. A successful IPD project requires a colo, upon the site, preferably. And we could have just moved all the teams up there and worked together as one team. However, logistically, that's not viable for the simple reason that the teams are all located across the United States.

And obviously, as well, as we all know, we're working on other projects. So we can only dedicate a certain amount of time to working on this particular project. So it wasn't really something we wanted to do. But we would use a location as much as we possibly could.

So BuroHappold, we requested to Autodesk to get involved in their Beta project SKYSCRAPER in 2014, '15. And we wanted to be part of this because we saw cloud collaboration as the future. And so this was Autodesk's actually first attempt to embrace the cloud. And we wanted to be part of that. So the Beta test was successful, and we recommended it to Brown, the client.

In terms of cost, it was a fraction of the price of the other options that we had. And I think with the support that Autodesk were going to give us on this, because they were up in Boston, we were in Rhode Island, it was a train journey down.

And for them, this is actually the first true IPD project they've been involved in, where all the key stakeholders were working on an environment. And also, as well, this was the first iteration of Collaboration for Revit, so they wanted to see how it went. So it was important to have their support. And this was BuroHappold's first IPD project. And we were really excited about this.

The format. The team purchased a number of licenses, and they're managed by the construction managers and the architects. And that was a shared project cost, which is the essence of IPD. Licenses can be assigned and reassigned as needed, which was important for BuroHappold as a global practice. We were utilizing offices in Los Angeles, Boston, and Chicago.

So we wanted to try and use the best talent we had in the company. So it was very easy to move a license from one user to another. You have to register with Autodesk to log in to the cloud. And actually, now, Collaboration for Revit is part of the Revit instillation. Back in 2015, it was a separate installation, and so this is a huge improvement, actually. And you have to be invited onto the project by the client or the prime.

So what were the benefits of using Collaboration for Revit? We can seamlessly access model data at a central location, which is really important. We need to see changes quickly, and we want to update whenever we can. And that was important to us. And the ease of access. If you've got an internet connection, you can access the models at home, on the colocation, or in Starbucks if you want.

And concurrent model authoring. As engineers, we're working closely with the trade partners. So our mechanical engineers are working with the mechanical engineers in one of the trade partners. We're working in the same systems. So it's important that we have a good platform and be able to make those changes together and make decisions together as well. And it worked very well for that, actually.

We see real-time updates, obviously. I'm an MEP engineer. So in the early stages of project, trying to negotiate space for your MEP systems, we want to get that information in there. We want the architect to see it as quickly as possible so they can make any changes to the shafts or horizontal distribution.

Centralized communication. I think we've all used Skype to communicate. It's really important now in the way we work. We want to talk to our team members and within your company, and it's really a staple diet now. Collaboration for Revit uses this as well.

If we're not in a colocation space, I can talk to the mechanical engineers at the trade partners up in Rhode Island. And it's as if they're actually working in the same office, both of them working in the same office. We can use the communication to either talking to each other or video. So it was very important to have this and utilize it.

And we're working together. Again, that's the essence of IPD. We're all in it together. We want it to be successful. And it's a real team effort. And I think one of the things, as I said earlier on, it's cost effective. There's no specific server builds and we've got no changes to security, and both of those can be expensive.

And, of course, no file transfer. File transfer as you move from design into construction, the models become bigger and bigger. The architectural models can go to gigabytes in size. The MEP and structural models, 200 to 300 megs. So when we do those data exchanges on a weekly basis, it can take hours to do when you've got so many models involved. So not having the file transfer was key to us.

However, there are drawbacks, and I want to go through those with you. Outage. Autodesk Orion at Amazon data center. And it does actually go out of service, which is really frustrating. Fortunately, it's always only for a short period of time. And we had workarounds to get around that. Don't synchronize the cloud. Just keep synchronizing and saving locally until it comes back online again.

And it's bandwidth-driven. You have to make sure that your internet and your bandwidth is scalable. We fell into a trap of not thinking about this. And we [INAUDIBLE] our utilization was at times 95% as we brought in more engineers working in the project. And, of course, we have other activity on our network as well. So you have to consider all of this.

So we had to double the bandwidth of our internet to be able to cope with this. And, of course, as you get more and more projects, you have to think about, can we cope with this? Because we have seven or eight projects on this now, and it's important to anticipate that over the next two or three years.

I think that the way that they manage licenses, at that time anyway, in 2015, traditionally, we have pools of licenses which we can tap into. In this, they're allocated to the user. And I think that was logistically difficult to try and move-- it wasn't difficult to move the licenses about. But I'd rather that the engineers can tap into them whenever they want.

So we're going to talk a little bit of best practice. So what were the model requirements? We wanted to use it for clash detection, scheduling, cost management and estimation, materials quantification and procurement, construction engineering and execution, and post-construction operations with the facility management and the asset management teams.

We find that we want to set a solid foundation on IPD projects and collaborating with the external teams. So it's important to have-- we always have a BIM kickoff. We want to get all the key members in the team together. And generally, we will set up an agenda. We want to identify the key documents. The BIM execution plan is the most important, I believe.

And the project plan as well. What are the deadlines and milestones? And that level of detail in development as well. We want to know what we're modeling and when because, in our experience, we've found that the younger engineers can get a little bit overexcited and start modeling more than they should at the early stages of the project. So we want everybody to understand what we're doing at what stages. And that ties into the project execution plan.

So what is the project-- sorry-- the BIM execution plan? What are the key points in that plan? Obviously, contacts, you know, who are your BIM leads? And these guys are key in making sure that we're all singing from the same hymn sheet really, you know?

And as I said earlier on, the project schedule. What are we using the model for? Analysis, clash detection, scheduling, quantities, documentation, and prefabrication. And we want to get the most out of this model.

Software selection, as I said. We knew that we wanted to use Revit for model authoring. And for prefabrication, the structural guys were using SDS, AutoCAD, and MEP were using Sysque. And for design analysis, it was the third-party tools.

We weren't using Revit itself. We just don't think it's there yet. So we were using IES and Trane Trace. Structural guys, RAM. And clash detection, of course, to me, one of the most important things. How do we report our clashes? And well, I'm going to go into that in a little bit, actually.

Standards is really important. All these companies have their own-- have different standards. So we need to make sure that we're all aligned. And fortunately for us, we were setting those standards because BuroHappold have had a really robust set of standards in place since 2007.

So we put that-- we didn't force it on anyone. We put it forward because we thought that we had probably a little bit more experience on BIM projects than the other teams. And fortunately, they went for it because as I say, we want to try and make sure that everyone is working to those same set of standards.

Example, what worksets? You know, we try to keep it, we're very conservative over worksets. We don't want to go crazy and start creating countless dozens of worksets. We wanted to keep it simple, and we wanted to make sure that the other teams wouldn't go in and just start creating worksets or anything like that and kind of diverging away from what we'd set at the beginning of the project.

And parameters as well. We want to make sure that we're all using the same parameters, we share a shared parameter [INAUDIBLE]. We gave the teams the opportunity to comment on it if they wanted to have any input. We knew that the trade partners at the construction stage have got a lot of experience in this. So we wanted them to into it, make any comments, and add anything in if they could.

Model access, obviously, which is, well, we're using Collaboration for Revit. We consistently use the cloud platform at design phase, pre-construction, and construction. And the level of detail, as I mentioned earlier, understanding what we're modeling and when. Through the design stage, it was to LoD 300. Post-design, we were going to 400 and 500.

Infrastructure. Your IT infrastructure again, as I mentioned, the bandwidth is really important. We fell down on this a little bit as I mentioned earlier on. We didn't anticipate the amount of activity we would have, the amount of information that we're synchronizing to the cloud.

When you've got 10, 12 engineers in your own office synchronizing at the one time, you need to make sure you've got enough flexibility there for them to do it because if you don't, as I mentioned earlier on, no one can synchronize. People panic.

We actually had, because it was the earlier versions of the Collaboration for Revit, things were freezing up, and we were losing information, which is disastrous really, you know? So make sure that you tie in your IT group to when you work on these projects. It's really important. I think that through the project, I think we had probably about 15 engineers working on it.

And also as well, you have to consider if you have other offices who are tying into working on the project. Our offices in Los Angeles and Boston are much smaller than New York. And they vary from 5 to 40 people. So you've got to make sure that they've got the infrastructure in place as well. So if you have a lot of offices that are tapping in, always remember them as well.

The template is key. BuroHappold were setting up the project using their templates. And all the templates are different. We try to have a simple, efficient MEP template and a structural template as well. For example, the project browser, I always like to keep it simple. I've worked with some teams where the browser is just endless.

And the thing that you have to remember-- it's OK if you're working within your own company, they understand the format of the browser and where everything is. But when you get external parties coming in, they maybe don't understand where you're keeping your views, et cetera. So I like to keep it simple. I want them to find things quickly and not go into a situation where they can't find someone and they start creating their own views or sheets, which is not good.

Our schedules are preloaded. We have a set of standards, standard schedules within the template, so that the engineers understand what our standard schedule looks like and not to deviate and create their own. And that's the same for the external groups as well. We gave the external teams a chance to comment on these schedules if they wanted to input to them. However, they were really happy with them.

We only allowed critical families into the template as well. I don't know what your thoughts are on this. A way back, we used to have what we called a full fat template. And it was 120 meg in size. And I spoke to an architect at a Revit users group in New York. And he used a lean, mean template, as we called it.

And if you load everything in, all your families in, that model's going to become very clunky very quickly. And a lot of the families in there you're probably not going to use. So why load them in? You want to keep this model running as efficiently as possible because it is going to LoD 500, and it's going to get very slow if you don't make sure you set it up properly.

So we only loaded in from the MEP side of things settings and accessories and basic, mechanical-- the families that we use for mechanical equipment. It's simple geometry. That's it. We know that as we move towards, in a traditional project, CD, once we know what equipment we're going to be using, we're going to use the manufacturer's families. So we don't want to start loading those types of families in early on. It's an inefficient use of time and space.

We set our sheets and views up. We call it front-loading. We know what we want from the project all the way through CD. So we get all the sheets set up. We get all the views set up. And we run what we set up, what we call a cartoon set. That allows the team to look at or understand what the construction documents are going to look like.

What I don't want is doing it as we go through the project, where you've got various team members from other consultants and other trade partners setting up the sheets, setting up the views. They may have different ways of setting things up, so you're going to have an inconsistent set of documents.

Consistencies are key because when the client opens up the drawings, you want to go from one trade to the other and just see a flow. So what I did was I had the teams set everything up at the early stages of the project and understand what we're going to be delivering all the way through to the end of design and then into construction.

One of the things we did, we split the models up. I know that there's a lot of debate on this, whether to keep all our systems together or we split them out. This is not a large-scale project. It's 80,000 square feet. It's a medium-sized project for us. And we could probably, traditionally, have comfortably taken that model as a combined format with the MEP systems altogether.

However, that's the LoD 300. When you're going to 400 and 500, when the bolts, and the hangers, and the finite detail that the trade partners will be modeling with, that model is going to grind to a halt. I guarantee that. So we wanted to split everything out.

So we had four separate from the MEP side of things. We had a mechanical electrical, plumbing and fire protection, as well as structural as well, so that we could just keep everything running efficiently. And it worked really well. I make no bones about it. When you get to the later stages of these projects, things are going to run slowly, and you have to anticipate that.

However, I'm going to talk about some efficiencies and some tasks that can help minimize that, let's say. And this is it. So what we did once a week, we took the models offline and ran a maintenance program. What we were doing was we were really notifying the team that there was going to be a disruption.

It would take usually about an hour to take all the models off the cloud. Tell the guys to go away, have a coffee, take a break. And synchronize all their work before we'd done this and relinquish as well. Then, we would detach, and we'd audit the models.

What we'd do is we'd do a quick check of all the families that were in there. Is there anything that we can take out? We don't want [INAUDIBLE] unused because we can be using those families later on. But it's really just a case of getting in and looking at it and saying, what can I take out of this? What am I not going to use?

When the model comes offline, you can get your users to remove all cache and backup files as well from the local drives. This is really important, and it's really difficult to get your team members to do this. There was an element of policing that I had to do to make sure that they'd done it because you will-- or we did run into permission issues. And this seemed to resolve it, which was great.

If the models are still online and hosted to the cloud, the local users should never remove the cache files and local files. That's a disastrous thing to do in the sense that once they open the model up again, all that information has to get loaded back into your local drive. So creating a local file can take an hour, maybe more.

Looking at workflow. So you really need an efficient and robust workflow for this. And everyone has to understand what the workflow is. As we spoke about the software, that's key. We had a cloud collaboration software, and our modeling software was Revit. Working with trade partners, we had to understand who was modeling what and when.

Utilizing those teams' strengths. We know that our trade partners are very, very good at LoD 400 and 500 coordination. As consulting engineers, we can do it, but we don't do it as well as our trade partners. And we know that. So we want to tap into their strengths at the early stages of the project as well. And that was very important.

And any problems, communicate them and solve them together. And we actually really enjoyed doing that. We were really working as a team. And if you want to tap into the experience and strengths of a trade partner who has got a lot of background on these projects, then don't be afraid to use them, and never be afraid to ask.

So this was the software workflow. And from Collaboration for Revit, Revit, Glue 360, Sysque for fabrication and families, FABmep, which I'm going to talk about in a little minute, and Field360. As I said, this wasn't a traditional project with the traditional stages of concept, SD through DD. There was only a design stage and then a construction stage.

And what that meant was that there were stages where the structural guys were actually getting into construction, and there was actually partners who were still in the SD stages. So as I said, you have to really look at your project plan and understand when you're delivering what and when. And it was really new for us to do this, actually. But it was a great experience.

This was documentation workflow with those tools that we were using. A360 and Revit we were using from a design stage through to construction. FABmep was used by one of the trade partners as we began moving in design and once we started to understand how our main distribution was working through the building.

Glue 360 we used from design all the way through. That was a really important tool. Sysque, once we were at the construction stage, we wanted to convert the Revit systems into a fabricatable format. And Sysque was the tool that we used. And Field, the trade partners were using Field 360 all the way through at the site.

So at the early stages of the project, this was a really important lesson that we learned. The architectural model is fluid at those early stages. The architects are excitable. Things are changing all the time. And as MEP engineers and as structural engineers as well, we host a lot of our objects to that architectural model.

And we learned the hard way, you know, when things were being deleted, walls, RCPs. It's never a good thing to see your fire protection engineer crying because he's lost thousands of sprinkler heads because the architects removed an RCP. They become orphaned.

So what we did was we created a date-stamped architectural model at the early stages of the project. We weren't linked to the live model. So it was really having a frozen architecture for a week. And we would date stamp it when we got to the following Friday. We would then update the model again to understand the changes.

So this was really important for us. We weren't working in a completely live environment. But I think it was key to making sure that we weren't losing information at those early stages of the project. If there was any major changes that the architect was making and it was important that we saw them, for instance, spatial allowance, for example, we could do intermittent updates if it was required. And that was fine.

The MEP models and structural models were still live to the architect, which they wanted because they wanted to see the space that was required for our horizontal and vertical systems. So that was live. This was the workflow that we had for that partially live environment. As you see, the structure and MEP models were tapped into the stamp model, but the architecture was linked to the live models at structure and MEP.

So once the architecture had settled a little bit and we understood, you know, we wanted to be live. So when we started to move a little bit deeper into design and we knew that things were kind of settling down, we linked all our engineering models into the live architectural models on A360. And the date-stamped model was removed so there was no confusion.

So what we had to do was we knew that there would still be a lot of changes going on in architectural model. So we wanted to start-- we wanted to put a workflow together that would allow the architects to continue to make changes that would impact us, and also same for ourselves as well, to continue to get scope into the model.

And well, that was the-- so this was a live flow. I do apologize. So this was a live flow that we had. We split the building in two zones, Zone A and Zone B. At the beginning of the project, KieranTimberlake were getting scope into both zones of the building. Then, when we moved into the second, the third week, actually, KT moved to Zone B, and BuroHappold moved to Zone A.

So there was a real, coordinated effort to make sure that we weren't tripping over each other, we weren't losing information, and KT were allowed to continue to develop the building. And we did this through to probably the first two, three months. And it worked really well.

The interoperability between a design engineer and the trade partner is important as well, as I said earlier on. Who will be modeling what and when? And for us as design engineers, our responsibility is in mains distribution, the big-ticket items.

And the trade partners are responsible for the secondary distribution and final connection. The level of detail in development is fully understood as well. We want to make sure that-- we don't want any abortive work, i.e. someone getting a little bit in front of themselves and modeling secondary branches, et cetera.

Utilizing the key strengths of the trade partners is important, as I said. They know what they're doing at those stages of the project. And the knowledge and experience was key. And work those clashes out together, as I said earlier on. And the way that we did that, actually, was making the most of our colocation and actually getting the guys together to resolve clashes actually around the table together.

So this was the workflow and the communication protocols. First of all, for the ductwork, BuroHappold were responsible for-- or the design engineers were responsible for the mains distribution, schematic risers, riser diagrams, typical details, and equipment schedules. We were also responsible for inputting any FM shared parameters when they were needed.

Now, this is an interesting part of this, this part of the project. The trade partners who were responsible for ductwork were not working in Revit, which was initially a problem. And it's something that we weren't exactly happy about. However, these guys were using CAD-Duct or FABmep as it's now called. And they've been using it for years. And it's something that they rely on, they trust. And the client understood that they wanted to use it.

So we were OK with that, actually. We worked out a workflow for this. And what we did was we exported out 3D DWGs for the trade partner to use. And then, they started to develop the ductwork model. Then, what we'd do is on a weekly basis, we would get them to give us a 3D DWG for us to link into our Revit models.

It wasn't ideal. There are certain issues with that in terms of running coordination reports and Glue 360 recognizing that 3D DWG. And also, we couldn't schedule their equipment as well. So there was a little problem there. But we did have a great workaround for that. Communication is the most important thing, letting these guys know our design intent, and them coming back to us and just making sure that our mains distribution was being modeled in the right place.

For fire protection, the design engineers were providing design intent through sprinkler head placement. Then, that was taken on by the trade partner. And they were then running the system calculations in HydroTech. They would then create the model layouts, and then, they would export them to us so that we could then link them into our Revit models for coordination purposes, just really for mains distribution to see where the 8, 10-inch sprinkler pipes were running.

Again, that back and forward communication is really important. I can't emphasize that enough. And we were, again, responsible for the input of shared parameters for the FM purposes. For plumbing, again, there's a consistent workflow here, really, as I said, apart from the ductwork, it's really that we want, BuroHappold are responsible, again, for mains distribution, schematic risers, typical details, and equipment schedules.

And then, the trade partner would start to build a Revit model from the mains distribution that we'd created. And they would take that all the way through to final connection. And it was the same trade partner that was doing the mechanical pipework as well. So we had exactly the same workflow. And it did work really well.

So coordination. Again, something that I think is maybe top of the list when it comes to delivering a building that works. And you need to have the right tools in place, and we looked at a few different tools. We looked at Revit Clash Detective, which actually works pretty well. However, it has got limited capability in terms of creating rules.

We looked at Autodesk Navisworks, which is what we used. It's actually a primary coordination tool in BuroHappold. It's a very powerful tool as well, especially for reporting clashes. But it does create rules that you want to build into your coordination templates. However, it's very expensive. It's $10,000 a pop, you know? And to get, you know, 10, 20 licenses of that is a very expensive exercise.

So we looked at Autodesk Glue 360. It just seemed to be cost-effective to use. And it just really had the functionality, I thought, of Navisworks for the purposes that we wanted to use it. This was a great chance for us to get all the teams together at the colocation space for training. So it's really important that you do that as well.

You can do it online, which is perfectly fine. But I think it's a great experience to have everyone together. And Autodesk came down from Boston to do the training with us. And it was a pretty straightforward, three-hour session. And very easy software to use, especially if you know how to use Navisworks.

As I said, we used a colocation space, and just being able to be a team together doing it was very important. We actually used a project model as well, which is important, I think. It just kind of, in a way, it brings familiarity with using a software and relating it to the model.

For communication, coordination is important. We used the collocation for coordination meetings. It's really important to have regular coordination meetings with your teams. You can do it remotely. You can connect in and do it over Skype or the communication tools and by looking at the models in Glue.

However, we wanted, first of all, someone to take ownership of the coordination reporting. And that has to be the construction manager. Someone has to be there to get all that information together, collate it, and then understand what is a priority and what can be left till later on. So the construction manager is perfect for that, actually.

We schedule a coordination meeting once a week. You have to do that. We can do it more often if you want. But to get everyone together and resolve those clashes is just so important.

AUDIENCE: From the IPD process, how early did you start the weekly coordination meetings?

PAUL MCGILLY: That's a really good question. I think that we started mid-design. I think that was probably about-- this was a pretty fast-tracked project. So design was really from 2015 to 2016. We probably started the clash reports in mid-2015, I would say.

I don't think it's an efficient use of time to start it too early just because of the nature of the building changing. You don't want your engineers to be chasing coordination issues at early stages of the project. We want our engineers to be engineering. That's really important.

Once we know that the architecture's settled, then we want to understand how our MEP systems are going to be coordinated with the structure, for example. You don't want to be telling your structural engineer at the end of design, oh, by the way, we need these BIM penetrations. That's how you really, excuse my French, piss off a structural engineer. So you don't want to do it too early. Once you feel that the building's settling.

But trying to relate it in a traditional project, we will begin the coordination process towards the end of DD. You can start it at 50% DD just to get an overall idea of where things are to make sure that things aren't running one foot off the ground. But I think that the ideal time is to just do it towards the transition of DD to CD. And for us, that was about six months into the project.

Prioritizing what you should look at and what you shouldn't is important as well for us. Looking at the MEP services, the mains distribution, the big-ticket items, and how they worked with the structure. We want to make sure that we get our coordination with the steel locked in so that the structural engineers understand where the penetrations are through the BIMs. Once we get that down, we can start working on other things.

For MEP systems against MEP systems, that came a little bit later on, actually. We wanted to make sure that we got our coordination right with the architecture and the structure. Get all that mains distribution in place. Get your corridor zones locked down as well. Make sure you get the right space that you need.

We did all our-- we actually got everything up on a big screen, not this size, but, you know, we got everyone in the room. We got everything up on the screen. And we actually used Glue 360 very successfully for navigating around the building. If we wanted to show pinch points of any problematic areas, we could just walk into it and just show the architect, hey, we need more space here. And we were solving the clashes together.

I mean, really, what it came down to, which was a huge enjoyment for me, was getting a clash report. We would go through the list in the colocation space. And we would look at one of the clashes. And we'd say, right, let's resolve that. So I would be sitting beside, let's say, the mechanical trade partner. We would see the clash. I would say, you need to move that. This is purely as an example.

We need to move the pipe here to resolve that clash along at this point in the system. So he would do that. Then, glue it back up on the cloud. And then, we would see the clash resolved and the change made. It was done instantaneously, which was great. So I got really a huge enjoyment out of just sitting beside our trade partners and fixing all those clashes. And it was very easy to resolve them. That's an image of the colocation space.

So one of the things that we did was we created clash rules. This was a huge learning experience for us, [INAUDIBLE] management. There's nothing that will make you go more pale than getting a clash coordination report back with 40,000 clashes. It'll make you want to run out the door. But that was what we-- that was just a very general clash report that was run.

And this is a way back in 2008. So we were learning about this. And what we did bring from that was that we need to start creating rules. What do we want to eliminate from the report, the clash report? Things like sprinkler heads against RCPs. You don't want that to come up in your report. And the same with ceiling diffusers.

Final connection pipes and reinforcement. Structural connections and temporary work. You can build all those rules in. Therefore, we were really actually looking at clash reports for each discipline which were essentially double figures, which is very manageable. And by getting those rules in, you can prioritize on the big-ticket items. It's really important.

So as I said, those meetings I mentioned earlier on, it's really just making sure that your major design is coordinated, as I said, in particular with structure and architecture. They have to be resolved as soon as possible. I'm going to talk to you a little bit about asset data and how we got that information into the model.

So Brown requested that the team integrate the information in the BIM with their FM software. In the education sector, they use FAMIS, which is essentially the equivalent of COBie. Same information, actually. And they wanted to utilize the data in the model and populate it to their asset management system.

So how should we get that information, and organize it, and get it to Brown University? And that's something that we had to work out with our trade partners. Who should be responsible for what? From the data side, that's a lot of information, and it could be time-consuming as well. The shared parameters, where the data will reside, let's say, who's going to be populating that information as well?

People tended to back off at that stage because it wasn't in the contract, which in future projects we've worked on is now in the contract. So make sure, I would say, look at your contract at the beginning of the project. What have you agreed to put into the model? We've been caught out on this later on on a few projects, actually. So you really need to make sure that you only want to put in the information that you really need to. And I'll explain what in a little bit.

We needed tools as well to input that information efficiently. It's a very time-consuming process, just pressing buttons, you know? And I don't want any engineer doing that. It's not a good use of their time. So well, we understood that during construction, the trade partners are likely to switch the families that BuroHappold have put into the model.

Once they know what manufacturer they're going to be using, they're going to swap out that simple geometry that we would have for, let's say, for example, [INAUDIBLE] handling unit. We are putting parameters into those families. But that's purely to populate the mechanical schedules.

When you get nearer to the construction stage, they're going to take them out, and they're going to replace them with a more accurate family. And those families, actually, can already have the FAMIS data in the family. One of the things that we did, actually, was-- is anyone familiar with Sysque?

They're actually a very good company, and they produce millions of families which are usable for prefabrication. And we utilized them. Actually, I met them here a couple of years ago. They had a stall, and I spoke to them about the project and said, look, we want to use your families. The trade partners want to use them. However, if we give you a list of these shared parameters and a list of the data that needed inputted, could you get those into the families?

And they were actually only happy to do it. They wanted to be part of the project. So that's something you should think about as well, you know, communicate with the manufacturers. Tell them what you want embedded in the family. And I would say, they will do it for you. They're only too happy to help if you don't tell them you're going to go somewhere else.