Hard Questions Only! A Multidiscipline Panel on BIM and Digital Transformation.

ROBERT YORI: Hi, everybody. Thanks for joining. Welcome. Just a couple of introduction slides, obviously, the class is Hard Questions Only, A Panel Discussion on BIM and Digital Transformation. That's not the advancer. That's the advancer. Here we go.

I am your moderator for today. My name is Robert Yori. I'm with AECOM. I'm the Digital Solutions Studio Lead in the New York office of AECOM. I'll introduce the panelists here in a moment.

I just want to give a brief overview of the session today talking about the reality of digital evolution, and digital transformation, and organization, generally, where we are in that process, how you think we're going, also, understanding how to drive transformational change in our organizations, whether that's incremental or revolutionary. And then talking about maybe probably-- you may have experienced this once or twice in your career about silos typically related to disciplines, understanding those points of tension and perhaps, friction. Some chuckles. Yeah, chuckles of familiarity.

So what we're going to do is, we're going to try to have a robust conversation starter here on the stage. And then at the end, we'll probably hold out the last 15 minutes or so for Q&A. So I'll have to keep an eye on my clock here. Hopefully, that sounds good. Excellent.

Also, last but not least, huge shout out to Sean McDonald, and actually, to Christine, because I had nothing to do with this presentation except for chatting with these guys, you know. And I've had the privilege of knowing at least some of you, and the privilege of meeting you as well. But these are kind of topics we talk about on a regular basis. So it was Chris and Sean who put this idea and realized this entire panel.

CHRIS SHAFER: Mostly Sean.

ROBERT YORI: Mostly Sean. All right. Well, mostly Sean.

CHRIS SHAFER: He took the bull by the horns and got the people together.

ROBERT YORI: Excellent. So shout out to Sean, our Executive Producer here. So he gets all of the credit. And I get all the blame for whatever goes wrong. So--

[APPLAUSE]

What's that?

CHRIS SHAFER: Do we get it with everything now?

ROBERT YORI: Everything? No, I'm sorry, that's a tall order, man I can't do that for everything, as much as I can. I'll just introduce our panelists here. The full panelist bios are in the handout. So I'm just going to go briefly and introduce down the line.

Shane Burger, Principal and Director of Technical Innovation at Woods Bagot. Chris Shafer, who's Digital Delivery Leader at HDR. Kristopher Dane, who is an Associate Principal and the Director of Digital Design at Thornton Tomasetti. Nora Swanson, who's the Director of Design Technologies at ACF. Anthony Hartke, who's the VDC Manager in the mid-north region for Turner Construction, and Laura Saravia, who's BIM Manager at the Port Authority in New York. So thanks all for joining.

There's not another slide, right? The next one is the closing slide. So I'll just leave that. So Chris and Sean thought it was a good idea to keep everybody's names up, because maybe you might want to ask us a question. So that's who we are. Sorry, that you have to look at us twice, but at least there's names on that one.

So really, just kind of getting down to the questions itself, this is kind of a long intro to a question, so apologies for that. But I think about digital transformation being a pretty complex evolution of work in an organization. So there was a Salesforce blog post that I came across a number of years ago that broke digital transformation down into three aspects, dimensions, phases. I'm not exactly sure what the right word is. But the first is digitization.

And digitization would be really just making digital versions of the analog things that you already had. So that might be scanning all your drawings into PDFs. And then there's digitalization, which is actually using the digital versions with technology to help do what you do a little bit better. So my analog to that is maybe you use Bluebeam for coordination, and you overlay PDFs as opposed to a physical lay table. You're still doing a lot of the same things, but you're doing it in digital space as opposed to physical space.

And then the third is digital transformation, which is really sort of fundamentally rethinking the exercise or practice, and technology being a key part of that. So the example there of course, would be using a tool like Navisworks or something for clash detection instead of doing sort of the analog overlay. And then if you want to crank it to 11, these go to 11 version of digital transformation, is investigating routing algorithms, so you don't have collisions in the first place, right?

