Road Map to Successful Implementation with Autodesk Construction Cloud

BRIAN POPIS: Hello, and welcome to our presentation Roadmap to Successful Implementation of the Autodesk Construction Cloud. Of course we're going to start off with some introductions. My name is Brian Popis, I'm a senior business transformation engineer at Barton Malow. I have about five years of experience in construction software deployment, especially in the Autodesk Construction Cloud. I like to think that I'm committed and passionate about the advancement of technology in our industry. And as well as hoping to be a thought leader for standard and best practices in all of our construction markets.

NICK BOBBITT: My name is Nick Bobbitt. I'm a business transformation manager with Barton Malow. I began my journey in the AEC space back in 2009 with a focus on reality capture technology. Specifically laser scanning. That evolved into other reality capture technology, and I've spent the last half of my career working through devoting construction workflows and processes.

MICHAEL BUGBEE: All right, my name is Michael Bugbee, or Bugs, as you can call me. I am a customer success manager here at Autodesk. I have a little over 10 years of experience in construction and construction technologies with degrees in both kind of bachelor's and master's for it. Really I love kind of helping the industry improve on all stages of construction and a lot of the background has been in implementing and training our construction customers on how to adopt and be successful in utilizing new software, new tools, new workflows as well. So pass it back to you, Brian.

BRIAN POPIS: All right, a little bit about Barton Malow. So you have an understanding of the company. We're approaching 100 years in just a couple of years, in 2024. We currently have over 3,000 employees in 16 offices throughout the Eastern half of the US. On 2022 we're ranked 30th on the ENR top 400. We operate in a number of different delivery methods in a wide range of markets, such as sports, entertainment, health care, k-12, higher education, commercial energy, automotive, and industrial.

We also sell perform civil, concrete, interiors, structural steel refractory, rigging and boilermaker services. A major driver for Barton Malow is innovation. We believe the construction industry is ready for major disruption, and we've been strategic in aligning Baron Malow to be ready to transform for the next 100 years in the construction industry.

MICHAEL BUGBEE: As with all Autodesk processes and presentations, we will throw up our nice safe harbor statement. So there we go. We did it. On to you, Brian.

BRIAN POPIS: All right, so we'd like to start by providing some learning objectives for our course here. And we have four main learning objectives. So to walk through these individually. First, we want to show you how to identify critical bottlenecks for the adoption of your Autodesk products across your organization. We want to talk about how do we get there, what are each of the bottlenecks that we saw, so on and so forth.

So our second learning objective is comparing workflows of yesterday to today, and identify efficiencies in a common data environment on fast paced projects. Really this is a function of why did we choose to go with the Autodesk Construction Cloud. Our third learning objective is to learn from our experience and development of in-house training solutions and redefine successful training implementation. Additionally in our last and final learning objective is to envision the future of data using the Autodesk Construction Cloud, and what we expect to accomplish with the unified data environment using ACC.

So just to kind of kick things off and provide some perspective, in the past at Barton Malow when I first started at our company, we really had many different points solutions to accomplish many different objectives. And really what this leads to is the fact that we didn't have a single source of truth. And without that single source of truth we run the risk of having incorrect information on various platforms, a lack of transparency, and difficulty organizing all of our team members with the latest and greatest information.

So we're really tired of having our construction projects be managed on 5 to 10 different platforms, and with the lack of efficiency that comes with it. And therefore we made the decision to go forward with a unified platform to host the majority of our processes. And throughout this search for a unified platform, it was paramount that our teams have a program that is easy to use and understand.

NICK BOBBITT: As Brian mentioned, Barton Malow wanted to get away from multiple point solutions, and focus on simplifying workflows across all of our projects. Getting all of our data into a common data environment would allow us to have better, more consistent data than we've had in the past, and use that to make informed decisions about our business in the future. There are many options, but we were already users of BuildingConnected, trade tab pipe, assemble, the AEC collection of desktop products, and more. It just made sense that ACC would be the choice that we made.

BRIAN POPIS: So in starting off and talking a bit more about these components of successful deployment from a Barton Malow perspective, there's really like four main questions that we would recommend that you ask yourself. And I want to go through these and talk in a bit more detail. So first and foremost is, what resources are available for your success, right?

