Data Sharing: When, Where, Why, and How?

JEREMIAH OWENS: All right. Welcome. Welcome to our session on data sharing, when, where, why, and how. It's session number CS3022. Hopefully you are all on the right place here.

This class is a general overview on data sharing, highlight some areas and some issues we've overcome along our journey, our transformation journey. It doesn't require any knowledge of all Autodesk products or any other software. And we really hope you take something away from this class. We hope that it inspires you maybe to implement some data sharing processes within your firm or maybe revise some of your current processes and way of thinking.

And also, we want to make sure that you guys feel free to step out of this session at any time, especially if it's not for you. We understand your time is valuable, so please feel free to do that.

All right. So my name's Jeremiah Owens. I work at Burns and McDonnell as a technology and innovation consultant. I've been with Burns and McDonnell three years. I've been in the AEC industry for 24, almost 25 years.

I spent 10 of those in civil structural disciplines, specific design site, special inspection-- you name it, I probably did it. Especially, I came from a smaller firm, so at smaller firms, you know you wear multiple hats. Even got my South Carolina residential contractor's license during that time. And currently, again, serve as technology and innovation consultant. My co-speaker Chris, I'm going to let him introduce himself.

CHRISTOPHER O'NEAL: Yeah. Thanks, Jeremiah. My name's Christopher O'Neal. I am also a technology and innovation consultant at Burns and McDonnell. I have 10 years experience in the AEC industry, all of that which has been with Burns and McDonnell.

I started off in the structural discipline as a detailer and drafter and then worked my way up to being a designer. And then more recently, I made the switch over to the electrical discipline. So I have several different areas of experience within disciplines and also with the industries, so I've worked on anything from manufacturing facilities, tank farms, pipeline facilities, and now EV charging stations-- so a wide range of experience. And I work with Jeremiah in the project delivery group.

JEREMIAH OWENS: All right. Great. Thanks, Chris. In our role as technology and innovation consultants, we provide strategic guidance and technology assessments to align with Burns and Mac's visions. We focus on data governance, resiliency, and risk analysis. We also look at emerging technologies and optimizing processes to keep our firm competitive throughout the industry.

All right. So today's session, 45 minutes plus or minus. At the end, we'll have Q&A. The agenda-- introduction, we're going to talk about key questions that need addressing, impact of data sharing on the design and construction industries, current challenges in data sharing, and then the conclusion.

And the image on the left side of the slide is kind of cool. That's a aerial photo looking down at our lawn at our world headquarters located in Kansas City. It shows our logo, which is an ampersand.

All right. So, introduction. And throughout this session, we're going to ask for some audience participation, some jumping jacks, cartwheels, things like that. Nothing big.

All right, so show of hands. Who feels right now at this time confident in their ability to share data throughout a project's life cycle?

CHRISTOPHER O'NEAL: Awesome. Thank you. Now, who here feels confident in their team's ability to effectively share data throughout a project life cycle? So you may be confident in your own ability, but who's confident in their team's ability?

And then finally, who acknowledges the necessity for enhancement within data sharing? Who sees the need there?

JEREMIAH OWENS: All right. And again, if you're watching this at home or online, feel free to raise your hand. We may not be able to see you, but we know you're there.

So if you're confident in your ability right now, that's fantastic. If not, that's OK, too. We've all been there, and hopefully we'll be able to help you navigate some challenges along the way.

All right. So starting out, we want to talk a little bit about data. What is data? All right. I think Chris is going to start us out with a quote.

CHRISTOPHER O'NEAL: Yeah, a great quote here. "Data is like garbage. You'd better know what you're going to do with it before you collect it." Very important. Mark Twain.

JEREMIAH OWENS: All right. I like that quote. What is data? So we've listed out-- provided four bullet points.

What is data? Raw facts and figures. So what comes to my mind is 500 bricks, 100 steel beams, 300 bags of cement, right? Just raw data.