And I don't think that there's one-size-fits all solution for everything. I think digital transformation is not a monolith. And the goal of everything is not to get to a fully fundamental all digital universe where everything's cranked to 11. I mean, I think it's a nice goal, but I think in reality, I think there's shades of each I think, in any digital transformation. And I think they vary by organization.

So based on that very long question, just want to get sort of a temperature check on your thoughts on digital transformation in your organizations, and kind of where you are, and if you see a prevalence of digitization, digitalization, digital transformation, what your goals are for that, if you have an idea about if there's a balance, or just generally, get your thoughts on where you are as organizations. I guess, we can start down the row. So maybe, Shane, if I could ask you first.

SHANE BURGER: Yeah, sure. So I appreciate that description from Salesforce. There's a very parallel description that I've been talking about within our practice, which is the three levels, which is effectively, a change in medium, a change in process, and a change in product. And I think the change in medium has always just been about we're going back 20, 30, 40 years now of the movement from standard drafting into digital-based drafting. So that was pretty simple, or arguably simple. At least we look back on it now, it seems like it was simple.

The process change is the one that we've been in for such a long time now, which is fundamentally changing how we interact with each other. And there's a lot of conversations about that in our practice. And we still have people in this mindset of thinking that just the translation even to Revit is, yep, check, digital box done, right?

But actually, the ways in which we interact with each other, we're-- company has 17 studios around the globe. How do we interact? How do we share projects and location location? How do we interact with the other people as part of the AECO on that set as well?

And we're still getting more education around the kind of change management side to get people moving into fundamental changes and processes. But what I've appreciated is how quickly people have moved to the third level, which is the change in product conversation, which ultimately is about-- I'll back up for a second. If the previous phases were about designer experiences and how they do their work, the client experience becomes a much bigger conversation.

So how do we work with our owners and operators? And what are we actually providing them, both in terms of our actual deliverables, but also our consulting engagement? And what I've appreciated is that when we got to that moment, I feel like a lot of leadership ears started to perk up, because maybe they're seeing new services opportunities. So it wasn't just about efficiency, and it wasn't just about new design opportunities, but became about new relationships with our clients, and consultants, and everyone else.

So I have found that we've had the greatest success in bringing people along in that journey if they see what that last level is, which is your relationship with your clients, and consultants, and owners, and operators, and ultimately, the public, is where we're going right now, even if we still have to get through the efficiency phases. But it's all over the place depending on the studio and the leadership that we engage with. But I'd say in the last year or two, there's been some really fruitful conversations about that last part.

CHRIS SHAFER: I'll make it a little counter to Shane's is, when we see these digital transformations, we find that a lot of people step back. And when we think of digital transformations, a lot of people see it as all right, we're going to be hitting home runs. There's some tool that's magically going to change everything.

Where we've taken a little different approach, and where we sit, we're going to focus on very small steps, focus on base hits, make sure everyone's comfortable, and really getting batting 1,000 on base hits, and doing the little things here and there with the goal, and everyone's aware of those goals, of getting to that level of efficiency and effectiveness that leads to the home runs. So it's taking a very baby step approach to this. What we find is a lot of times our clients, if we go and introduce these big concepts, and these big ideas, they kind of step back. And so how do we prepare them in ways that they feel comfortable with?

KRISTOPHER DANE: So I think within Thornton Tomasetti we also have multiple offices. We have 50 offices. So I think, depending on where you are in the organization, we're at different points in that spectrum evolution, whatever it is. I think what's happened over the last couple of years is that the floor-- I can never keep the term straight-- digitization, you're not doing analog. You're doing digital. I think we've raised the floor on that, right?

So everybody is working from home. We're all using digital formats for almost everything we do, which wasn't true two years ago. And at the opposite end, there are parts of the company that are experimenting with AI as a partner to the structural engineer, either for doing code reference look-ups, or for actually doing schematic design. But there's a huge part of the organization-- and that's the game changer part-- there's a huge part of the organization that for whom advancing along that spectrum looks more like let's do Revit better, right? Let's have schedules that are driven by the model, right?