So in the past we had had a small team that was responsible for the deployment of certain project management and document management softwares. But in order for us to deploy unified solution, we really needed to dive into the question of, what are all of our resources? Not just what's sitting right in front of us. What can we leverage in order to be most successful? Right? And that's a good question to ask yourself is, how am I going to leverage the things that I have in order to do the best that I can?

So Additionally is when we're talking about onboarding and training is, what opportunities do we have that are different from the past, right? So if you're looking at the past, you may have trained for a software in person, or how big instructor led trainings in your main corporate office, or whatever it may be. Right? Whatever your process was.

Going back and thinking a bit about what opportunities do you have in order to change what you've done in the past in order to be more effective in the deployment of a software that's going to affect potentially all of your projects, like it has for us at Barton Malow. The next step I would say is really to think not just internally, but also externally. How do we align all of our team members around this new program being in namely the Autodesk Construction Cloud? How do we get people rallied around this idea of we're going to be changing our processes for the better. We're going to be working in one place, and we want to bring them along for the ride, right?

So how do we focus on including those people who aren't just those who are sitting on from a Barton Malow perspective on our projects, but also our design partners, our clients themselves, our subcontractors. Anybody who can be involved in the project. And then after you're thinking about all these components of a successful deployment, really, you have to think how do I monitor and manage the deployment successfully. So data, measurement, verification of your adoption. This is all really important stuff in order for you to be an organization that deploys a product successfully across all of your projects.

So really what it comes down to is we feel that there is four main opportunities and associated solutions that we decided to go with. So I'm going to go through these individually. So as I mentioned, first and foremost is we have-- there's lots of resources that can be used in order to effectively move through the deployment stages of a product, right? So and one of the best resources that we determine we could tap into was our Autodesk customer success team.

So we've worked on developing a really strong relationship with Mike Bugbee, our customer success manager, and the team that he works with in order to be most effective and leverage all those resources that we have. So that's number one.

Number two is we wanted to make sure that we onboarded and trained our teams effectively at the fastest pace possible. Because when we're talking about scaling a new unified software across a multibillion dollar company, we need to do that quickly, otherwise it could take a lot of time. So we focused on the deployment of a focused on demand training platform for ACC, throughout our whole organization internally and externally, which we'll talk a bit more about in a bit.

Additionally is, we wanted to focus on all of our project stakeholders, both internal and external. And promote that awareness and show them how we're going-- we see the future of working on our project management, management platforms to be, but bring them along for the ride. So the solution is really having these collaborative workshops with our clients, our design partners, our trade partners, whomever, right? Making sure that they have a say in and understanding and they're able to provide their input on what is the best way for us to work together.

And then when it comes to monitoring, managing, and validating our success and the adoption of ACC, we have worked really hard to start developing a data library for use in the verification of our success with the program. So using data to extract key insights that allow us to see how we're utilizing the program most effectively, and what we can do to be more successful in the future.

NICK BOBBITT: So this was not just a simple implementation change. We went from a number of softwares into a unified platform. We had multiple conversations with leadership so they understood the value that accommodate environment would have on our organization. With this being a major technology change and shift, we needed to use a top down approach to communicate the message clearly and often.

In 2012 Barton Malow launched a long term goal to coincide with our 100th anniversary in 2024. This goal was broken into three four year base camps, each with strategic goals. ACC implementation is part of our final base camp goals of the last four years. In addition to incorporating this into our company's strategic goals, our president and COO have communicated this change and it's important throughout all family huddles, in Barton Malow TV episodes, which are both live and recorded video updates on the status of the entire enterprise.

And just when you thought that message wasn't conveyed enough, and clearly enough, it's communicated again as a part of our brand promise, which is aimed at providing a consistent experience for all of our clients. Knowing that we needed to focus on how the landscape of the construction industry will change, not in the next six months, or a year, but over the next 5, 10, 15, and even 30 years, a specific group was formed to focus on keeping our pulse on technology and other drivers of change in the industry, called the business transformation team, which Bryan and I are both a part of. We don't focus on specific day to day projects, and the team is focused entirely on the future of the family of companies and the enterprise. Setting up a strategy for deployment of ACC was an initiative of this team as we knew it was a foundation for our project data for years to come.

