Barton Malow's Guide to Automated Project Creation in Autodesk Construction Cloud

STEFFANIE SCHRADER: Hello. My name is Steffanie Schrader. I'm a business transformation manager with Barton Malow, and this is my presentation on our guide to automated project creation in Autodesk Construction Cloud. And this is a detective's story.

We have here our standard safe harbor statement. Feel free to pause this recording and check that out, if you would like. Otherwise, we're going to move on. And I present to you the case.

So it was January of 2020, and my team had gone through an exhaustive search to find the right replacement for Prolog. That's when we ended up on Autodesk BIM 360. We were really excited to roll it out to the company. It had so many features that were going to make our project delivery personnel's life easier. And so we made the announcement, and we rolled it out.

And that's when we started getting mysterious emails like this. So I received an email from Chuck here. And all he says is, can you start up a new project for me in BIM? Thanks. End of story-- but not for me. So, first off, he misspelled my name. But that's typical because my name is not spelled the same as everybody else, and I pick my battles.

The second one is I have one clue he wants a new project. The third one-- he said BIM, which I'm sure everybody who sets up new projects has encountered this before. I knew what he was talking about, fortunately.

So those of you who set up been BIM 360 projects are probably aware, I needed some key pieces of information here. I needed the project name, the project type, and then, of course, the language. The language was a freebie. But the other two-- I didn't get any of that information in Chuck's email.

So that meant I was going to have to interview him-- the subject, in this case-- for more information, which, of course, meant setting off a flurry of emails because I'm not going to make a phone call, right? It's important to mention here that we were not just gathering information to start up new projects for our project teams.

When we rolled out Skilljar, obviously, it was right before something major worldwide happened, and we needed a way to get the same training out consistently to our project teams and the subcontractors, architects, engineers, client reps that would be using the BIM 360 project. So we decided to employ a company called Skilljar which is a learning management system.

We prerecorded a ton of Autodesk BIM 360 trainings and put them into curated programs based on who you were. So not to mention having to set the project up, we had to have a way to communicate back to our project teams that they needed to complete the Skilljar training and where they could find it.

Also, a big thing at the time was when we first rolled this out-- we were charging our projects individually for the cost of the BIM 360 licenses. So I had to get a lot more information than just the project name and the project type. Now, I was going to need more numbers from them. I needed their project number, and I needed a network and activity so that we could actually charge that project for the licenses they were going to be consuming.

So off on the emails we went. And, as you can imagine, there were a lot of emails back and forth. And that's when it dawned on me that this was not sustainable. Emails just aren't great for things like this.

There were too many emails. There was a lot of confusion in this communication. And then, of course, both of those things together are always going to equal wasted time.

So it was time for a break in this case. We needed to find a new approach for this, and I was on it. So anybody who knows me knows that I am an absolute fiend for automation. If I can automate it, I'm going to.

It's right there in my LinkedIn profile. I'm a Power Platform enthusiast. And if you can't trust the LinkedIn profile, what can you trust? So I turned to my old friend and my new partner, the Power Platform for Microsoft and my favorite assistants, Microsoft Forms and Microsoft Power Automate.

So what I came up with was a form that the project teams needed to fill out. It made sense. Why wait for them to voluntarily give us the information that we needed, when we could just ask them for everything? So here's an example of what a project team or a precon manager needed to fill out if they wanted to request a BIM 360 project.

I was pretty staunch in making our project teams do this instead of accepting things by email. When I would get an email like the one that Chuck sent me earlier, I would say, hey, can you fill out this form for me? So as you can see, I've made several of the fields required here.

But that's a lot of typing for our project teams, right? But that was their problem, actually, and I was getting what I wanted, which was all the information that I needed. So this is where the Power Platform came into to play, really.

So once a form was submitted, good old Power Automate was waiting in the background, and it picked up that form right away and all the information in it. So for those of us setting up these projects, I flowed that information into a Trello card.

And we had a whole Trello board set up with the different phases of setting up a project, including whether the person had completed their Skilljar training so that knew what they were doing when they got into BIM 360 and if we had talked to the project team, if we had set it up, if everything had been accepted. So that's what Trello did for us. And then, of course, I flowed all that information to Excel because we had to have a record of the status of the jobs and, of course, all those numbers that we needed so that we could charge those projects.

