Description
Key Learnings
- Evaluate whether Autodesk Build can enhance the design-to-digital-twin journey.
- Explore the interoperability between design and construction with Autodesk Build.
- Compare the feature differences between Autodesk Build and Procure.
- Discover the workflow differences between Procore and Autodesk Build.
Speaker
- WMWill MarinosI have been working in the AEC industry for 20+ years. I have a diverse design background and have spent most of my career managing various CAD and BIM software, and Document Management Systems. Currently, I am the Director of Design Technologies at Hazen and Sawyer. The Design Technology (DT) team is responsible for System Administration, Software and License Management, Training, Support, R&D, and Innovation related to all CAD/BIM and GIS products.
WILL MARINOS: All right. Thank you for taking the time to join me on our venture around ACC Build. We did a quick pilot. We're doing a quick pilot test of ACC Build. We're trying to determine if we should use that in place of our current CM platform. So take everyone for a quick ride on that journey and what we've learned and where we landed with all of that.
So my name is Will Marinos. I'm the Director of Design Technologies here at Hazen and Sawyer. Myself and the rest of the team-- we manage all of the Autodesk, ESRI, and related products that we utilize here at the firm-- so construction support training, innovation, R&D, all of it. Won't spend too much time on that. I'm sure everyone's familiar with the general role.
As I mentioned, I work at a Hazen and Sawyer. Hazen has been around for 70-plus years since 1951. Actually it's a little bit of an outdated graphic. We're now at about 1,700 people and 60-plus offices, and we focus on all things water. All examples displayed at the bottom of the screen. I won't speak too much to it because there are a lot smarter folks at the company than me. I'm just happy to support them in doing the good work that they do.
So why did we choose to even pilot Build? I'll get into that first as we go through this journey. One reason-- we already made the transition to ACC for all of our design projects. That was done well over a year ago, and currently we've got 650 or so ACC projects and well over 2,000 users total between internal and external staff. I actually did a session on that topic on why we chose ACC for design last year at AU. I'm sure you folks can find it online if you'd like to.
Also we use Assemble and Tandem, both of which conveniently connect directly to ACC. So again, a little bit more of the ecosystem already built in. We've also developed a workflow that helps us identify and maintain a client's assets from the point of our initial design through construction ideally, and then into facility management, particularly Tandem. So what we'd like to know is will Build provide a more connected workflow?
Our current CM software is disconnected from this Autodesk ecosystem at the moment and ultimately, the big question we'll get to towards the end of this is, will Build provide a more connected workflow for us as we go down this path of trying to maintain our clients' assets through the entire life cycle of the project?
A little bit about the project we chose for this. Wasn't the largest project, but that was intentional. This is located in North Carolina. Construction schedule is about 18 months or so. We'll see. Constructions seem to never stay on schedule, but we'll see how this one goes. It's targeted for July of next year to end.
This one again wasn't the largest of projects. We replaced two mechanical bar screens and ventilation fans, some flow equalization pumps, and upsized some other equipment to improve capacity. So not that that's critical to this pilot, but just give everyone a little background on what the project consisted of.
So I'm going to jump right into goals and takeaways here. I combined this section rather than have to jump around too much. What we're hoping to get out of this pilot-- and again, it is still ongoing. As I said, construction is not going to end until next year. But even to date we've taken enough away from this that it was worth presenting-- we felt it was worth presenting on.
So ultimately, the five takeaways we wanted from this pilot-- compare Build to our current software and platform. Does Build meet the needs of our existing software? How easy is it to use compared to our existing software?
And not just that-- what learning curve does it have? What do we need to do to train our staff, both internal office and external field staff and internal Hazen staff and external contractor and sub-staff to learn Build, assuming that no one's ever used it before? What does Build do better or worse? And then again, come back to that-- does it provide a more connected workflow? It's a bit of a theme through this.
So the first item, comparing Build to our current CM software. Everything that our current CM software has, Build does provide for us. There was truly nothing that we couldn't do with Build that we-- couldn't do with Build that we can do with the others. So we're happy to see that everything we were expecting and needed is in Build. And I didn't mention this at the divider slide, but there's some quotes on these slides this is feedback from our pilot team. So if I don't read them out exactly, that is what's on the slides.
So one of the highlights we noticed while working through this pilot and evaluating Build was the Assets feature and how that feature specifically does draw that connection to assets in our design to managing those assets during construction. And also, again, noted by our pilot team was that it could be very useful for equipment startup and O&M logging and tracking.
Item number two was ease of use compared to our current software. I'm going to get to the bright red screenshot there in a minute. But our pilot team felt the interface is well-designed-- the format, the aesthetic, and it was nice, easy and pleasure to use. Efficient communications between design and construction teams is another benefit to Build. The connectivity between the design files, the ability to create issues on RFIs and get those comments and markups right back to the design team when needed was a very efficient workflow.
One negative in all of this is not specific to Build. It's kind of generally an ACC issue. It's the administration side. That is the side that I generally sit on and all of this. Permissions management within Build can be challenging. That screenshot in so much red is my Excel permissions matrix that was developed for Build so we could track what role and group was getting what permissions and within which module. So that is actually going to be a blank version of that I'll include in the handout content for this session as well for anyone else who may find that useful.
So along the permissions lines again, can be a little difficult to manage and daunting if you're new to it. Also the fact that creating a template is going to be a little difficult because certain projects on the construction side are going to have different subs and different groups and may result in different permissions. So we're trying to figure out as we go through this pilot what the best kind of median template would look like for Build projects.
So takeaway number three was learning curve and training agenda-- essentially requirements. During this pilot I actually went on-site to do the training-- found out that was probably the best way to do this. So Build-- if you're familiar with ACC for Design, build has a much larger footprint in ACC Design does. That was honestly a shock to me when I started digging into Build-- at least how much larger it was.
So you have to cover so much, and the blue screenshot here if you will, or image, is page one of the training agenda that I had put together for Build. And this page one is all web interface, not mobile. So again, I'll put the whole training agenda for anyone interested in the handouts for this course as well and just download them and develop from there if you'd like.
So since Build has a bigger footprint-- and not just because I was on site, but having been on site, I do recommend that all Build training is done on site. It is going to be a lot to cover in a day, assuming you've got one day to do it. You do have to cover web and mobile, and the easiest way to do that is to get everyone into a room. And since construction management-- a little harder to do remote than design and some other things, most of the time all staff's in one location anyway.
So easier to get them all in the room, cover everything, answer questions. You can make lunch an actual working training trip and have everyone grab their phones or tablets and go through some of the mobile features at lunch, and photos and that type of thing. Keep people engaged without having to sit in a conference room staring at a screen.
And the other thing, and this goes back kind of to the permissions-- but training shouldn't be taken lightly, even for system administrators. As I said, the system is big. It can be complicated. There is a lot to know, a lot to set up, a lot to configure, and then even more to support once you get it there and people start asking questions. So make sure that administrators know the system backwards and forwards even before the users start getting training. That's my advice. It's been a fun thing to walk through.
OK. So this one seems to be one everyone was interested in as I was going through internally about this presentation-- is what does Build do better or worse than our current software? And I don't mean to take shots at one or the other. This is just factually what we found throughout this pilot, and essentially as of today.
So currently there is no dedicated specifications module within Build. So the fact that it doesn't have that-- we can still manage our specs within the files and through submittals and things like that, but there is no dedicated specifications module. Didn't hurt our pilot in any way. Just something that we noticed, so we wanted to put it in here. Knowing Autodesk, they're already working on something. But again, I'm going to be honest with our reviews of all this. So it's currently missing.
Another simple thing-- not the end of the world, but again, we noticed when we were viewing sheets or just opening up a model with sheets or drawing with sheets in it, the text clarity-- both text clarity I should say and line weight clarity at full zoom of the PDF linewidth-- it appears that the line weights were applied too heavily at that zoom level.
Goes away immediately once you start zooming in on that PDF. So again, it was not a showstopper for us in any way. And most of the time you're zooming in to look at something or at a markup anyway. But minor thing, but it was there, so we're calling it out.
On the positive side again, there's some feedback from our pilot team here as well. So submittals, issues, RFIs-- the referencing features within Build to connect one item to another-- and I didn't list them all there, but those were the three that I think they used the most. And they point out how useful that was to track processes and manage things. I didn't mention this, where forms and photos and everything else-- how it all references together nicely to create a complete package as we're going through the construction process on this project.
And what I think came as a surprise to the folks on our side here was the geolocation of photos. Not so much that photos geolocated. That one seemed-- we kind of expected that. But the accuracy at which they showed up on a map within the Google Map and the fact that as the image on screen shows, the red location icon-- you can actually see where that photo was taken in the Google Street View within the Build app in the Photos feature.
So that actually was not something I expected to be a notable feature as we were looking into this. But as construction started and pictures started being taken and we had multiple people on site trying to figure out where this picture was, having not been to the site before, they found this to be one of the best ways to locate that portion of the site.
And then just more of an ACC feature, but obviously Build being part of that now, the ability to view the Revit models as well as the PDF sheets. And again, goes back to that initial connectivity piece I mentioned on an earlier slide where being able to open up the Revit model and put an issue in there directly if something comes up in the field and needs to be changed in the design, and then connect that issue to RFIs. And just, again, the whole interconnectivity piece was a big benefit to all of this process as well.
All right. So that question that seemed to be a bit of a reoccurrence through this presentation is, does Build provide a more connected project lifecycle for us? The answer is absolutely yes, it does. Build's going to be a critical piece of our digital delivery for facility management. As I mentioned, our asset management team can now work with our design team on getting the assets into our design files, take that asset information right into Build.
That Import from Model feature becomes very critical piece to that workflow so we can get our assets into Build even before construction begins, and then our CM team can manage and maintain those assets and that asset information while the construction is happening and make any changes that need to be made. And then link any photo start-up forms, handover whatever it is right to that piece in Build.
And then ultimately we can take all that information, put the model and all the qualifying asset information into Tandem, and that becomes your facility management. And from there, us for the client or the client themselves can then further add other information to that model in Tandem, whether that's connecting to actual O&M manuals or safety documentation, whatever it is. And they have a fully-functioning digital facility management tool.
And that connectivity is the true benefit Build in my opinion, personally at least. And I think that's what we've taken away from our testing initially besides the connectivity from our construction and design teams just for change management.
So what's next for us with Build? Our current CM software is not going anywhere, first of all. I should start there. We're very invested in it. There's hundreds of active projects that are still ongoing. And on one small pilot, we're not going to just throw something like that in the garbage. We're also not always able to choose what software we get. And that's not just us. We're at the behest of certain contractors and clients and what they prefer to use. So that's I'm sure going to come up again and again, that we will be using that in those regards.
And most of our linear projects that we do-- they don't have the same requirements that our vertical projects do, and we're not necessarily to the point where we can take linear projects into Tandem. It's just not built for that yet. So we've got a little different workflow for those start to finish, so we're more focused on our [COUGH] excuse me, on our vertical projects in the asset workflow I was mentioning right now.
So our CM software that we're currently using is not going anywhere. We are going to run a second pilot for Build-- a lot larger pilot starting next year. It's going to be a new build, a new construction, and we're going to run that through Build. And that project was all done in ACC, and we've got the assets piece and we're going to use that to refine that second pilot, to refine our workflows and our training. We find the best way to refine those things is actually while doing it.
So we're going to run that second pilot in 2024. We may do a third one. I don't know. We've got to talk about that internally, but we're definitely doing a second one. We've more or less picked the project at this point. But we do intend on using Build when it suits the project needs, more or less. So it'll depend on whether we can choose the software that we use for CM purposes, and it'll determine what the client is looking for at the end of all this and the schedule of the project.
If the staff has already been trained, maybe we don't need to do extensive training. If they haven't and we have to do extensive training, does the schedule allow for that level of training? Because everyone's already current and comfortable with our current software. So we're going to look at the variables for each project, but if we can make Build work, we will use it if that's what suits the project best.
So that's our plans. Everyone may see me back here talking about this again next year. Who knows? We'll see how everything goes. The initial question on my title slide, should we choose Build as our primary? Essentially replace-- the question ultimately is asking if we're going to replace our primary. Can't make that call completely.
What we're going to ultimately do is look at each project on its own merits and what the requirements are and what our clients are looking for. We will choose the best one for each project as they come, and we'll go from there. I can't tell you that over time there won't be a shift one way or the other. But for now, that is the approach we're going to take.
So if there are any questions for any of you watching, please just send me an email. I will get back and answer as soon as I can. And I do appreciate you taking the time, and thank you.
Downloads
Tags
Product | |
Industries | |
Topics |