BIM for Builders: BIM Planning with Integrated Teams

PIERCE REYNOLDSON: All right, I know there's some people waiting to get in from outside. But we're at 2:15, so I'll go ahead and get started. Just a real quick question. How many people in the audience are contractors, are coming as general contractor types? BIM for Builders, obviously. How many people are designers?

[INTERPOSING VOICES]

Good. OK, I'm glad to see a nice grouping. Trade subcontractors? Cool. Owners, operators? Nice, good, we got a mix.

I was worried about, with the title of this, that I'd end up with just contractors. No offense, but I wanted to get everybody in here. If you're here that means you like Construction BIM and you couldn't get an earlier flight. Thank you so much for coming out.

I'm your speaker. My name is Pierce Reynoldson, and I work for Skanska USA Building. I'm the Senior VDC Manager for the Metro New York office, and for the LaGuardia Project.

A couple of things that you should know about me. One is, I like to think of myself as split between two worlds. I have a bachelors and a masters in architecture.

I worked for three years in architecture. I've spent the last 8 and 1/2 years doing VDC and construction. And also, as a lecturer at the Yale School of Architecture, where I teach architecture grad students how to put together a set of drawings and develop their design using Revit, and other BIM-related technology. I like to think that part of the approach I'm going to be showing you today is really coming from that academic way of looking at things. But academic with a kind of a ruthless pragmatism, I'd like to think.

The second thing to know about me is that I spend most of my time working on the LaGuardia Airport Project. This isn't a presentation about LaGuardia Airport Project, but I've been on it, now, for three years. And if the contracts are true, I'll be on it for another five years. So the shadow being cast here is basically over my entire life.

Everything I'm going to talk about is going to come from working on a really big project with really big teams. It's big, right? And actually, I should've updated this. It's bigger than this. It's more than 1.3 million, 'cause there's been a contract added since. It's still 5.3 million square feet of site.

But this is the part that really affects me is as a VDC Manager. It is eight projects. That's eight projects, with eight separate teams. There's actually 14 projects, but 8 are the ones that I primarily deal with.

It's 150-plus Revit models that we're dealing with on a regular basis. And it's over 12,000 CAD files. Then finally, it's over 15,000 sheets, 1,500 for the CTB, Central Terminal Building, alone. So a lot of what I'm talking about today is coming out of a mindset of strategic laziness, of trying to deal with 150, with all of these files, and not just drown in them.

Learning goals, I'm hoping that when we go through this today, people are going to come out of this with a better understanding of how designers work, how contractors are working, thinking about how you can apply these to your BIM planning strategies, and also, software strategies. But more than anything, I think the overarching theme of this is going to be about empathy, and engaging across the divides.

Most often, for me, the contractual divides between the contractor and the architect. And then also, with the subcontractors as well. Really, with everybody on the team.

As I'm going through these examples, these strategies or hacks, you're going to keep asking yourself, wouldn't IPD fix that? Or wouldn't Co-Location fix that? Or Design Build fix that? This is a presentation that's really for the reality that I live on. At least in the Northeast.

In the Northeast, the projects tend to be-- at least, the projects I've been on, are primarily design, bid, build, CM at risk. So you're always working within that paradigm. I would even add to that, because I've worked on IPD projects. I've done heavy co-location. LaGuardia is actually a design build project.

Even when the contracts change, if you've spent the last 10, 20 years doing design, bid, build, guess what framework you're going to default to when it comes time to do the work? It's going to be that design, bid, build mentality. A lot of this is also about how we can continue to move forward.

But like I said, I'm working from the middle here. These are strategies assuming that I'm kind of stuck in this contractual situation. Where there is an earlier contract between the design team and the owners. There's a little-bit-later contract between the CM and the trades and the owner. And that the two groups that I really wish would talk more don't really have, necessarily, direct communication built into their contracts. Unless it's been emphatically done.

By the way, I'll throw one more thing out there before I continue barreling ahead. I tend to talk a little bit fast. So if anybody has a question or needs me to slow down, feel free to raise a hand or nod, or shout out, and I'll go back. This isn't about hoping for what we don't have yet. It's about being optimistically pragmatic from where we are right now.