MICHAEL BUGBEE: All right, so with anything of building a relationship kind of takes time and commitment, so we want to make sure that we had commitment from the Autodesk side, but also from the Barton Malow business transformation team. So part of that was once again having meaningful and strategic relationships and. First with anything is going to be getting in front of, getting face to face, having regular office visits. So we would try to have as many office visits where we would get together and have discussions around workshopping, workflows. What's new, what's next. The different things to be focusing on the implementation of the ACC team as well.

We also had biweekly sinks with kind of the larger team. So we would have very direct interactions with Brian or Nick or different members of the team. But kind of come back and take a step back and say, hey, this is what we're working on. This is what we've been doing. And being able to kind of have different points of views of like, hey, we're tracking towards the same goals. Right?

And one of my favorite parts, and I think a definitely huge thing, is we visited projects. Because you can have all the technology in the world. But you have to have buy in from the project teams. And some of those project visits were just taking a job site tour. Which you can see in this photo here, we were just sitting there. They're pouring concrete on one of the levels, and we're just sitting with the superintendents, just kind of talking to them. And they love talking about their projects. They love asking questions. They loved me asking questions of their different things that even I would learn from it, right?

Other ones were kind of going back into the job trailer, and kind of sitting and having some troubleshooting time. With, hey, they're frustrated with, hey, why is it doing it this? Or how can we make this better, right? Because that's a great thing to be able to do is have those conversations, and either kind of take that feedback, which you'll kind of see in a little bit later, or be able to kind of answer and kind of brainstorm some solutions on the fly, right?

So getting that face to face time with project teams and listening to kind of their overall positive feedback has been a great way to kind of alleviate and solve some of the kind of rollout to it. As Brian alluded to. Rolling out to a multibillion dollar company there's tons of projects going on at a time, but being able to focus in on some of those projects that are closer to some of their offices has been a great blessing for us.

BRIAN POPIS: And just to provide a little bit of commentary on that as well, as like working both from the internal Bugs, you being at the external perspective being working for Autodesk, and then internally on our end I can tell you for a fact that having dedicated project visits with your customer success team, with Michael and with our team, it really, it makes all the difference. It shows the commitment to our project teams and the commitment to use the new software that really helps us debug problems that trying to solve through a video call or through a phone call just sometimes can't reach. It really provides a connection that has been truly valuable to our project teams.

MICHAEL BUGBEE: And with this one, we know as soon as we release software, we know it's perfect, right? There's no issues, it works great. Barton Malow was able to roll it out without any problems. Well, we know that doesn't necessarily always happen because as with construction there's a lot of different intricacies around an automotive project versus a k-12 project versus a doing some civil work, right? There's different things that you have to go through and talk about.

So what we ended up doing was we created a very good engagement model to get feedback into from Barton Malow back into the project. And into the product. So we held different types of workshops, so we would kind of come through and look at design reviews, daily reports, submittals, and sit there and write it out from like, all right, this is how Barton Malow was currently doing in their current ways. And here's how it would work with the same people in the Autodesk Construction Cloud. So being able to have that has been a great value for them as well.

And also is really having a good engaged relationship, is being able to have research visits with the different product teams. So those are just once again just getting face time with the product developers, the product UI designers, the managers themselves, and being able to kind of get and see the day to day life of the end users, of seeing how they use the tools, to see, well, hey, can we improve some of these clicks, or some of the mobile experience, right?

So being able to do the job shadowing and the interviews allow the product to be able to kind of see firsthand how the technology could help, but also how technology can kind of hurt, and make things more complicated for them. And I think the business transformation team has been great with their beta involvement. So they've realized once again it's kind of a partnership, right? It's hey, we say, hey, you want to be a part of this beta for something. And they have been great at having standards and self expectations of those teams, of being involved in the betas, on like, hey, you're not just going to be in it.

Do one meeting. Give some feedback. Like you are going to constantly give feedback. There are expectations for it. And that's been really great for the product teams themselves. So once again, they just kind of keep asking, hey, does Barton Malow potentially use this. Like can we grab Barton Malow for it, right? So it's been a really great thing to kind of see and flourish over the years.