Types of data that we deal with in the AEC industry include numerical, textual, and visual. And I think throughout my career, I've spent a lot of time-- well, really a lot of time in each of these and even additional ones. It's not listed, but primarily focused on drawings, construction documentation, and now over the last 10, 15 years, models.

And the purpose of data is to help us make informed decisions, improve processes, enhance collaboration and ensure accuracy in design and construction. And like I said, now in the AEC industry, data is integral in the BIM process and methodology.

So data is everywhere. It surrounds us in our daily lives. We use it, we process it, and we generate it throughout our day.

CHRISTOPHER O'NEAL: So what good is what you have if you don't understand how to share it? So we're going to dive into sharing.

So one of the little phrases you probably heard growing up as a kid-- maybe if you have kids, you've said this to them-- sharing is caring. One of the first lessons we learn as kids is to share our toys, share our things, work together, play together. And I think that same thing, it really rings true in the data sphere of things and the professional workforce. So I wanted to break down sharing in terms of four key questions, the first one being when, and then where, why, and how.

So going more deeper into these in reference to sharing, when we share, we show care and consideration for the success of others. So we really show that we want to have that team mentality, bring others in, make sure we're not siloing ourselves. So it really fosters a good environment.

Where we share, that can really have major impacts on us and our career growth, other people's career growths, our project's success. It can impact efficiencies, the collaboration, how we communicate with each other, risks-- security risk, project risk-- and also innovation, how we innovate bringing more people to the table. Are we just siloing ourselves? And we're making the decisions, or are we letting other peoples do that as well?

And then why we share. So the main reason why is to openly and efficiently build trust and relationships. Briefly touched on that a little bit, but we want to foster a collaborative environment, really invite people in and, you know, newer employees, people that are newer to the industry, really encourage them to take ownership of some of these things.

And then how we share, that can allow others to join in the fun, so to speak, so allow them to be part of the team. Maybe they have different perspectives. It's always good to get different opinions on things. It allows others to understand and make informed decisions so you're not just making all the decisions yourself. Other people have opinions, like I was saying, and they can really bring stuff to the table as well.

And then driving group success. So ultimately throughout this whole thing, I think we're going to really hone in on making sure we're driving the success of our team and not just individual success.

JEREMIAH OWENS: Yeah, those are great points. All right. Data plus sharing equals data sharing. So what is data sharing?

There's a definition on the screen, but for me, when I think of data sharing, I think of the accurate exchange of information from one stakeholder to another. That's what pops in my mind. And again, some of the common types of data that we see or deal with in the industry that we wanted to highlight-- design data, engineering data, construction data, operational data.

And the graphic on the left illustrates data sharing throughout a project's life cycle. And it really, I think, illustrates a very simplistic life cycle of the data sharing process.

CHRISTOPHER O'NEAL: So now we're actually going to get into some of the key questions that I'm sure all of you are here to find out. So we've defined data, we've defined sharing, and then tied those together, data sharing. So some of these key questions we're going to dive into is when, where, why, and how in terms of data sharing.

JEREMIAH OWENS: Thanks, Chris. First one, I want to talk a little bit about when. When should we share data? And I think throughout my career, it's been at milestones. It's been understood that we're going to share data with someone at a milestone, right?

And kind of reading through the slide that you see on the screen is bringing all stakeholders together early in the process to devise a data sharing strategy for the project, document the agreed upon process, and put it in the project execution plan or the BIM execution plan.

In my experience, it's really critical to bring all key stakeholders together at the beginning-- project managers, discipline leads, engineers of record, designers of record-- and talk about-- even client representatives, right, if you have that opportunity. Subs, constructors, whomever that may be or what that looks like for you and your circumstances.

But now with the emerging technology, technology has come a long way, so we're able to share more often with the same amount of effort or less effort. So time is money. So daily, weekly exchanges, that's a time-- again, milestones. We've listed some milestones up there, some common milestones that you'll see on projects.