Let's have model-driven drawing sets, because that's still what we're delivering. So I think I like to kind of bring our perspective internally is like, the AI is useful and interesting to explore, but we can get more quicker wins with those base hits, right? And there's still opportunities there.

ROBERT YORI: What about you, Nora?

NORA SWANSON: Similarly, at AKF, we're having experiences like Chris and Kris, and with multiple offices and varying levels of experience, and varying levels of acceptance to change, and to digitization, and all the levels, just making sure that we are applying the appropriate level to the appropriate project, right? We have some bigger projects where it makes sense to try to go for the home run, some of those longer burns, some of those larger fees.

But we have so many projects where we're reissuing 2D PDFs. No one cares what's in a BIM model. But we want to make sure in house that we are still trying to use all of those workflows and all of those tools, so ultimately, looking forward, we can use those data sets for AI, or for algorithms. Are we there yet? No. But are we trying to set ourselves up for success? We're trying.

ANTHONY HARTKE: I would say from the contractor's side, we're very much an entrenched industry. We are all about we're checking the boxes, we're following the checklist, we're following the specs. It's all get something done and move on to the next thing. Get something done, move to the next thing.

The transition from paper documents, so paper checklist, or paper whatever hand estimate, hand take-offs, moving from that to a digital tool is not a huge lift. We're finding more and more success of that, because it's allowing the teams in the field to do it quicker, more efficiently, versus filling the paper out, go stick it in a file cabinet.

But what's happening is the easy step is just taking that paper thing and making electronic. It's still a file going into a file folder. It's a dead end piece of information. It's a dumb document.

The next step that we got to look at is, how do we get that data harnessable? What we're seeing in the industry right now is we're seeing a lot of tools out there that are-- they're still working with that PDF, the digital document. You can extract some of the data out of it now because the technology is able to read it thanks to AI and whatnot. But the thought process has not been put into place to figure out what data can we collect, what data should we collect, and how is that data going to inform future decisions and future actions.

So to me, that's where our next step is as a contractor is, we're collecting and generating all this information. But are we collecting and capturing the right information? And how do we use that to drive future decisions?

So one example, we've got this Ladders Last Program across Turner. We don't want to have ladders on the job site because it causes injuries. People fall off ladders, all kinds of stuff. The form requires a tag and a form inspection checklist. We've got that electronic now.

But if you think about that concept of if we do have accidents, you can go back and look at the ladder inspections. What are the common denominators? What are the driving factors that are leading indicators to when these accidents start to happen? So we can start creating those metrics as key metrics to warn us ahead of time of hey, you're starting to see this same thing happening over and over.

That's a red flag. We need to stop the project. We need to figure out how to prevent it from going any further. So we're taking a proactive step versus taking a reactive step. And that to me, is that next step that we need to take in digitalization.

LAURA SARAVIA: So me as a BIM Manager at the Port Authority, working for a governmental agency, it's like a very long process for the digitalization, or the digital transformation. As you mentioned, there are like three steps, or three phases. I believe, we probably are in the second one. We didn't do like the full thing.

We are working on it. We're implementing BIM. But yeah, today is a big challenge, because there are different divisions. Each division have their own process. So coordinating all the divisions, integrating the process, the workflow, also working with different consultants, different companies that are outsourcing the project. So it's kind of yeah, it's kind of tricky, but yeah, we try to integrate everything from the agency.

ROBERT YORI: You brought up a really good point, which kind of leads to my next question. And this will be-- we won't go down the line for everything. Sorry. This is like a jump ball, right? So you mentioned something that I've observed, and I think we probably all observed in some form or fashion is, oftentimes, where a digital transformation effort struggles is between parties, between let's say, an architect and an engineer who might not be in a particular workflow, or between an owner and the consultants that are contributing, right, and the goals that you might have as an owner for the models that you need versus the goals that an architect, or an engineer, or another consultant might have for their models, and how they reconcile.