The roadmap, the way we're going to go through this today, I'm going to talk a little bit about what I consider to be the key characteristics of Builder BIM. We're going to talk a bit about how you can improve that situation by understanding how the designers are working. Then lastly-- well, not lastly-- the most of it is going to be about looking at strategies and hacks, given that framework.

Let's talk about what is Builder BIM? In my experience, a lot of the literature and the way the software around BIM works is it assumes this one-to-one relationship between the model and the application. If I'm doing 4D, there's an idea that OK, I can go back in. I can update location parameters within model elements. I can update phasing parameters. I can change geometry. I can break up a slab by pour, rather than just what needs to be there for the design drawings.

The reality is, when you're a builder, is you're actually always downstream. You don't have direct access over those models. I mean, you kind of can. You can go back in.

Let me just spell this out. You have your author. In this case, let's say it's the designer. You have a model. That is the model they're working on. And then that get published downstream, for use in your application down here, on the non-authoring end.

The first thing I can do is I can go to live model. I always hear this all the time. People ask me, is there a big shared live model that the contractors and the architects are all working on live?

The answer is almost always no. This isn't always quite an option. The other part of this is, I can maybe push it down and work on the published model as well.

I can add all those parameters in for the 50% DD model. And then when 100% DD model comes out, I can do it again. When the 10% CD comes out, I can do it again, and et cetera, et cetera.

The other thing we can do, and this is what a lot of the BIM planning literature revolves around, is maybe I can get the designer to do it. Those designers in the room, you have fees. You probably structure that fee not around my 40 needs. I don't blame you for it. I didn't necessarily change my contract for you either.

But also, this does happen on projects I want to point out, I'm not trying to pick on designers at all. This does happen on projects, but it is almost 100% propped up by just good intentions. And frankly, the kumbaya vibe around BIM, where people are like, yeah let's push this project.

Let's make it better. Let's work together more. But the catch with this is, is you can't always rely on this. And I'll talk a little bit about contractually, why you can't always rely on this later.

Of course, looming in the background of all of this is everything that I'm trying to do is of outside of the typical contractual framework. So the first thing about Builder BIM is it's downstream. It's downstream within the process. We don't make the models, we get the models. The second thing about it is, I mentioned, we don't make the models.

We're surrounded by authors. So we've got designers over here. We have our subcontractors over here. And in the middle, is a CM who doesn't model much. I might model some logistics, put some cranes in my model. I might make a detailed component, to see if everything fits together correctly.

But 95% to 100% of what I'm working with is somebody else's model. And that's going to be another kind of component about this, is how are you going to work on somebody else's model? Even though the builder isn't doing a lot of modeling, we end up being responsible for all of the models.

As we move out of design, the builders begin sharing the design with the trades for 3D coordination. We send the trade models back to design, in order to hopefully speed up the shop process. We're at this hub of all these swirling models throughout the construction process.

Then ultimately, at the end of the project, we're also taking those models and packaging it up for the larger turnover document. So it's a funny place where we are, where we're the curator. the shepherd of these models, but we really can't do much to them ourselves.

Then the last aspect of this is that we miss the BIM kick-off. When it comes to working with the designers, we hope they got together. And before they started modeling, they did a BIM plan. They began with the end in mind.

But we weren't there. Because even in a pre-con situation, I may be coming in sometime around DDs. The models are pretty well set by that time. And in a pure design, bid, build situation, I'm even coming on later, at construction documents. Once again, for all of this model content up here, I don't have a lot of ability to change it and to get parameters and the changes in it that I need. So we're even downstream when it comes to the actual deliverable process.

Now, if you believe that framework, you have three points of leverage that you can work with. The first one is you can do more here. What can we do to actually work with the people who make the models and get more out of that?

The second one is, you can work more here. What can you do to work with the actual live models themselves that end up coming down to you? So directly working with it. Then the third one is, what can we do at the application point?