And then project closeout, I wanted to touch on that a little bit in detail because I feel like it's overlooked a lot of times, especially in the pre project planning. I believe that teams do not allow enough time for quality reviews and audits at the project closeout phase.

So really, we're not technically done until we exchange that information. And we want to really exchange accurate information-- the exchange of accurate information. So I want to speak on and make sure we drive home the importance of putting model quality audit gates in your schedule and allowing for that time for you guys to review your data.

So project team utilizes Construction Cloud, or ACC. They can ensure that all stakeholders have access to the latest project information. Again, the handout's going to have some more information, so please refer to the handout.

So determining the optimal timing and methods for data sharing is crucial for project success. And sharing too soon and too late both can have negative consequences.

And without getting too deep into those, I just want to share with you that in my career, a lot of times, I have a task to complete on a Thursday, and maybe I don't-- I have to complete mine on Thursday, and then maybe on a Friday I receive data. So I've received that data too late, so it's impacted my deliverable. So then I have to revise and resubmit my work-- potentially a change order, right?

So you want to make sure that you're sharing on time, on schedule. Everybody agrees upon that schedule, and everyone understands how critical it is to share data accurately and on time.

Some practices to help mitigate some of these issues or help control and coordinate some of these is daily standups-- short daily meetings that discuss progress and share critical updates-- weekly reports-- comprehensive weekly report to summarize the week's activities-- and ad hoc sharing. I would caution that, although I know we deal with that day in and day out, hour by hour. As someone says, hey, I need that, and you're quick to react and say, OK, here you go. Just make sure you are checking that data and that is accurate.

CHRISTOPHER O'NEAL: Those are all fantastic points. Let's ask for some more participation here. Who's currently sharing data weekly? How many of you had actually have had that talk with your project team? And who is currently sharing data at project milestones? And then this last one. It's OK if that is you, but hopefully that's why you're here and to gain more knowledge. But who is currently not sharing data throughout your project? Fantastic.

So now we're going to get into the where and how. Jeremiah went through the when. So this is more specific to your Burns and McDonnell and how we do things and what's worked for us.

We utilize Autodesk Construction Cloud as our main common data environment. You'll hear that term a lot. Our single source of truth, you'll also hear that term. So it's our common data platform we store all our project data in. It really helps with collaboration. There's secure access. You can really limit the access and share data pretty seamlessly throughout the project life cycle.

So some key points in here we wanted to highlight was collaborate in real time. So again, ACC, as the example, really helps us with seamless collaboration across our disciplines and project teams. So we can give everyone access to the latest and greatest models as needed or whatever is determined based on what Jeremiah was talking about with when we're sharing, what we agreed upon in the pre project planning stages.

We can also share other stuff outside of models and drawings, other critical project information like if it's procurement information, equipment, information, calcs, specs-- things like that can all be stored there.

The second one there, maintain version control-- so this is another one we're probably going to harp on a couple times, but it's definitely very beneficial with ACC. I know specifically having the version control built into it-- so any files that you store and use within the ACC environment, every time it's saved and overwrites the previous version of that file, it creates a new version of that. So it'll track every single time a file is saved.

If you need to do compare, that's a very powerful tool when trying to see what exactly changed between one save to the next. You can also make the other file current. If the current file that's most up-to-date is actually corrupt, you can go back to where you need to, to where it wasn't corrupt to fix the solution.

So there's a lot of user friendly features there that weren't necessarily accessible on previous file storage platforms. That was very limited to certain people in IT, depending on how your organization's structured. So it definitely doesn't take as much time to get those versions of those drawings back. So it's definitely a good point there.

Provide secure access. So with everybody going to more cloud based, I know there's security risks, or some clients may not be so gung ho to actually do it because they're worried about the security risk. That's where ACC does have where you can make sure that whoever's in your project, they only have access to certain folders.