So just wondering, again, anybody chime in if you like, just kind of thinking, what sort of friction do you observe perhaps most prominently, or most often? And sort of, what are you-- what are you addressing first, I guess, because I'm sure that there's frictions and pain points all over. But like, have you found one to be of particular concern? And what steps are you taking to address that?

NORA SWANSON: I can jump in. Sure. So as MEP engineers, we are pretty much as far down in the contractual pecking order as you can get. And so we really have to be agile and adaptable to what's coming at us. Sometimes, we have the ability to drive change in our architecture owner partners. Other times, they're driving change in us.

For example, we made the decision to go 100% Revit about three years ago. And we still have numerous architectural clients that still only produce in CAD. So we had to develop workflows to do what we call CAD to Revit, in which we link in CAD backgrounds, and still produce our work using Revit and those BIM tools.

So I think figuring out how to maintain a level of consistency in what we do, while being able to receive information in all types of sorts, because even if we receive architectural models, some are really good like up here, others, I hate to say it, hopefully, there are-- actually, there, are no bad architects in this audience right now today. But other models are not that good, and we really have to have plans in place to be able to adjust to what we receive.

CHRIS SHAFER: Well, I was going to say that as the architect, we are just telling the engineers what to do here. So thanks for basically answering that from the start. But we're trying to be really conscious of the level of capabilities of the sub-consultants as much as we can.

But at the same time, we feel like we have a contractual obligation with our clients to kind of push the envelope as we go. So that means at times, pushing the engineers out of their comfort levels if need be, or also being receptive to ideas that they may bring on board. And I think really, in the last two and 1/2 years with basically the marginal adoption of BIM 360 to all in, that has really forced us to really open up the possibilities and the experimentation that's come along with it, and really shown us the power when we truly do collaborate, take advantage of a lot of the tools available, we are kind of getting back to those promises that we're I guess, we're hoping to achieve.

SHANE BURGER: I think two things that come to mind where we run into some frictions, I mean, and honestly, like the most ideal scenario, and you'll know this from my background, Bob, is that we're in New Orleans, like, the ideal scenario for me is like a reference to jazz bands where you've got like a central mission with the overall melody is going to be, the chord changes. And everybody can listen to each other, and work together, and create something amazing where the tension actually results in something better, right? You make everybody push themselves, even better. Unfortunately, we don't get that in a lot of architectural projects.

ROBERT YORI: That'd be a mess.

SHANE BURGER: I mean, it'd be awesome. It'd be great. But the two things that come to mind for me, one, is the kind of change in frequency and pace when it comes to how often architects are changing their designs and the frequency at which that goes to MEP and structural. Years ago, it used to just be the MEP and structural would just kind of be sitting back twiddling their thumbs waiting, when are you going to finish changing the design, right? That's still--

NORA SWANSON: Then rush at the end.

ROBERT YORI: Right, right, and there's a huge rush. But we're wanting to get more feedback from you. It kind of depends on the positivity of the relationship. If you're in alignment as to what the vision, then that works well. But sometimes, it breaks down in the detail level. And I'm not just thinking about a good model element matrix that says what LOD and whose ownership of each particular part is, but it could be the difference between as an architect, we're often dealing with the geometric representation of information. Whereas, an engineer, you're often dealing with an analytic representation of it. And we have a disconnect between those.

And in different parts of the regions we're for example, having to model a lot more-- I'm not just poking just at you Thornton Tomasetti-- but the structural model then I feel we should be modeling, because we're very interested in particular details about slab edges, column locations, openings, all sorts of things that are going to manifest in how we put together our facade packages, or all that information. Whereas, we're not getting that same level of modeling from our structural engineers maybe in an earlier stage that we would like to have.