So pure downstream. Published models, what can we do to make our applications, our 4D or our coordination, basically built upon this concept, that we're going to have models that we can't really edit very much. I'm going to move through each of these, for the rest of this.

Doing more here, working with the authors. The first step with this-- you're going to hear me say this over and over again-- is empathy. Reaching out, trying to understand what their process is. Then you can actually find where the collaboration points are going to come in.

Let's take a look at this. This is the AIA B101 Owner-Architect Agreement. I want to point out here, I'm not picking on the AIA. And I know designers in the room that are going to be like, well, you're supposed to build on this contract. You're not supposed to start with it from scratch.

But I do think it's interesting that this is the default position. And you have to add exhibits to this to change this. I also think that most of the contracts I work on, this is pretty typical for what is being asked of from the designers. 3D is typically not in the contract. if you look at the schematic design phase of services and the other phases built on this, you'll see that it talks about drawings and other documents.

You will see digital modeling down here, within a list of things like study models and perspective sketches. What's interesting about this is these are called instruments of service. They're basically inaccurate means to get to the design itself.

You can think of it. The other three things that are in this sentence, like a perspective sketch. As a contractor, I can't go on site and hold up a napkin sketch and put a scale to it and go, oh, I think this roof's going to be 10 foot, and just guess.

That's what the category is. It's in the same category with digital modeling. Digital data is an additional service. I should say, I've been on very few projects where I've had trouble getting CAD or getting the models, but I can talk about how we were able to do that.

For my experience, this tends to be as we've moved to digital, I think owners are just expecting this. It doesn't seem like it's something that's all that critical anymore. Then, forget about copyright and licenses. I'm more interested in this, the digital data protocol.

The trick is, if we know that the contract is going to be 2D at the end, and we know that the digital model is really this liability point for the architects, then we can actually begin to talk to them around that. Now we're not looking at it as something they're keeping back from us. It's really something we're asking for. It's a point of liability we're trying to connect with.

James Vadezande, at a BIM forum, when he was introducing LOD scope awhile back, talked about the digital protocol with these funny terms. There's a disclaimer approach. Some of it's not reliable. So don't rely on any of it.

There's a specified use approach, which I never see. Which is where some of it's not reliable. So only rely on what you can.

You can use this for 4D, but you can't use it for coordination. The disclaimer approach is the thing that I always see. This is going to be the first tip of the day.

Which is always sign the exhibit. I talk to contractors. And the first thing is they'll tell me there's no model. And there's almost always a model.

Then the second thing is they'll tell me yeah, they want me to sign this thing that says that they're held harmless for the model, and that they don't cosign on its accuracy. I don't want anything to do with that. The answer to that is, you can't completely avoid risk.

But you can pick the smarter risks, so sign the document. I have never not signed one of these documents. Because I want the model. The biggest thing I can do for myself as a contractor to understand the design is get the model.

By the way, the second tip, love the exhibit. The exhibit is great. It's like you're two people at a table, and you can unload the gun and put on the table and say, hey look, now one's going to get hurt here, let's just sit down and talk.

I take it so far that when I deal with less experienced firms that don't have their own in-house exhibit, I give them a package of AIA white papers on writing digital data protocols. And I say, take this. Hand it to your attorney. And then write something up that they think I can sign. That's how far I go.

Honestly, the great thing about it is, is that first sign of trust. When you sit at that meeting and say, look, I'm not here to screw anybody over. I really just want to get this conversation going.

The other complaint that I'll hear a lot about getting the design models, is this LOD thing. This is from Kaplan ARE Guides. Designers in the room, or at least architects, will recognize this.

Every time I show this to contractors they're surprised. They're thinking to themselves like, oh my god, why is the bar for schematic and design development so much shorter? And I think if you're a designer-- or you're an architect, you're looking at it like, because that's where I make all my money, is in the construction documents.

If you overlay the [INAUDIBLE] curve over the top of this, you can start to see, from a contractor standpoint, where the problems are. I've got generally LOD 200 stuff here. Which, if I'm on the project earlier, that's when I want to start getting my pricing and really tightening it up. So that I can start thinking about value engineering or something like that. But I don't start to get reliable numbers until somewhere around here.