So you can really limit that access if a client wants access but you don't want them to see your working files because it could just cause issues, you don't want them getting in there-- or if you're working with an outside contractor and it's a legal thing to where they can only have access to certain files. So you can really lock that down based on the individual member, or you can do it by permissioning of roles or company they're assigned to.

So there's different ways to do that. I know we use that quite a bit at Burns and Mac on our daily projects.

And then the next one, enhanced project efficiency. So obviously, if everybody's working in the same environment, that eliminates a lot of the going back and forth between different places, trying to find files, not having to worry about people sending you file locations all the time. Everybody should have an agreed upon location of where all files are stored and the folder structure is organized in a way that it's easy for your project members to read and find files.

And then finally, have listed there integrate with Revit and other tools. So ACC specifically works really well with integrating with BIM tools like Revit. So Revit I think is like the bread and butter for ACC and what it was built for in a way. Revit does have its standard collaborative environment, and it fosters that. Well, then ACC added another aspect to it with the web, so it works really well with that. Really allows teams to collaborate effectively.

And also, if you have team members that aren't comfortable in some of these platforms like Revit, they can get into the ACC website of things and actually use the web viewer. They can utilize issues and see what's going on in the model without having to worry about messing anything up and causing issues for other people.

So the final thing here, we don't have it listed but I think is very important-- and again, I think something that's going to be touched upon later-- is training and support. You want to make sure that before you go all into an environment like ACC, that you have in mind and documented training people that can support these teams that are going into these environments because while they're very beneficial, it can also lead to a lot of issues with change management.

If you don't have people who are so gung ho about going into some of these and they don't fully understand the benefits of it, if they just go in there and they're not used to getting in different environments every day, they could be going in and not accessing something correctly. Or with desktop connector, they don't have it saved locally, and so they're getting frustrated. And then the whole effort is just gone because someone who's high up decided they didn't like how it worked because they had a bad experience. So that is definitely key there as well. I wanted to touch on.

And then finally, our project team utilizing ACC, that can really ensure that all stakeholders have access to the latest and greatest project information like we've outlined using some of the key points above.

JEREMIAH OWENS: Awesome. Thanks, Chris. That was a great, great slide.

So Chris and I, when we sat down to pull this presentation together, we kind of had a plan of action based on our current needs within our groups, and we ended up with a lot of data, as you could imagine. So we narrowed it down to three sections that we feel are key to us and were challenges to us, so we wanted to speak on those and share with you guys.

And those are prevalence of local work and email communication, limitations of cloud tools without full participation, reliance on others data in the design world. And Chris is going to get us started on the first one here.

CHRISTOPHER O'NEAL: All three fantastic points, if I don't say so myself. And getting started with the first one, the local work, people working on their local machines and primarily relying on email for communication. Email communication is fine as a tool to utilize. But with these common data environments allowing these other features, you can really take advantage of some of those to tie email into that. So it just enhances some of these older features that we maybe have been using for a while.

So really wanted to harp on this one. Technology's always advancing. Things are always changing. And I know I've worked with people who will save local files because it may be faster to work locally or whatever excuse they have to work locally instead of working off the same common data environment. So could lead to issues. Could have issues with version control, as we talked about. Within ACC, that's only as good as how you're using it. So if somebody is saving everything locally and then reuploading it, that could cause issues with some of that stuff.

So we tried to think about the best practices to eliminate as much as possible some of this and try to encourage the teams utilizing some of these other features we've been talking about. And so some of those are adopting a cloud-based collaboration platform or a common data environment.

So again, we utilize ACC primarily at Burns and McDonnell to house all our project information. It really, again, helps with collaboration, ensures all project teams are working off the same location, so there's not really a need for anybody to go and copy things down locally and then make their edits and reupload it. It all should work just fine from there from the cloud. So as long as they have a good internet connection, it should work fine.

The next thing, implement version control system. So touched on this a little bit earlier with ACC's version history, but other tools too, like Revit, it's a work sharing tool. Anytime the model gets synchronized back up to the central, you can go back and look at all those changes, all those times it's been synchronized, and download the new copy, make it current. So definitely take advantage of this version history and encourage people with it.