But this might just have to do with a lack of shared mission, or shared agreement with how we're supposed to be working with each other. We think that model element matrix is answering all that. No, it's not. So I think that's something that I think definitely could be better, which is understanding that there are elements within your models which have shared ownership and shared but different representations, and different priorities. And we still haven't sorted that out.

KRISTOPHER DANE: That's right. And I think we also have-- I was thinking that you're sort of on the tail end of the design, right? I'm waiting for the architect so I can do my work. So structures I think, used to be there, but increasingly, we're in the early package. So it's like, hey, we need the structural package to go out before we've even designed the building.

What? How do we do that? And what that means is so we can come up with something. We can have a conversation. We can have an educated guess.

But then what we need to have an open communication about is, there's risk in this design, right? And we're carrying contingency, and we're carrying assumptions. And those aren't things that are sitting in the model for us to find in BIM 360. Those are things that we need to talk about outside the bottle as the design practitioners.

And that's often where we see the friction is. Sure, there's how do we collaborate? Now, everybody is in BIM 360. So it's who's modeling the slab edge. Maybe we both are, and we need to sort that out, all of that.

But then it's how do you track those assumptions, and sort of track the evolution, and sort of completeness of the design as you go ahead when it's not something that you can just see in the model, right? The well, it's in the model isn't an appropriate answer to that question. So you have to have this like line of communication in parallel.

ANTHONY HARTKE: And I will say, it's like a family bickering. But on the other side, we're getting all the same problems on us of how developed is the design. And we need to go put packages on the street. We got to go bid the work. We got to go install the work.

And then at the other end of the table, we've got the owner putting pressure saying, well, we bought BIM. It's the drawings. It's in the model. It's like--

SHANE BURGER: Isn't it all fixed?

ANTHONY HARTKE: But it's not right per se. It gets the design intent across, but we got to take it over that finish line to get it to constructable. And what we're finding is we're getting more and more pressure to build faster, especially in today's market where everything is just crazy pricing and whatnot.

And so one of the strategies we're really pushing for is to get that early collaboration, early working together, identifying. And you mentioned BIM 360. I don't want to shill for our hosts here, but just the ability to get eyes on the designs that's happening. We're not looking to push and change anything, but we want to raise the flag of hey, this is a constructability thing, this is a piece that we're going to need more information on, that early structural package, which is done before the architecture. Somehow.

And so we're trying to help inform of looking at your details, looking at your information, we need you to spend a little bit more effort on the underground MEPs, because it's going to affect how we install the underground. So it's that communication and collaboration, be it 3D, be it 2D, there needs to be that open conversation and breaking down that wall of, we're not done with our design yet, so you just wait. It's like, but if you give me an 80% done design, if that 80% doesn't include what I need, then it was a waste of time essentially.

NORA SWANSON: Just to jump back in on the MEP a little bit there in regards to issuing things before they're ready, or trying to get designs on drawings just because you're supposed to according to the deadline, we have really focused a lot on what is ready to go out based upon the decisions that are made in that particular project. Is the architectural programming set? Is the structural set? And how can we as MEP designers still produce a valuable product that pushes everything forward without setting ourselves up for throw away sets, or for rework?

And we're really trying to utilize things within Revit a little bit differently to do that. Obviously, we need to get major pieces of equipment, and major duct runs, and pipe runs, and conduit runs-- that always trips me up-- in there, so that it can be coordinated. But do we need everything at the distribution level? Probably not. But can we express what's needed at the distribution level in a different way?

Can we do typical room designs? Can we use Revit spaces in HVC zones to kind of plan out and show an owner how things are going to piece together? Yes, we can. And so that's kind of the strategy that we've taken.

ROBERT YORI: Laura, I know you're dying to weigh in on this.

LAURA SARAVIA: Yeah, I just wanted to mention that in the agency we also face that problem between the design to construction. So usually, that is a very big step, and there is a lot of challenges between those two things. So today, we change the workflow on projects, and we have the design build.