So there was another part for this. If you'll remember, I told you that we had to send them an invoice for what they were using. So, again, as soon as that form got submitted, a different Power Automate flow picked up the same information, and then I used a product called Plumsail, which was a third party service that you can buy that goes with Power Automate, and that generated a PDF invoice that we could send to the project teams.

And, of course, we weren't going to send them to the project teams manually. So as soon as Plumsail generated that PDF invoice for us, Power Automate and set up a sharing link and then stored that PDF inside of a SharePoint library.

Then I had an approval go out where I gave the project teams all the information that they could need about Skilljar training, and here's your invoice. They had to approve it before we would start up a project because we had to have them understand that it was going to cost them money to use BIM 360, at the time.

So once they approved it, then a set of emails went out to not only my team, but also the project teams. And that had that Skilljar information in it that they could use to link to the training in Skilljar and send out to their subcontractors, AEs, owner reps, various people.

So things were working really great on this one. But as time went on, we discovered there's more things that a project team is going to want to have when they're starting up a new project, other than BIM 360. So, of course, as a Microsoft [? job, ?] we have Teams. And so we added these different softwares to the startup form that I showed you earlier.

If a project team wanted a Microsoft Teams setup, they could check a box for that. They could check a box to say they still wanted to use a Box folder because it was pretty hard when we first rolled out BIM 360 to get people to use the file storage. It took a lot of change management on the BDC team's part. And so we still had a lot of people requesting Box folders.

Also, we had BuildingConnected that we use here. We have Flypaper for our daily reports, and we use SpecLink. So depending on which product the project team wanted, different things would happen using, again, Power Automate to notify the right people.

We had a couple of APIs running for Box and for Flypaper dailies that would go out and actually start up the Box project based on a template and would start up the dailies project based on location and the person's email address. So we were hitting all of these things at one time, now, and it was working out great-- no more emails like Chuck would send. If you did send it, like I said, I sent him to the form.

But as good as this was, as much of an improvement as it was over how we started, it was still an imperfect solution. So we still had to follow up with project teams. Sometimes they wouldn't have a network or an activity to give us when they first started a job because they might still be in preconstruction.

So it certainly didn't eliminate all the emails, and there was a lot of manual entry in the form for the project teams. And we did get a lot of complaints about that because with the form, at the time, you could not go back and return to it to fill out more information. They would have to make sure that they had everything they needed to know right when they did it the first time. So we did get complaints about that.

The other thing is projects have way too many aliases. What appears in our SAP list for a project name is not necessarily what they called it in preconstruction or what the project teams actually call it. A lot of things have code names. They have nicknames. So we were having some confusion over what project it actually was, still, because it was a free-form field.

The other thing that was always nagging is that this information was already somewhere else. Whether the job was in preconstruction or whether it had already gone to SAP and been assigned a project number, somebody had already filled everything out that we needed to know about it.

I would like to note that, as of the beginning of this year, 2023, we no longer have to charge our projects individually for the cost of BIM 360, and we have also moved to Build as our solution. We are no longer standing up BIM 360 projects, although we did not migrate anybody off of it. We kept all those legacy projects. So sending our projects invoices for it is no longer necessary.

So, at this point, things were changing, and we were getting a lot closer to cracking this case of setting up BIM 360 projects and Build projects with great ease and accuracy. So this dapper gentleman is my boss, Ted Jennings, and he had this idea couple of years ago to make asking for project software more like the Amazon experience, where you went, and you chose, and you added to cart.

He started calling it Project Shopping Cart. And it was a lot like the form, except it would be easier for the teams to do. You could go back to it, things like that. So, at this point, it was time to call in our professionals. So we called on our app dev team that we employ here at Barton Malow.

And I'm going to introduce them to you. This is Jeff Witulski, Steve Britton, [? Bebe ?] Fong, and John Rathmell. And they made up the app dev team that made Project Shopping Cart come to life.