Most of the time, once again, you're looking for the path of least resistance here. You can't really fight this. I generally am skeptical of BIM execution plans to try to front load a lot of the LOD 200 stuff.

Because at the end of the day, you're dealing with somebody else's modeling standards. And you might be able to get it to happen in a few specific circumstances. But in general, trying to raise that entire level, you're asking them to basically overburden the model and make it harder to make updates, harder to make changes to things.

My tip here, and it sounds sort of obvious, is talk to the authors. If you understand that this is where things are going to be at that phase, you can begin having a conversation with them and saying, how about this? Is it possible that we can get sizes on the steel by next month?

I know we're not supposed to get it for a couple more months. But that would help us do our early package deal. Or how about this?

I'll go the other way, and I'll talk to the estimaters. I'll say, do you really need every wall type at 20% DD? Or do you really only need four wall categories, like demizing wall, exterior exposure, interior only, mountable partitions, something like that? Because that we can actually do. We can generally look at the generic types and begin to intuit where those things are supposed to be.

This brings me into planning. The Dwight Eisenhower quote here, "[BIM] Plans are useless, but [BIM] planning is indispensable." I have been working with BIM plans for almost a decade now. I've written a number of templates for BIM plans. The thing that I've learned is that the dialogue is always much, much better than the document.

I would even go so far to say I don't like BIM plans. I'll talk about this a little bit more in a bit. But they kind of tend to get really long.

The longer they get, the less likely people are to read them. And the more detailed they get, the less people are to use them. It ends up being this thing that you do, and you move on. In LaGuardia, when we were during more active design, we just met with the design BIM leads every single week, and had an hour-long conversation. What are you guys working on right now?

When are you going to get to here? What's this going to mean for deadlines? What's this going to mean there?

The conversation was more important. That's when I reinvented the wheel and learned about something the project managers have known for a long time. Just have the meetings and then keep the minutes.

The minutes are nice. You still get that record, but you actually get something that's much more flexible, and much more robust. The thing I I really like about this is you always hear at the beginning of BIM execution plans, it's a living document.

But then nobody ever updates it. Because it's this huge thing that's hard to update. But the minutes truly are living documents. Every week you're making a new one and building on what you did last time.

With that said, the way I approach BIM planning, let's call it maybe a skinny BIM planning, is the first one is when you're not involved. Like I said, builders, for the most part, were downstream. They've already made a BIM plan, in most instances.

So when you're not involved, I'll typically approach it with a BIM Execution Planning Construction Addendum. It's a little 20-page document that I'll write up just to say, this is what I want to do with your models. There are some standards in here that I'd like to just know about from you.

But for the most part, this is my plan. This is how I'm going to do coordination. This is how I'm going to do 4D.

The thing I like about it is, once again, it's all about starting the dialogue with the designers. You show up and you say, hey, look, cards on the table. This is what I want to do.

Let's talk about it. Let's see if there are any obstacles in our way. I called an addendum because I like the idea, the non-presumption that it's literally just a thing that gets slapped onto the end of an already-existing document, and then lets you just move forward from there.

If you can be involved in the BIM planning, and even in that addendum situation, if I have the opportunity to nudge some standards that are going to help me a little bit, and really not cause too much burden on the design team, that's what I'm going to do. So if you can be involved, there's a couple of guidelines that you can keep in mind for doing this.

I started learning programming last year. If you haven't seen The Zen of Python, it's this collection of guidelines. Really, like, mantras for life. There are 19 of them in total, from the thing. And it's all about coding.

And the first one I like is "simple is better than complex." A few years ago, I was working on a project. When I first started out, when I was younger and more enthusiastic, to me, the BIM plan was this encyclopedic novella of what we were going to do on the project, and what we were doing. And I loved updating it every week. And they, of course, kept getting longer longer, with more diagrams. Like, super long, beautiful-looking LED charts, and things like this.