So maybe that's something you can point out to people as they're getting into these common data environments to encourage them like, hey, if something goes wrong, we can always update it. Or if you're saving locally, it's going to mess up the version history, which we need to keep for tracking purposes. So there's a lot of data there that we can really utilize and take advantage of. So we just need to make sure we're on top of it.

Standardized communication protocols. So in the preplanning stages, make sure you're getting the key stakeholders involved, and have everyone agreeing on what forms of human communication you're going to be using. There's a lot of different forms of communication. You have your BIM execution plan. Jeremiah will touch on that a little bit later. But documenting all your processes and everything so if they do forget, they can go back to it later.

Email's fine, but I think the big thing is utilizing tools like Issues or Correspondence in ACC. Not every single thing may need an email being sent. You may just be able to go into the model through the web viewer in ACC, submit an issue, and then assign it to a certain person and select certain watchers on that so then they'll get alerted to go look at it. So you can communicate those ways as well.

And then also correspondence, you can make sure all your emails are also copied over to your common data environment so it keeps track of that throughout the project life cycle. Instead of having to dig through your emails and search for something, you can keep it all within ACC and it only has emails relevant to that project.

And then finally, the last one there, direct communication to file location. So this is a big one. What we mean there is instead of actually responding to an email for a request for updates to be made, say you had a request for a drawing to be updated and they sent you a PDF. Instead of sending a new PDF back to them, send them the location of the PDF as a link to the email.

So in the email, they would just click on the link and it would take them to, if it's your ACC folder, where that PDF is located, that way they're not forced to copy it down locally. Makes it a little more difficult for them to work local and copy down local. They have to be a little more intentional about it. So that could help with some of that as well.

And then finally, we have a bit of an example down there. An architect might send updated blueprints via email, but if the recipients don't check their email, there's a lot of things that could go wrong. Maybe it just gets lost in a slew of emails. They don't check it promptly, that might result in rework happening, outdated plans being worked on, which ultimately could lead to delays and cost overruns.

JEREMIAH OWENS: That was a great section, Chris. And again, if your analytical application or another application requires you to work locally, just make sure you have the processes in place to ensure those files get updated in your common data environment if applicable.

And really, don't isolate your data. Don't put your data on an island where nobody can get to it. Your data's just going to sit there. It's going to get a sunburn. Well, I mean, I'm sure a lot of us would like to be on that island right now, but please don't isolate your data.

All right. Moving into the next one, limitations of cloud tools without full participation. And so cloud-based collaboration tools have the potential to streamline data sharing, but their effectiveness is limited if not all members are using them consistently.

So again, some ways to mitigate and help with that is pre project planning, identifying those risks, those trouble spots early on so that you can get the training procedures, the onboarding procedures in place-- again, agreeing on and identifying a common data environment, and create BIM execution plans. So you want to create that.

So again, the illustration in the background, or the image in the background kind of paints a picture of someone out there on their own, maybe a team member or a team themselves, a discipline, whomever it may be, kind of working out there on their own. And they're not really plugged in to the common data environment or to the team. So you really want to give your teams the confidence they need to utilize these tools.

A lot of times in my experience, I've found that maybe someone isn't going to the ACC or using the Issues tool or whatever because they don't have confidence in it. So no one's sat down and explained to them how to use it. In our busy lives, it's hard to find the time to train sometimes, so I just encourage you to implement that training-- kind of going back to what Chris said earlier, implementing a training strategy.

And project management tools like ACC, they can centralize all project data. But if only half the teams update the information regularly, the tools benefits are diminished. So you really want to ensure, again, the accurate exchange of data between one stakeholder and the next. You don't want to have people out there on their own.

All right. So moving into the third one, the reliance on other's data in the design world. So we're all relying on others data to do our work, to perform our tasks, and vice versa. Someone's probably relying on us and our data to execute their task.