BRIAN POPIS: Yeah and just commenting on that, again, is that we as a company, really see these betas as an opportunity to develop a greater understanding of the product roadmap, and to get it really to get ahead of the curve. So a lot of times there's we on the business transformation team have heard a lot of things from the past where our project team would reach out to us and say, hey, I really wish that I could do this. Is there a way for me to do this? And being in tune with the betas that are opening up and that are available really gives us a lot of opportunity in order to plug people in and to understand where the product roadmap is headed.

And it gives people an opportunity to experience it firsthand, and to have discussions with the product development team, provide their own personal feedback. Again, it comes back to that idea of connectedness and partnership, and we're really fostering that through our beta testing programs.

Additionally when we're talking about research visits, just again it comes down to the idea of that one on one, or that team to team interaction in person. It just really helps to have a project team interface directly with the product development team, and understand a bit more about what their struggles are on site. And how things could be better in the future. Right?

MICHAEL BUGBEE: And continuing on the product influence, the I want to say feature request, right? A lot of times I'm sure most people think feature request is like a four letter word. So while we at Autodesk have been working towards improve that process, Malow has been working on an improvement of getting those feature requests to Autodesk. So a lot of times kind of what we used to do in the past was just open up an Excel spreadsheet and just complain and just list out a whole bunch of things.

And then we would take that and then we would dump it into our system, and you would just get countless request of pretty much kind of the same thing, but might be a little bit different. So one thing that the business transformation team has been paramount in is creating a better Barton Malow submission process. So what that's going to do is that's really finding out the value of, hey, why this is needed. The why behind the request.

So by the time it kind of goes through a Barton Malow reviewed feature request, it then is passed over to me at Autodesk, so then I'm able to submit those requests, and provide updates as it kind of works through our system. And you can kind of see here, we're able to get some clarity on, hey, this has been qualified. So it's in products hands. Or it's been deferred. Or it's plan to do, right?

And even more importantly sometimes things are just been deferred, or like, hey, we're not going to do it. So sometimes hearing no is better than hearing no answer at all, because we can figure out a workflow, or find out of like, hey, this isn't going to happen. So how can we work around this, right?

So the main part of this is just, once again, like gone are the days are just spreadsheet imports and feature requests, right? Each one is thought out, it is vetted, and then pass into our system. Right? And then during our biweekly calls we're able to kind of go through and review the status of each one of these as it's kind of moving along, adding more context, or even some of these you just need some need some more information. Even though we thought, hey, they fully understand. Like I fully understand what they're requesting. The product team might need a little bit more information about it. So we can kind of work that as a team and get that information back to product.

BRIAN POPIS: So and in tandem on that is that really as we've adopted and it's really with any new software that we've adopted, one of the most critical points is that our project teams want to be able to provide that feedback, and to be able to hear responses to what their future requests are. And one of the great things about this process is that we have a controlled system where we submit feature requests throughout the entire company, then they get consolidated, and then they get passed through to Bugs, who then submits them internally. But we receive a clear response that's a yes/no, and then if it is yes sometimes maybe it's deferred down the line. But still it's the idea that the project teams, the people, the customer is being heard and that really holds a lot of weight with our project teams.

And the last one, as with anything, is responsibility and accountability. So typically when we first started this relationship, we were using OneNote. Like everybody else out there. To kind of manage and track our items, manage and track what was going on. But the problem became very apparent quickly was, I had my notes, Brian had his notes, we'd email them back and forth, and I'd add his notes to my OneNote, and I'd be highlighting or creating a task in my side. And I'd say, hey, I'm done with that. And then I'd forget to tell Brian that I did this. And then once again it doesn't come up till the next meeting. Once again you can see some problems with that, right.

So Barton Malow uses Monday.com for a multitude of different things. But we started utilizing it in our biweekly customer success meetings. And it's really nice because once again, it's creating that kind of single source of, here's the action items. They're able to be worked through from the Barton Malow side without visibility that I can see. But when the Barton Malow is ready for me to do something, especially around like feature request, they'll get assigned to me. So then that's my kind of nudge of like, hey, you need to go submit these feature requests into it.

And as with anything anyone can come in and check the visibility of the status of anything, kind of what we're working on. So it's really nice of, it's made our weekly biweekly customer success meetings much more streamlined. They're better communication. And just overall have been great. And you can kind of see from the icon below, there are certain things that Autodesk needs to do, but the same thing, Barton Malow is working that relationship just like we are.