At one point I'm talking to a project manager. And he's looking at it. He goes, how long is this? I said, it's 142 pages. I was proud.

He said, how long was the last one? I was like, it was only 120 pages. And he said, aren't these supposed to be getting shorter? Why are they getting longer? If we're getting better at this, they shouldn't be getting longer.

The result is, I've started just cutting the fat out. LaGuardia, with all those eight projects and everybody involved, is 60 pages long. And about 20 pages of that is just for sheet nomenclature, because we have to have this crazy sheet nomenclature for 15,000 sheets.

It's all about doing the bare minimum and keeping it simple. For one thing, I focus on the essentials. For me, these are the essentials. Coordinate system, it's a no-brainer. File nomenclature, I need that to happen. At the same time, I'm learning more automation tricks. That are making file nomenclature a little bit less of a need to have.

Family nomenclature-- and I don't care about type nomenclature. I'll talk about that in a bit-- softwares, file sharing. Then this last one, PDF publishing standards. I need everybody, whether using CAD or Revit, to use True font. I need them to print to Vector, not to Raster. Because if I'm looking through 15,000 sheets and I want to do control-find bathroom, I want to just be able to find it, and not have to scan through, basically, pictures of the drawings.

So I'll basically focus on these. Everything else becomes a little more fuzzy around this. That's because every standard is a potential resource drain. The more standards, the more methodologies I build into this, the more I have to police the models that I'm getting. The more I end up just auditing models.

There was a point on projects where that was just a constant thing. Where I was just constantly auditing these models and saying, hey, you need to change these five things. You got 20 of these right, but I need the other 10 to be right. It's not a great way to spend your time. So the way I've learned to move beyond this is the first thing I do, is I try to document, not dictate, best practices.

Most of BIM execution planning for me is sitting down and just finding out what people do when they work. And if there aren't major red flags, let them keep working. That's because, frankly, when the deadline hits, when it's the day before 20% CDs, and a bunch of interns came on who've only been working on the project for two days, guess who's standard they're going to obey? They're not going to run back and be like, I wonder if this is in the BEP? They're just going to do the work based on the office standards they have. So I'm really trying to just go with the flow on this. The second thing is, performance, not prescriptive criteria. Those of you familiar with specifications, used to performance versus-- somebody help me out. I'm blanking on it. Either way. What?

AUDIENCE: Prescriptive.

PIERCE REYNOLDSON: Prescriptive, ah well, anyway. I don't want to tell people what to do or what not to do. I want to tell them what I need. I want the product at the end of the thing.

An example on this, the guidelines we have for 150-plus Revit models on LaGuardia looks like this. They're really general guidelines. Basically, kind of like expectations. This is what we need to see you have.

We do families only, not types. The reason for that is, it's a pain to manage every single type name across even just one Revit file. Also, everything I need to know about a type is in the type properties.

Last thing I want to see is a type name that's like, interior door, fire rated, solid wood, brass heart. Because I can look up all that stuff. I don't need a super long thing that I can't even read, and the tiny little Revit or a Navisworks parameters box. So it's all about keeping it simple. Everything we do on here is very simple, like this. It's what we want, not how we want to get it.

The next phase. Doing more here, working with the upstream models themselves. The approach with this, I have done projects where I've been co-located with the architect. I spent four days a week, and I was in their model. And I actually got to add the parameters I wanted, and clean things up, and it was really awesome. That happened once. Most of the time, it's about how do I actually get changes to happen in that model in a timely way?

This is another one from the Zen of Python. "If the implementation is hard to explain, it is a bad idea. If the implementation is easy to explain, it may be a good idea." I'm always thinking about, how can I get changes in that model that are super, super easy to implement?

Because once again, remember that a designer's fee is not based on doing adding every little property that I want into the model. It's based on making drawings most the time. So one part of this is, we create solutions, not requests. Rather than giving people a long email of all the things I want them to do in a model, if I can write that into a Dynamo script, that's exactly what I'm going to do. Because it's great. Suddenly, it, becomes instead of do this, it's just, run this. Open up your Revit file and run this.