But they had some challenges ahead of them. Our project requirements were that, because we knew that information was already somewhere else, we needed this solution to search three sources at one time Cosential, which is our CRM; SAP, our ERP; and then the request table that is generated every time somebody asks for something.

We also needed this solution to be able to be revisited. Unlike the form where it was a one-and-done shot, we wanted people to be able to go back and say, hey, I didn't ask for a team the first time. I want to do that now.

We wanted people to be able to see the status of their request. That was one thing that project team still didn't have. They put it out there. They got an automated response saying that their request had been received, pretty much. But unless they went and asked one of us, they didn't know whether it was being done or whether they needed to follow up.

It had to reduce emails, and it had to be available off of VPN, meaning that somebody didn't have to be logged into our VPN behind the firewall to be able to access this solution. And, of course, we wanted to automate everything. So that left the app dev team with some new skills to learn and some challenges.

So they decided they wanted to use the Azure app service. Previously, they would have built this in an on-prem app using .NET Core, but they were taking this opportunity to learn new skills and future-proof themselves. So they went with the Azure app service. And they went with .NET 6 instead of .NET Core.

They had to learn the Microsoft Graph API, which they hadn't really used before. They had to figure out how to connect this Azure app to on-prem SQL. They had to figure out how to connect it to SAP Datasphere, which is where we are housing all of our SAP data, now. Datasphere, in itself, is a new tool pretty much to the company and definitely to the app dev team.

They had to figure out to incorporate those existing Power Automate cloud flows that are handling other APIs, like the Box and Flypaper API, into this solution. And then, of course, the star of this show is they had to figure out how to add the ACC Admin APIs, which are still in beta.

But I'm happy to report that, after quite a while because they had to learn so many new skills, which they did admirably and with great success, that we have finally closed this case. And here's what it looks like.

So instead of calling it Project Shopping Cart, we now call it Project Startup. And this is the home page. Again, this is authenticated by our Active Directory. So you can see that I'm logged in up at the top, and I don't have to be behind our firewall to access this.

So we've got two tabs at the top. We've got All Projects and My Projects. And did blur out the project names because I don't want anybody at my company to come back and give me a hard time that I showed a bunch of our project names because I am not authorized. But, as you can see, we've got a bunch of Cosential data sources coming in. This first screen shows the most recent 10 projects to hit all of our search sources which, as you remember, is Cosential and SAP.

So the next feature is what I talked about with being able to see a status. So on this top-level one here, you can see that Autodesk has been requested. And, down in the lower, left-hand corner, we have status indicators. So it was requested, and it's pending.

You can see that they asked for Flypaper, and it's actually been approved. So that project has been created. Now, if you look at the next to last one, you can see that the Flypaper dot is red. So, for some reason, that one was declined. And then we've got an Edit button and a View button for those other projects because they have already had things requested. So there's where you get to go back in.

So this is the Build interface for setting up a new project. And, basically, it's still the same stuff, right? A project name is required. The account-- that's a freebie. It always comes up with our Barton Malow account-- and then the project type.

So, as I said before, we've already got all this information, either in Cosential or in SAP. So here's what it looks like in the ideal workflow for a precon project to request a new Build project using the Project Startup Solution.

So they would come in here and find their project, hit that plus button. And, as you can see, all the information that we've got in Cosential or SAP is going to come up for them. This is not a two-way street. They can't change any of that stuff that's already come through.

But now they can go down into contact information, and they can add people in. And those are tags, and that's where they're using the Microsoft Graph API. So they can add in multiple people. And it searches our Active Directory as soon as you start typing in more than three characters.

So it's important to note here that once you get tagged as being part of a project, you can go up into that My Projects area, and you can see any of the projects that you have been tagged in, whether you initiated the request, or you're just part of that. And here, the software products, is where things really shine. So the Build is the default setting.

We don't start up BIM 360 projects as a rule, anymore. It is on there for a choice, in case one of our clients is using BIM 360, and we absolutely have to use it. But Build is the default.

And if you'll notice, when I get back to the software products here, is that you can request Flypaper, Box, BuildingConnected, SpecLink, and Teams, all right here. Now, if you want to go back, you can always do that.