So the conceptual design is done in-house, and then it goes outside. And the responsible for the design, and the drawings, and the construction drawings is the same as the construction itself. So they are ownership of both things. So that is one of the solutions we try to implement now in the Port Authority project.

SHANE BURGER: Just one thing I want to note that we've had some interesting successes recently with earlier engagement with MEP and structural, specifically MEP, and it's been centered around conversations on carbon. So it's like, with all the conversations around both embodied carbon and operational carbon, it's actually helped us as architects realize what the value is from getting those early conversations about how we are actually going to bring energy through the building, how are we going to condition the building, where are the structural approaches that are going to be the lowest carbon approaches for us to have it.

So I feel like if there's one potential bright spot out there for us to all be looking at is to say, let's take advantage of the conversations around climate change and carbon to be one of those rallying forces that says, no, actually, let's talk with each other a little bit more about what we could do versus, the architect is going to go to traditional route. Everybody's going to do traditional thing. And then halfway through, we're like, oh shit, we should probably try to reduce energy and reduce embodied carbon on this. And it's just all surface treatments, and nothing significant.

So I have appreciated that when we've had some really good partnerships like that. Bringing everyone in earlier maybe sets a better tone for everything that comes afterwards.

NORA SWANSON: Agreed.

ROBERT YORI: So just before we went live, we were chatting about something, as we're talking about this, I'm thinking about modeling in two different ways. And I'm thinking about modeling as part of process. And I'm also thinking about modeling for outcomes. And process and outcomes can be different.

So let's say to an architect, the outcome would be the thing that you would deliver to a contractor. However, an outcome for you would be as an owner, would be something different, right? Or to an engineer, the outcome of an architectural design process might be something different for all of us.

But I think largely, again-- this was spurred by an earlier conversation today-- largely, what we see in the industry now is modeling for outcomes. And process is kind of mentioned as part of that outcome, which is not a bad thing. But in the chat we had before the mics went live, we were talking about the different types of models.

So Shane, you mentioned sort of the analytical models versus the physical representation models and how they can differ, and how oftentimes, for good reason, how they differ, and sort of how to reconcile that. And apologies, I'm not really sure I have a fully formed question here. But maybe I'll get there, I hope. How much time do we have? No, but just your thoughts on kind of the current state, and where you see the opportunities for how those two types of modeling, or modes of modeling might coexist for your point, what information you're getting in, and what you're outputting along this design and delivery chain.

CHRIS SHAFER: One of the things that we're really starting to talk about is, there's always about data, data, data. But trying to get our users to understand that every action in what we do there's data points that are associated with it, and that that data will be used for that final deliverable. But largely, it will be used on future projects.

Nora had mentioned that there's a lot of unknowns in the process of the architecture is in a certain phase. But if we can use that past data to kind of predict where to fill in a lot of those gaps, because we do 400 or 500 projects a year, there's a lot of data and understanding well, what did we know at these certain junctures? And how can we use that past data to fill in that?

And so we have these analytical models based off of deliverable models. And then it creates this cycle. And so we're trying to build that foundation of a thought process, and the way you approach design, where design isn't about a pen on paper, or an object in a model. It's about the data that's associated with it just as much as anything else.

ROBERT YORI: I think it could work the other way too. So you mentioned the analytical model as a result of the design model. But in some ways, it could work exactly the opposite, right? So Shane, I know I've seen a lot of great presentations from you where so much analysis goes into your early stage work. So the design model is actually an outcome of the analytical models, right? So I think that might be able to work both ways as well.

SHANE BURGER: Yeah, I think I've been talking about this a lot within the practice recently. And I don't have a whole lot of things specifically to share on this. But we've been engaging in broader conversations about topic of like, of augmented design, and what does augmented design actually mean, and how we bring analysis to actually affect the design process.