The other great thing about it is, once again, with 150 models, I don't want have to open every model and run that Dynamo script. It's a lot easier for the one person in charge of this model to open it up and run the script, and just have 20 people do that, rather than me do it 150 times.

I'll be honest. On LaGuardia, we're doing this a lot less with the Dynamo. And a part of that is because, I'll show you in a minute, we've actually managed to come up with a lot of off-the-shelf solutions that don't require as much programming. So here's one that we developed with HOK, by the way, who's one of our design partners on LaGuardia.

They had this tool that turns scope boxes into section boxes. And we were sitting in a meeting. And we said, you know what? We really need concourse B to be cut up by our phasing.

Because we need a big chunk for steel, and then for concrete. And then we're going to do roughly the same thing for the exterior. And the last thing I wanted them to do is to go in and split every single slab. Especially since guess what? As the schedule changes, we're going to keep changing what this thing is, basically, all the way up until it has to be done.

So this solution was great. It allowed us to take the scope boxes. So my team, on the construction side, just makes all the scope boxes they need. They give that scope box file to the designers.

Then when they do their regular exports, they just throw the scope boxes in. They create the views they need, and then they crank it out. And now we just get those when we need them. And they're always there.

Another tool we're looking at-- good party last night, by the way-- is dRofus. This was another one HOK introduced us to. I don't know too many contractors using this. But it seems to be popular in the design world. Basically, what dRofus does, you take a bunch of families, or at least the way we're using it.

You take a bunch of families. And you take the properties you want, custom properties you want to be assigned to those families. In our case, we're required to have uniform at 2010 in every single object, in every single Revit model.

Once again, my team can put together this schema. Then this is actually a cloud software. We can host that schema up there.

Then the next time the designers open their model once a month, whenever they want to do it. They literally just kind of run sync. And it updates all of those custom parameters.

By the way, if I need to change it again later, they can just sync it again. We can just say in the next meeting, hey, run dRofus again this week, before the next upload. Once again, it's allowing us to package something downstream and send up the chain, and make it push-button-easy for people.

I'm moving fast 'cause I want make sure I leave some time for questions at the end. So more that we can do on the downstream application side. When I talk about downstream software, I'm mainly thinking about, there's that dichotomy between authoring software, where you make geometry; and then reviewing software, like Navisworks, where you're mostly just looking at and analyzing geometry.

For me, the downstream software, it needs to be lightweight. Because once again, I'm going to have to open a lot more models. I don't want to have to open a giant Revit model with the eight giant Revit model links inside of it. I want something small and compact.

Non-proprietary is my preference. Because once again, as the builder, I'm this hub of file sharing. And if I can actually import and export from this lightweight platform, and not have to open Revit every time I want a CAD file or an IFC or something like that, then that's all the better. Data capable-- the more that I am able to custom filter and parse the data on the downstream end, the less I need data standards on the upstream end.

The same thing with editing. If I can plug data into the downstream models, then once again, maybe I don't even need dRofus. At least, for that use at that point. Because I'm putting the data in myself.

Then lastly, I want it to be automation ready. Once again, I'm the hub of all this file sharing. So I really want to be able to automate as much of that as possible. I want to be able to automate federating the models. I want to be able to automate running the analysis and the audits. I want to be able to automate the exports, if I can.

Click on this, and here we go. I'm going to let you look at these while I take a sip. So there's a lot of Autodesk competitors in here. I apologize for that.

But at the top of the list, iConstruct, which is a plug-in for Navisworks, this tool is awesome. I make no money off iConstruct. This is just a super-cool tool.

It's like, 24 different plugins for Navisworks. And they do all this stuff that I just mentioned. You can add data into the files. You can export to IFC.

You can crop stuff down and do a pure geometry crop, and export just chunks of a building to IFC. It does 30 other things that I don't even really know about. So it's really cool.

Solibri is IFC-based. So it's non-proprietary. I can't export stuff in and out of it.