BRIAN POPIS: Yeah, and in the biweekly CSM meeting, the way that we see that as a company as just being like the heartbeat of our relationship with Autodesk. And it it's just a platform for us to exchange ideas, to discuss and remove obstacles that are incoming. And we see it as an opportunity for us to share information with Autodesk and for Autodesk to share that information with us, and it really keeps us on a good rhythm of moving forward in a partnership.

NICK BOBBITT: So moving on from the customer relationship into the training side of things, once there was a decision to be made to move to ACC we had to have a strategy to get our employees trained. We knew we needed to have a well thought out plan, because we needed to get 1,500 plus project team members and another 1,500 plus subcontractors, owners, design partners, up to speed, and up to speed fast. We want to make sure that they were able to access content after the initial training, because nobody is going to remember everything they learned about this entire software in one sitting. It does too much, it's not a half hour you know everything scenario.

So we needed to make sure that the training was also very consistent so that everyone received the same content, and projects would be executing processes the same way. We didn't want project A, submit an RFI as one way, and project B doing it another. So we want to make sure things were going the same way.

And lastly we knew we needed to leverage technology to accomplish this. The 3 to 5 people we had in the past going from job site to job site and office to office to deliver trainings and then back to those same offices and back to the job sites with new when new people come on wasn't going to work. We were never going to get that many people up to speed and using the software appropriately. So why was addressing all this important?

Because with the focus on data and better data, we needed our teams up to speed fast, and using the program consistently in order to get that data clean and be able to use that to get insights on making meaningful decisions in the future. Which is the goal of the common data environment.

BRIAN POPIS: So just want to take some time to dive in a little bit further specifically on what is our training strategy, right? So one of the things that Nick had just mentioned is that this is an on demand training program. So the idea that we want to be able to scale quickly by giving people access to look at the training whenever and wherever they are, right?

So but on top of that as well is these trainings are persona based. So depending on what your role is on the project, you are presented with information in a certain way. So for example, if you are going to be a project administrator, you really need to have a good, solid understanding of everything there is to know, not only about the administration of the project, but the processes of the entire program itself. So that's a very, a very widespread training. Whereas if you're a subcontractor participating in our project, you may only need to see certain functions in certain processes. And so the information is catered to what your role is on the project.

Another thing is that we have to separations between internal and external team members. So we have two separate domains where anybody who's internal to Barton Malow is able to log in through single sign on, and is able to go through the training content, whether they're a project team member or they're a project administrator, and then as well as any of our external team members, whether that's our clients, design partners, subcontractors. So on and so forth.

One of the things that we've really put a lot of effort into, and you can see this through the data, is having really short consumable videos that are subcomponents of larger processes. And the reason why we do this is because if you look at the data for a video that's say over 5 minutes long, the viewership tends to drop off. So what we want to do is give people-- this really has the short, consumable videos have two major benefits. One is that people can come and go as they please, and they can see-- they can choose to go through the information when they're ready, and we have better commitment to finishing the process.

And then additionally by breaking it out into subcomponents, we can feed back into that persona based model, where we're only showing people certain components of a process as needed. So for example, if we're working with an architect on our design team, that they will only see, let's say, we're talking about our submittal process. They only need to see how do I review a submittal, and not necessarily how do I create a submittal, or submit a submittal, because they're the ones who are going to be reviewing at the end of the day. So it's catered to what they need.

Additionally through our training program what we like to do is use iterative feedback. Or we like to make iterative development through feedback that is provided on our platform. So at the end of each training there's a required survey, and in order to receive the certificate for that training, you have to complete that survey. And then what we do is we go back and we harvest information from those surveys to identify, hey, maybe we missed something here.

Maybe there's something that we could be doing better. Maybe there's a way we can shorten something down to make it more concise so that people understand it better. So there's really just this cycle of developing the training, implementing the training, and then in just going through this whole process of getting it out there and then receiving feedback so that we can make a better improvements in the future.

BRIAN POPIS: So as this is just an example of one of the, I guess the landing pages for one of our trainings. This is our Autodesk build project administration training. So really just a couple of key points here is that, first and foremost, you can see how our content is split into sections. And these sections really-- are set up by module.