So again, the definition of data sharing for me, the accurate exchange of data or information from one stakeholder to another. And so again, whether it's a architect waiting on a structural engineer, a structural engineer waiting on an architect, mechanical waiting on structural, or electrical waiting on mechanical-- whatever the case may be, someone is waiting on someone else.

So some best practices to help mitigate or navigate these scenarios is make sure everyone understands the data context. Make sure they understand the whole picture, not just the part.

Collaborate with data providers. So open up the dialogues, establish a communication line with whomever is providing data. If you're the one providing data, then you take the initiative.

And check for data updates. Don't assume that the data available to you is the latest and greatest. Reach out to them. A design team working on a building might rely, again, heavily on structural engineers. If the data is outdated or incorrect, it can lead to design flaws that are costly later on.

And again, going back-- and Chris will touch on this later on-- but really going back to the isolating your data on your C drive. So if you're doing that workflow, if you're conducting that workflow out of the necessity to gain time, gain efficiency-- it's quicker-- I would caution you. I would caution you on that because it may seem quicker.

However, kind of taking a few steps back and looking at it a higher level or elevation, so to speak, you'll see that that time spent ensuring that data is accurately exchanged during the design phase is a lot cheaper than in the construction phase and then post construction.

So even if you're out of hours on a project-- I know the PMs in the room, I apologize-- but if you're out of hours you want to spend, you want to buy those hours, so to speak, I call it investing. You want to invest that time to ensure your data's accurate prior to handing it off.

CHRISTOPHER O'NEAL: Yeah. Speaking of investing, we wanted to see about asking you some more questions. So who here feels assured that they consistently receive or have access to the most current data? All right. Now, who here is currently facing one or more of these challenges? Thank you.

JEREMIAH OWENS: Yeah. Thanks for your honesty there. All right.

So we kind of added in a quote-- I wanted to talk on or reiterate on some things-- so making sure you have accurate data and quality reviews and audits in place. And sometimes when I'm conducting a review of a model and I'm navigating through it, all of a sudden I see something. Kind of catches my eye. I kind of zoom in on it.

And from afar, it looks correct. But upon further investigation, I find that maybe it's a in-place family, or maybe it's a mass, or maybe it's a imported CAD block, or sometimes all of the above altogether.

So I find myself, unfortunately, asking the question or talking to the wall on where the heck did that come from? How did it end up in our model? And then just, oh, boy, right?

And so then I start asking, OK, who owns this data? Where did it come from? Which processes broke down? Why is it in here? And of course, the answer I always get is, it wasn't me. All right, so a quote from Shaggy.

CHRISTOPHER O'NEAL: All right. Now, going into the impact of data sharing and in design and construction, and see how those compare.

So we have a few figures up here. Some of them can be pretty eye popping and eye opening, but just to check out some industry trends where the AEC industry is based on some information that was pulled.

So the top one there, 95.5% of all data goes unused in engineering construction. That one right there was pretty astonishing when I first saw that. I knew there was a lot of data just with everything evolving the way it is, but it really shows how the AEC industry as a whole has not really caught up with such a data centric world we live in.

Data is always at our fingertips. So keeping that in mind on how we utilize that, that just speaks to there's a lot of garbage out there, so to speak, as Mark Twain would say, because we have all this data but we don't know how to use it. So it just goes unused and just sits there.

That next one there, 50% of owners said they've used or planned to use design-build, moving away from design-bid-build. So that movement there really shows the importance of quality, making sure our data is accurate. And now that we're cutting out the bid in design-build process, that really ensures that the quality of our data needs to be there.

And then down below, the 81% of owners and operators want to drive better decisions from building data. So that to me speaks to going to digital twins and where the industry is going with that, how they can use some of this data in operations and help save some time and not have to worry about going back to some drawings to figure something out on how something was built.