But at least, because it's an IFC, I know that I can get an IFC into any other piece of software. More or less. You know IFCs aren't that great. It also has a lot of really powerful data parsing tools.

Simplebim is one we've just started getting into. I wish I could tell more stories about it. But it does let you do more data work on the model itself.

Then, Synchro is another one too. I will mention this. iConstruct has some great 4D tools. Synchro also lets you do things to the geometry. Like, say this is a slab pour, this is a slab pour, this is a slab pour, rather than cutting it at the source in the Revit model.

I'll give you a couple examples of what we're doing with this downstream software. On the iConstruct end, we're able to actually put the data in that we need. We don't have to ask the designers for this data.

We don't even have to ask our subcontractors, like our precast fabricator, for this data. We basically can just get Excel sheets, either from the fabricator, or we can get Excel lists of the inspections that we're doing. Or in this case, it's the approval log for different shops based on piece.

I can actually plug that right into iConstruct. And then use iConstruct. It will literally create this tab with all this data in it, right there inside iConstruct. It works really, really well for objects that are discrete and have a logical tagging convention.

Obviously, a piece of precast has a piece mark. That piece mark only gets used once. A piece of steel has a piece mark like that. Some curtain wall works like that. It's not going to work that well on ductwork. At least, not that I know of.

But this has been a lifesaver for us. It allows us to do visualizations very quickly. It allows us to help out our QA/QC teams as well, by just moving data back and forth between the Navisworks model, and then Excel, which is what they're comfortable with.

This is one we actually paid for to have built, but I think you're welcome to use as inspiration. AC Resources developed this for us. I don't know if they're out here, but they're popular in the Northeast.

So we get all these civil 3D models. And we need to split these up. They're obviously not going to install the LaGuardia runway area in one giant slab of asphalt.

So we need to break it up based on this phasing. Also, we need to change it all the time. Because as they're working with this and schedules change, they're going to change this layout.

Our schedulers and our logistics people are. This allowed us to take a polyline within CAD. Basically, put the task ID for that polyline inside. Or put the task ID from P6 into the polyline.

Then it would just chop up that Civil 3D surface for us. We pump it out in the Navisworks. And the search sets just get made automatically.

So this is actually my closing slide, now. I think the key thing that I want people to keep in mind is, once again, it's about empathy and it's about engagement. It's about being curious with the people you work with, and really just trying to find those points of leverage, those points where you can get the most out of it. And really trying to not force your system onto somebody, but actually just try to find the common linkages.

Wanted to leave enough time for questions at the end. So I'm going to go ahead and throw it to the audience. By the way, you're welcome to call me out if you think my reading of contracts or anything else is wrong. I'm happy to hear your opinions. Anybody? Yes, you.

AUDIENCE: All the information that [INAUDIBLE]?

PIERCE REYNOLDSON: The question is, what's the point of pumping--

AUDIENCE: All that data--

PIERCE REYNOLDSON: IConstruct data into Navisworks? It's really the Excel data that goes into Navisworks via iConstruct. For us, a lot of it's visualizations.

The other thing is, it actually helps us go two ways as well. Because we can take some of the model data out of Navisworks and put it back into their Excel sheets, if they need things like lengths or anything like that.

For the most part, I think besides the visualizations, it allows us to plug it into our mobile solution as well. So we're using 360 Glue with SharePlus. Basically, they're able to check stuff off in SharePlus. Then they can pull up the model, these model views, in 360 Glue, and see which steel is getting checked off.

It's a good question, because if it's just visualization, and it was a lot of effort, I wouldn't do it at all. But since it's pretty easy and it's visualization, and it helps us run our meetings, than it's worth it. You?

AUDIENCE: One thing [INAUDIBLE]?

PIERCE REYNOLDSON: The question is, what do we put in our subcontracts on the downstream side? I want to point out, by the way, I was originally going to have a big subcontractor chunk in here, when this was a 90-minute presentation, that I ended up having to cut. I think it's interesting to point out that there's an opinion amongst contractors, like, oh, subcontractor's are gonna do whatever I tell them.