So you see that we have a module for files, for sheets, for issues, for forums, RFI, so on and so forth. So really this is broken out into consumable components, that if somebody needs to see a certain part of the RFI process again, they can go directly there, find the two to three minute video that they need, and they can review that content.

Additionally one of the keys to our success was to harvest training content that was already produced by Autodesk through HTML files. So online ACC.com, you can see all of the information of videos that have been created by the Autodesk team that are related training, but by harvesting those videos, we are able to confirm that our information is the latest and greatest that has been produced. And also it gets updated when needed. And we're also just saving time by leveraging content that's already available.

So going through a bit of the development process, how do we develop these trainings. So first and foremost is that to ensure success we like to put together cross-functional teams that have different assignments in the development and verification process. So really it's split out into, say, there's a user or multiple users that are organizing the interface that are producing or selecting videos as needed, curating the content, so on and so forth.

And then there's another set of users that are providing internal validation, that the basic structure is met for the training, and that it meets the needs of project team. Just an internal validation to make sure that things are able to go to what we would next go through a focus group. But really, again, like I said, we're leveraging all this training content, that really helps us get off the ground quickly and running as fast as we can.

But what we'll do is, like before we bring all of our videos and content to market, we'll do two major things. One is we'll customize the information so that it really shows the Barton Malow way of doing things. So if we have a general set of videos that explain this mental process, if there's any context that's needed to talk specifically about how Barton Malow does things, we will provide that with the video in the form of either text or a downloadable document, whatever it is. And so that when somebody is going through their training they're getting a bit more context on how we expect the program to be used.

And then once we have this all put together, we have focus groups of project team users that are selected, and they're generally incentivized to provide review of the training content and gaps in learning. And this is extremely important, because at the end of the day, project teams are going to be the ones using the training and using the software. So they have to be the ones that validate the training program, and say yes, this really does meet our requirements. Because they're the end user, and we want to make sure that this first and foremost, this is providing value to them, both internal and external users.

So in just a plug for everybody who watches this. You can check us out on the digital builder podcast with Eric Thomas, coming up in the near future. Nick and I both did a video that dives much deeper into our philosophy surrounding a successful training startup for using any cloud platform, or any software program. But this is really the experience that we had with developing our training program for-- our on demand training program for the Autodesk Construction Cloud. So please if you're interested, it should be a great lesson, and you'll get to dive a bit more than what we're just saying in this presentation.

So we've touched on this a little bit in the past. We're talking about influencing the product and in product teams feeling heard when they're providing feedback and feature requests. But it's really, to reiterate, one of the major roadblocks to successful deployment of a software is the feeling of not being heard by your project teams. They want to be able to provide feedback, and to feel that they're being listened to, and that the product development teams and the creator of the software understands the problem effectively so that they can come up with a solution in the long term, right?

So one of the things that just going a bit deeper on that feature request process is, we set it up so that in turn we said all users can provide feedback and receive those responses within 4 to 6 weeks from the subject matter experts at Autodesk. And then that information can then be transferred back to our project team so that they know what the answer is, and is it deferred, is it qualified. What status is it in?

One of the things that Bugs and I have done, and we will continue to do in the future, is we would like to host bimonthly webinars that are in coordination with the release notes that come out, or the releases that come out every two months for the Autodesk Construction Cloud. So generally speaking after those two month cycles of releases come out, Bugs and I will hold a webinar, and we'll show the company how things are changing, and what the new features are. And then we'll also relate directly to feature requests that have been processed. So we can show how that feedback is being incorporated into the bimonthly product development roadmap updates.

NICK BOBBITT: So traditional construction methods keep many workflows siloed. We want to continue to integrate with our owners, our design teams, our subcontractors, all our partners on our projects. And we knew we needed a partner with some key clients to help develop and improve workflows of the past. In addition to working with select clients, we also decided to team up with strategic design partners.

So typically workflows have been determined by project teams on the project level. So they are consistently being tweaked to change to meet the specific needs of those teams and projects. But we wanted to go above the project level, and work together to achieve some optimal workflows that would work across all projects. And after getting the key stakeholders together, we could discuss the needs of all parties, not just Barton Malow's, not just the design teams, not just the owners, but everyone collectively and take that information back to Autodesk so that they could continue to inform the direction of the product.