So that's super important, and it kind of ties back to that first one. We have so much data that goes unused, and we have owners, clients that are wanting to utilize some of that data for their operations. So if we can really hone in on that, all that will do is just help all of us increase in revenue and the bottom line for all of us.

So speaking of revenue, the last one there, companies that utilize big data analytics report an 8% increase in revenue. So that's a pretty significant increase, and that's ultimately the bottom line for how a lot of us assess our success as a company and as a project. So if we have that much data unused, all that will do-- if we figure out how to use that garbage and turn it into gold, so to speak, that will ultimately increase all of our revenue exponentially.

JEREMIAH OWENS: Yeah, that is a really good graphic. So moving into role of good data sharing practices and mitigating mistakes. So consistent and accurate data sharing ensures that all team members have the most up-to-date information, reducing the likelihood of errors during the design and construction phase.

Some things or some, I guess, items that help with that-- best practices, if you will-- establish a single source of truth, role-based access and permissions, and implementing continuous quality checks. Again, that's one of my pet peeves, making sure you have basically the time needed-- I'd say a day before, depending on the project-- the time you need to review your data, make sure it's accurate prior to sending it out or exchanging it downstream to someone else.

So regular, updated, shared documents and models can help identify discrepancies early, allowing for timely corrections before escalating into bigger problems. And again, time spent during the design phase is going to be cheaper than time spent correcting it during construction. And I believe the next slide will cover that. I think Chris is going to talk a little bit about that.

CHRISTOPHER O'NEAL: Yeah. So going into, again, the bottom line for a lot of us, what's the cost implications of these mistakes and design versus construction? How is it affected at the different stages of a project?

So mistakes made in the design phase, they're usually a lot less costly than construction design phase. You have a lot less moving parts, a lot less people waiting on an answer. You can work together at the same time while still maintaining your schedule and meeting deadlines.

If you're waiting until the construction phase, they catch something out there, they're sending an RFI to the engineer. Engineer has to review it, ask some questions, have some conversations, maybe do some calcs, and then send the response back to the construction team on site. So you could have a lot of people waiting around, whether it's to pour concrete or what, to get a response.

So there's definitely a big emphasis on that, and we have some multipliers there. The American Society of Civil Engineers estimates, just like I was saying, the cost of making changes increases exponentially as the project progresses. So during the design phase, it's estimated to be 1x cost of change. And then during construction, it jumps all the way to 10x. So that's pretty measurable just by amount of hours and materials, things like that.

And then the eye-popping one I would say is the 100x or more after a project's complete. So after you complete construction, once it's in operations or before operations, it's going to be 100x to make that same change.

So something to keep in mind. It puts a bigger emphasis on making sure your preplanning is set up correctly. You have your meetings with your key stakeholders, you make sure everything's ironed out, and you do things and utilize your clever data environment like ACC and do things like model coordination. Make sure you're doing clash detection. Checking to see-- anything you can make or catch early on in the design phase is going to save you a lot later on.

So a design error caught during the planning stage might only require a few hours of work to fix, whereas that same error discovered during construction, that could lead to days or weeks of rework, significantly increasing the cost. And ultimately, it could lead to a timeline adjustment of construction, which could cost even more money to the actual client. So big emphasis there.

JEREMIAH OWENS: Yep. That's great. 100x is hard to see. 10x is hard to see, right? But the 100x to me, I was like, whoa, whoa, wait a minute. But it makes sense. If you've completed something, you're basically, essentially, a lot of times starting from scratch, new calculations, new drawings, et cetera.

All right. Quick show of hands. Who in the room as encountered issues or losses on a project that could have been prevented by implementing a good data sharing process? Hopefully-- thank you for your honesty. Everyone of us has probably been impacted by these types of events. Hopefully, we can mitigate those moving forward.

And Chris is going to share briefly about one that was really bad, and we called it a failure in data sharing. And again, it kind of took place before our careers, before we started. And to our knowledge, Burns and Mac was not associated with this project.