But it's the same story as when you're dealing with the designers. They have in-house standards. They have a way of working. The last thing I'm going to do is going to tell a subcontractor what family to use in CAD map, right?

A part of it there is, once again, working towards performance criteria. Our LOD, in that instance, is not trying to get into, you will have these following things. It's more of a-- what is it? It's an inclusions list, not an exclusions list.

So we'll say, OK, we're going to have steel. We'll have bolts. We'll have this, we'll have this. Then anything else they want to have it in is fine, as long as they hit that minimum area. Also, we have kickoffs with our subcontractors.

So I have an initial kind of boilerplate subcontract that I'll put out there. Then as we're interviewing people during the bid process, we're trying to get their feedback. And frankly, if it's a good suggestion, hey, we would never model, I don't know, wiring, for instance, which always comes up. Then we'll have a conversation about it.

Typically, we're either going to win them to our side. Or we're going to say, you know what? That's true. We don't really need wiring. I just need what's in the rack. I thought I saw another hand over here. Yes?

AUDIENCE: [INAUDIBLE] solutions?

PIERCE REYNOLDSON: OK.

AUDIENCE: [INAUDIBLE]

PIERCE REYNOLDSON: The comment was, in the Netherlands, there's a fourth option. Which is change the contract, and I couldn't agree less.

Part of what I'm hoping to accomplish here is a bit of a stealthy, let's change things from the inside. Then maybe the contracts will follow a little bit. It's also a way to approach what I always hear called IPD lite, or IPD-ish contracts. Which are like, literally nothing's different. But we had a talk about IPD at the beginning.

The good thing about the IPD lite, by the way, is it means your owner's like, I actually really want you guys to talk and collaborate. So this kind of stuff becomes not just a thing that you do because you think it's a value add. It becomes something you're doing as a mandate. Which is what I prefer. But I totally agree. I think it's really about the contracts. Jim?

AUDIENCE: [INAUDIBLE]

PIERCE REYNOLDSON: Yeah, absolutely.

AUDIENCE: [INAUDIBLE]

PIERCE REYNOLDSON: The comment was talking about how even when the contracts change, that the context doesn't necessarily change. It becomes about how do you find those moments, as least resistance within that contract? Jim brought up that LaGuardia is a design, build contract.

At the same time, we're still in different offices. The model doesn't get built on a computer behind me on site. It still happens on HOK's server, on WSP, Parsons Brinkerhoff's ProjectWise application.

So you're still dealing with that upstream, even though it's a design, build situation. Unless you're in a pure IPD co-located situation, even though the contract's different, you're still kind of fighting it. Another thing Jim brought up is something like LaGuardia, the contract is so big and complicated, even though it's design, build, that you're also not trying to kind of recreate that overly-complex BIM execution plan within the contract.

And have to go point by point, to be like, you're actually going to do this, this, this, and this. Because it's on sub paragraph 5, page 87. It's really about trying to have that conversation, and make sure you kind of build a larger understanding.

AUDIENCE: [INAUDIBLE]

PIERCE REYNOLDSON: Yeah. [LAUGHS] Absolutely. I think one thing I'll say too, about the contracts, is that clients actually love this stuff.

When we do proposals, and I come in with like, hey, the BIM is all about growing the amount of interaction we have with the design team, with the owners, with the subcontractors, with everybody. It's all about growing this, making things big and transparent, the clients love it. They're behind it.

Actually, one thing I like about making sure that that bit of propaganda gets in there at the proposal stage, is it's a thing that people remember throughout the project. So when you show up two months later, with your BIM plan, they're like, oh yeah, I do remember being excited about this. Oh, go ahead.

AUDIENCE: Hev you implemented, like, a [INAUDIBLE]?

PIERCE REYNOLDSON: A protocol? You mean an actual contract exhibit?

AUDIENCE: Yeah. Just anything like that, [INAUDIBLE]?

PIERCE REYNOLDSON: Absolutely. Yeah. The question is about how we do constructability reviews during design. This might be another good example of a trust-building, hands-off approach.