MICHAEL BUGBEE: I'd like we kind of mention as being involved, so kind of being involved is great, but once again, it has to be kind of meaningful and kind of raising the bar. Some involvements just checking in once a month saying, hey, how are things going? They're good. All right, cool, talk to you next month. Or taking them to lunch when you're in person, right?

So how we've been trying to kind of raise the bar is getting the product development research trips to visit job sites, if possible, or even just kind of getting on the phone with them and just kind of doing the interviews that way. So it doesn't matter if it's admin related, using Desktop Connector, handover, take off, model coordination anything that Barton Malow uses or would like to use or is testing out, we're getting them back in front of the product so the team can hear from the customers how things are going.

Even running IWP. So IWP is their installation work packages for their self perform groups. So that's what this image is here. And we're kind of going through and looking at basically what they've created as a kind of one sheet experience of all information around what they need to do, is either on that page or hyperlinked from that page. So no matter what they're doing, when they're on the mobile device they're on that one page, and they can get and see everything. So once again, just making sure that all the work that they've done is still utilized and still being able to be worked within the ACC platform.

And even kind of even taking it a step further, and building that partnership of saying like, hey, we need to solve kind of, or help work towards a larger industry problem. So like the handover process. Everyone I'm sure has horror stories of the handover process, from semi truck trailers full of paper documents, to spending hours and hours putting everything into a thumb drive. You know, so what we've been able to do and what we're working towards is just kind of taking a small subset of, all right, let's look at the handover process with automotive clients.

So that's once again working with the automotive kind of owners. That's working with Barton Malow and that's working with Autodesk on being able to document how they currently do it, utilizing technology. Where the manual processes have to go, and how can we improve those processes. Right? Is that just a small workflow change that we can utilize, or is it a step further of utilizing maybe Forge or Power BI, or maybe kind of working with the client on saying like, hey, why do you need it this way. I can give it to you this way much easier, and all the information is there. It might just look a little bit different. So being able to have those open and honest conversations with floor, right? So trying to work towards a less painful handover process.

NICK BOBBITT: So once we get this platform up and running, we get people trained, we need to validate the usage. And where people are at. So where are we now? We're currently heavily down the road of the descriptive phase of our analytics journey with ACC. And what I mean by that is, we are connecting daily directly to our data, and that way we have up to date metrics on what's happening within the platform.

And then we use that to update project level dashboards that show things like average time to close an RFI, or a number of outstanding issues by company. And so on and so forth. Endless number of ways we can use that information. In addition to project level metrics, we're also looking across the enterprise to look at adoption of the tools and training. We want to know who's trained on our projects, both internally and externally, as well as what modules are being used the most within the platform.

Not every project is using everything the same way. So we want to know, where are things going well, and conversely where are teams skipping out. Why aren't they using these things? Is it because there's lack in training, or is it because they don't see the use, they don't know how to use it. What is the driver for that?

And as we continue to gather more data, we can start to use these metrics in a predictive fashion, which is where we want to get to. We can determine if a specific subcontractor, for instance, consistently gets their submittals in on time. They have a lot of positive safety observations. Or a design team that is reviewing submittals faster than anybody else, and we can actually use that information when we're working to get a project team together, to make decisions down the road. And that really sets the stage for the power of being able to look at this data and actually gain some insightful information out of it.

BRIAN POPIS: So just want to take a little bit of time to talk a bit more about where we're headed, right? So there's sort of where we're at now with our data, and we and we've come pretty far. But where are we going? And just a couple of these things are first and foremost is that we could see that through the collection, and verification of data related to our projects, we may be able to automate the project startup process. So that's something that we're working heavily on internally is when a project goes through our CRM system, and then we know that it's a go and we're going to be working on this project, kicking everything off in order to be successful from a software standpoint, and from internally all the people who are involved with the project. So on and so forth.

One of the things that we want to do as well is, we want to produce an extensive library of information that doesn't include just our information from ACC, but also our CRM system, our ERP system, and more. So looking holistically at all of the data that we have, and how does that tie to what we have within the Autodesk Construction Cloud, and using this to make more intelligent decisions in the future, which leads kind of into the next step, which is AI and machine learning.