CHRISTOPHER O'NEAL: Yeah. So a prime example of where we saw some of the breakdown in some of the data sharing aspects is the Hyatt Walkway Collapse. I'm sure a lot of you watching online and here are aware of this example. I'm sure you've learned about it in school or somewhere else. It's definitely at the forefront as a what not to do example.

But for those of you that aren't aware or need a refresher, I'm not going to go super deep on the details. They have a lot of case studies online about it, so I encourage you to do your own research. But we also will have more information in the handout with this class as well.

So the Hyatt Regency Hotel was opened on July 1, 1980, as a new construction, new build hotel. In just a little over a year later, the fourth floor walkway, as well as the second floor walkways, collapsed. And at the time, they had an event going on, so there was a lot of people in the atrium where those walkways were and on top of those walkways. So unfortunately resulted in the death of 114 people and injured approximately 200 more.

So ultimately, again, not going to go super deep in the weeds, but the failure was determined to be the connection at the walkway box beam. So in the bottom right hand corner, it's a good illustration of the details of how it was originally designed on the left hand side with the single rod supporting both walkways. And on the right hand side, there was two separate rods supporting each walkway. So ultimately, there was a miscommunication between engineering and the fabricator actually doing the construction on site.

So back then, the main means of communication were phones. So trying to look at it from our perspective, having the technology we have access to now, how could we solve some of these issues or make it to where it's more difficult to get around these and make engineers unaware of this?

So I start with a common data environment. So we've been harping on that a lot, but if everybody was working off the same location, even the fabricator, you can give them access to your common data environment. And then same thing with their shop drawings. That communication can be done with whether it's issues on ACC bringing it to your attention. If you're emailing through the communications of the major changes, you could also attach those in correspondence so there's a record of that later on.

There wasn't really a record of this-- like I said, just the phone calls. So it was hard to determine exactly who was miscommunicating what.

And then also intentionality. Like, going back with those teams and determining, OK, I'm responsible for this. You're responsible for this. There wasn't really that communication there, and it seemed like both sides were expecting the other to either design it completely, or the fabricator was sending it back to the engineering company with the changes on their shop drawings and not really alerting them to it, so it really affected the load.

So obviously, this is a worst case scenario, but it really shows the impact poor data sharing can have on everyday lives. And I think it puts an emphasis on us every day. We share data and need to make sure we're intentional about that.

JEREMIAH OWENS: All right. So we're going to move into the conclusion and then end with a Q&A. So I think Chris has another quote for us, so let's see what this one is.

CHRISTOPHER O'NEAL: "We cannot solve our problems with the same thinking we used when we created them." Albert Einstein.

JEREMIAH OWENS: All right. Yeah, I like that quote. I like it a lot. All right.

So key takeaways. Again, we kind of compiled these. Hopefully you guys have been taking notes. You've got your own key takeaways from today's session.

I just wanted to highlight a few things. I think one of my personal, I don't know mission, so to speak, is to make sure our teams have the skills, the tools in place so that they can be successful.

So the fourth bullet point down, it says sharing data promotes trust, enhances collaboration, and enables better decision making throughout the project life cycle. So really want to bring our teams up together and make sure everybody's successful, current team and future team, right? Plan for all of that. And really, adopting a common data environment, it will assist in overcoming common challenges, some of the ones we listed in this PowerPoint.

Again, before moving in or adopting a common data environment, I believe it's essential to sit down and devise and work out a change management strategy because really, a lot of firms, in my experience, you really have to approach it that way. So create your change management strategy, make sure that you have your training in place, make sure you have all your documentation in place, and then go out and adopt a common data environment.

And so next, Chris is going to speak on just a few call to action topics.

CHRISTOPHER O'NEAL: Yeah. So we kind of wanted to wrap this up and end it with a call to action, what to do next-- what we recommend are the best ways to continue your learning experience and actually take steps to be a better data sharer.