So I've heard it said a few times, but if you look at the idea of product design, a good product changes behavior. So if we've actually been able to change the behavior of our staff to take in more information about the data that they learn from their model, simulations that are associated with it, and it actually affects design, right? It's not just it's been post-rationalized, or just to win a client to show the pretty false color analysis of solar work on it, but it actually has changed the behaviors of our designers, that's where the biggest impact ultimately gets for us.

So we've been having a lot of conversations about both build and performance analysis, and spatial or social performance, how do people interact with each other. I've kind of felt that architects have very much, unfortunately, ceded their knowledge and territory and understanding how people actually behave with each other, and how they work with each other, we've lost the scientific aspects of that. And we have a lot more opportunities to do that.

So the way I'm thinking about is, that you have lots of representations, or lots of models that you can have. We've unfortunately, as a practice been focusing on a representation and drawing form in a representation in a rendering. We haven't necessarily understood those representations in terms of performance and analysis. And it's something that we're having to re-educate our entire workforce to get into.

So we're at the beginning stages, I would say. We've had some successes in some areas. Come back and talk to me in six months. But this is our big push in our practice right now is trying to re-educate our practice around these multiple ways of representing and understanding your design that are not just traditionally what Revit, and Rhino, others have been providing you.

KRISTOPHER DANE: Right. And just picking up on that point, you know, the-- I always think it's important that we don't kind of overstate the value of the improved collaboration tools that have been adopted certainly, over the last few years, but really developed over the last 10. It's like, we've got good collaboration now around the geometric model, right, the drawing representation, the representation that would end up in the renderings. But there are many disciplines that overlay on that right, where the analysis model is fundamentally different from that geometric representation. And as structural engineers, we need both, right?

We need the structural analysis representation. Inside TT, we do other kinds of work. So you might have a more of massing model that's used for CFD analysis, or for blast studies. There's yet another representation that I use in some of my work around crowd modeling, where it's informed by the geometry, but it's different in substantive ways. And it's just not the same thing.

But they need to coexist, right? We need to understand the relationships and the level of effort involved, and the trickle down effect of changes. And all of that starts at that early engagement you were talking about where on the design team, we need to be able to say, OK, when we talk about a design freeze, here's why it matters, right? Here's how it's going to facilitate the work that comes after that. Here's how it lets us do that validation.

SHANE BURGER: Just a quick thing, I think we've gotten away with as architects for too long with not having to think about as many representations as we possibly should. So the comment about lack of understanding of spatial experience and social experience, we don't do any of that stuff. But we're seeing the others doing it, and we need to know a lot more about that kind of thing, and start bringing our other methods of representation in. We've had it easy, I guess.

NORA SWANSON: Something we're currently working through now is how best to complete our HVC load Calix, one of the biggest things that we do as MEP engineers. I don't know how many mechanicals are out there, but train trace is sunsetting, one of their main platforms that we have all used for years and years and years, and everything is now going to volumetric analytics. And so we have tested out many programs.

We actually started with the newer Revit load analysis product. And at first, went hmm, not for us, then subsequently, went and saw a couple of others, and have since circled back to that. But what we've found similar to I think what your experience is, is that we can really only be informed by what the architect gives us.

We are having to basically recreate architectural models in order to perform the load analysis in Revit, frankly, because the tool really kind of only starts to shine in Revit 2023. And a lot of the architects that we work with are not using that version year yet, on top of the fact that a lot of the architectural models are potentially more complicated than we need them to be for load analysis. And so we are having to kind of do double work in order for that analytical model to happen.

ROBERT YORI: Laura, I'm afraid I'm going to put you on the spot. Sorry. Because one of the reasons that this question came to my mind is you mentioned that you do a lot of the early phase work, and then you distribute that to folks that you work with in order to execute that design, right? So in some ways, it sounds like-- and correct me where I'm misinterpreting here-- it sounds like you're doing modeling as process inside the Port Authority. And then you're sending the result of that process out to be more fully documented into a constructable solution.