So let's say that I'm a precon person. I requested a Build project. It got approved. We did our work in it. We won the project. Now, the project team needs to come back in, and they want to get more products on this O'bleness Hospital.

So they can see, just by looking at it-- and, say, I'm a project engineer now, and I was tagged in it. I can go into my projects, and I can see O'bleness Hospital. And I've been tasked with standing up all the other software, requesting it.

So I just visit the Project Startup Solution. I see O'bleness in my list of my projects, and I can go in there and edit it. So I don't really have to worry about project details at this point because it's already been pulled in. The project's been started up.

If projects want to add details into Build, they're going to have to do that themselves. But this does save a ton of time and not having to repeat what was already in Cosential and SAP. Contact information-- they can add more people, if they want to-- other team members, other project engineers, superintendents, things like that.

Software products-- so we've already got Build. Now, they want to add on Box or Flypaper or Teams. When they click the Yes, instead of it being No, and hit Update, those requests are going to go through. Box is going to be stood up automatically using a Power Automate flow that connects to that API.

And this is the same flow that was being used before. So the App dev team was able to reuse that Power Automate cloud flow and connect this new Azure app to it-- same thing with the Flypaper API. Right now, Teams doesn't have an API to stand up, so that request is going to go to Steve, who is our Teams admin. And he will create the Teams team for the project.

And then for SpecLink and BuildingConnected, that's going to be an approval that goes to the person who is the admin for both of those solutions, so then she can communicate with the teams from that point and find out exactly what they need. But we are using the information that was already put into this solution. So the project teams, again, don't have to enter any additional information to get this done.

So if they want to come in here and add software products, they click Yes. They click Update. Things run in the background. And, now, when they go back into the My Projects area, we can see that O'bleness Hospital has a pending Autodesk. A Microsoft Teams and Flypaper project have already been stood up, and BuildingConnected is pending and SpecLink is ready to go for them.

So this was a satisfaction for one of the major requirements is that project teams can come in here, see the status very quickly, and know what's going on. So no more back-and-forth emails about, hey, is Flypaper stood up yet? And, of course, most of these products are going to send you an email to say "welcome to a project."

Build will do it, Box, Teams, Flypaper. Most of them do it. So that we don't actually have to communicate back with the project team. The software project itself is going to do that.

So this was the magic of being able to use the ACC Admin for Build. This was a big deal for me personally when it finally got released into beta. I'm super excited about it. We've been starting up projects from templates using that beta API. We can also add people to the projects using the APIs.

So it's working great, even though it is still in beta. I'm looking forward to its general release. So what we've got now with this new solution that we've built is one-click creation.

Now, the ideal is that-- and this is going to be the next iteration-- is that it'll run on an approval from Liz or Ashlyn who are our Autodesk technicians. They fully support BIM 360 and Build for our two entities, and that's all they do.

So when someone asks for an Autodesk Build project, depending on the entity, either Liz or Ashlyn are going to get an approval request so that they can just do a sanity check on why that's being asked for. And then they can hit Approve. That'll hit the ACC API, and it will send that off to be done. Liz and Ashlyn are going to be freed up. They don't have to go into the UI and set that project up manually like they have been.

So the new project is going to be set up from a template, which also depends on the entity that the person is with, that the project is coming out of. And we're going to be using that captured project information out of Cosential or out of SAP. It's going to add all the requested team members to the project. Again, Liz and Ashlyn don't have to worry about it anymore.

And then it's going to return that success message and change the indicator in the app for them, as soon as Liz or Ashlyn hits Approve and the API routine runs. Then it will report back, and the indicator will change automatically.

So if you look back as to where we were getting mysterious emails from our project teams to ask them to set up BIM projects to where we are now, where project teams don't have to feed us all that information, and we don't have to do any detective work, I think this is a major win using Autodesk platform services and, of course, our great app dev team and a lot of ingenuity with automation.

If you'd like to get in touch with me and ask me more about this solution, you can reach me on LinkedIn. And the correct name of my spelling is on the first slide. So feel free to reach out to me. I'd love to talk about this solution more.