During that process, let's say when you're engaging with your consultants to do that sort of work, how engaged are you with that? Like, are you as the designer of that, are you engaging with them to make sure that your original design intentions are continuing to be followed? And do you become part of that process, which then they return back to you as an output? Or is it a little bit more autonomous? Do you handle the relationship with your consultants a little more autonomously?

LAURA SARAVIA: Yeah, that type of workflow, it happen in some type of projects, usually, are the smallest one. And yeah, everything is developed conceptually in-house. And everything that like we finished that stage with documentation, and that is handled to the consultant, or the company that is going to work on it. And yeah, we have the leader of the project is going to follow up on all the changes that are done on the other side. But yeah, it's open to more development and changes for answer in the right proposal, you know?

ROBERT YORI: Cool. So I think the timing is good. Yeah, actually, this is good. I'd like to open up the floor for questions or thoughts. Certainly, these aren't all about the questions that we had prepared.

KRISTOPHER DANE: Can I ask a question?

ROBERT YORI: No, of course, you can.

KRISTOPHER DANE: Laura, this question is for you. So we were talking about different representations of the building different types of models. I feel like every conversation around whether it's BIM, maybe now we stop saying BIM. We start saying digital twin all the time, whatever the buzz word of the day is.

It's always like, look, if we do this right, it's going to help with facilities management and operation. Is that a real thing? Like, is it actually helping or not? We're structural engineers. So we don't see it, and you don't care where the columns are. But I've always wondered, like, does it matter? Is it helping?

LAURA SARAVIA: I believe it's a process. And it's good to believe on that, is having faith that is going to work at some point. We're trying to do it, but it's in a way, you know?

ROBERT YORI: It will help.

LAURA SARAVIA: It will happen. Yeah, because it's not easy to get a model that really can work well in facility management. So yeah.

ANTHONY HARTKE: Can I piggy-back onto that?

ROBERT YORI: Go, please.

ANTHONY HARTKE: So what we find is being in the center of that, we got the generation of model here. We've got the end state model here. And we've got a parallel stream of fabrication, installation, coordination work in place tracking all the more parts and pieces type of model. And so understanding where in the life cycle of this project, that asset data, the information data, what, the end use is.

Again, going back to the beginning, you got to look at the end goal to start the project off right. So identifying what information do they need, who along this timeline of project, when does that data become live, available. If it's an air handler in a room, we know what room it's going to be in. It's easy to identify in design model. We don't know what the zero number is until it shows up on site.

So identifying what information, when it becomes available, and where does that data go? Does it need to be in a model? I don't think it does. Natively, it can. But which is the proper model? Is it our model, which has all the clearances, and hangers, and everything else that's just going to bog it down, and it's going to be painful for them to use? Is it more of a stripped down version? Is that the design models? Or is it just the data turned over, and it's linked in a system?

So understanding that end use I think is what makes this process work. And we're seeing some success on projects. It's just if the conversation isn't had at the beginning, then you're all starting off down your path. And by the time it gets to us, it's like, well, now we're too far down, and all right, buckle up. We got to get this done.

SHANE BURGER: I 100% agree. I think the best conversations we've had on that has been really strong engagement with our contractors and with the clients. We have an airport terminal we have off and on been working on, where it's a temporary location. It's only going to exist for 20 years. So the conversation to come back to what I said about carbon again has been about carbon circularity, and the idea of buildings as material banks.

So the concept of discussing with our contractors what do we model, how do we tag the information so the client can start looking at potential reuse capabilities of all that information, so the model is being a repository for very particular use around that. So I think there's amazing opportunities for all of us to be talking with our contractors and clients about what are your actual goals. For some of our retail clients, they're tracking particular like materials, or mechanical units, or systems that they want to know, because they may have 500 locations around the globe. And they want to know, all right, this is a repeated unit that continues to fail, or this material breaks down, or this bracket breaks down, so they're going to want to treat it like a repeatable product. But in other cases, you may have very different aspirations, but that's a great conversation.