Changing Change Orders: Improvement Through Autodesk Construction Cloud, Autodesk Platform Services, and Workato

JOHN SAPP: Welcome to our class, Changing Change Orders: Improvement Through Autodesk Construction Cloud, Autodesk Platform Services and Workato. I'm John SApp, and I'm the CAD/BIM Manager for City of Madison Engineering. I started out working for Madison in the field for two years as a construction inspector. Then I worked for eight years as a Civil Engineer doing project management and street design.

The last two years, I've been in my current role as CAD/BIM manager, and about 90% of my time is /BIM, not so much your Revit building information model, but more the construction administration side. My overarching mission is to transition Engineering to the Autodesk Construction Cloud.

A big part of my job also is the automation work in Workato using Autodesk Platform Services. It's very satisfying to take a tedious manual process and automate it to make it much easier going forward. And with that, I'll hand it over to Michael and Joey from Team D3 to introduce themselves.

MICHAEL PARES: Thanks, John. I'm Michael Paris I'm the director of Enterprise Services at Team D3. Team D3 is an Autodesk Platinum partner and now part of Symmetry this year, which makes Team D3 part of the largest global partner for Autodesk. I don't have a ton of industry experience in AEC, but I did spend one summer as a construction estimator. That's real. That really did happen.

Most of my experience comes from 15 years of software implementation, integration, and other things in the aerospace industry. And then for the last 3 and 1/2 years, I've been leading enterprise services at Team D3, and have spent most of my career leading technical teams, cross-functional project teams, and working across all kinds of different enterprise systems, customization, implementation, integration, data analytics, automation, all those things, PDM systems, PLM, ERP, CRM, and then more recently, working in a bunch of AEC systems. Connect with me on LinkedIn if you can scan that code there. I'll pass it over to Joey.

JOEY BAUGHMAN: Hello. I'm Joey Baughman, integration consultant with D3. I've been here about 5 and 1/2 years. I started off as a project manager in the PLM realm, and the last 3 and 1/2 years, I've spent implementing, architecting and integrating PLM systems kind of across the board to various enterprise systems, and creating those solutions. And I've also been diving more into the ACC realm in the past year and helping out the City of. Madison I'll hand it back to John.

JOHN SAPP: Thanks, Michael and Joey, for the introduction. One more introduction to make is to the City of Madison in Wisconsin, We have a rapidly growing population of 270,000 people. A lot of public and private construction to support that keeps our engineering department very busy. We are the site of the State Capitol and the university, the flagship university, UW Madison, one of the top-ranked global universities in many programs. Also, a lot of tech startups and more established companies make up all the major employers.

Lakes are a big part of Madison's identity. We're sometimes called the City of Four Lakes. The State Capitol and Downtown Core Area is actually an isthmus between our two largest lakes. So boating, fishing, ice fishing, are big activities. Finally, livability. We pride ourselves on being a place where people want to work and play. We have policies that we try to do to make that happen, and it's reflected on a lot of lists nationally and internationally.

Presentation outline. First, the problem. Why did we change orders? Objectives, both our learning objectives and change order objectives. Collaboration. How did I work internally with the City of Madison? And then Joey will detail the unique working relationship between City of Madison and Team D3 while also discussing his work with Autodesk.

Then Michael will talk about automation, how automation works generally and how it fits into the Autodesk suite of products. Autodesk Construction Cloud, Autodesk Platform Services and Workato. How did I use them all to get a change order from start to finish? No case study is complete without a discussion of failures and how you can learn from them, review our results, and then finally, what does the future hold for us.

So why did we change change orders? Well, just to give an overview of the situation, our Facilities Management Group had a critical need to replace their SharePoint system. It was 13 staff who managed facilities owned by the City of Madison, everything from design to construction to operation for a variety of projects.

So in mid-2013, they deployed Microsoft SharePoint. Over time, legacy software issues compounded. We had no support by IT, Microsoft, or modern browsers, and it was difficult to replicate customization. It was built on SharePoint 2010, very heavily programmed and customized, so we couldn't just adapt it to modern SharePoint, and had a one-time quote to do so of $500,000, not including any maintenance or support or training.

However, at the end of the day, it was a vital part of their day-to-day operations, so we needed to do something. So why did we go with the Autodesk Construction Cloud for that? We just liked the new way of doing things, the fact that it's already built for construction. It has that built-in support. Everything is by project and in one place, reducing emails and scattered files.

And then finally, the big one that set Autodesk apart from its competitors was PlanGrid and Sheets. So PlanGrid is a separate company that Autodesk bought, very well-respected company. Autodesk incorporated it very well into ACC via Sheets. And a bunch of different advantages.

One, you can view very large PDFs that would kill the most capable CAD machine. Works flawlessly on an iPad. Also, works flawlessly, very low learning curve to do markups. You can add rich data like photos and punch list items, things like that. It's very powerful suite of tools and a big reason why we went with Autodesk. So as a result, we purchased Build Unlimited license beginning of 2023, and we deployed on projects in the summer of 2023.

So why are we talking about change orders? Change orders have numerous challenges. They're inefficient and expensive. When you have to do a big change, all of a sudden, when you have a street ripped up and you weren't anticipating it, it can cost a lot more to deal with things. You're willing to do whatever it takes to get the issue resolved.

Tie-in with other processes, such as pay apps. We have legal limits by contract and municipal ordinances that we have to follow. And then finally, a proof of concept. That was a big thing in my department. It was, well, if we can make change orders work, we can make anything work.

Objectives. What have we hoped to achieve? First, our learning objectives. How do we deliver change within municipal constraints? We have a lot of budgetary and legal issues to navigate. Software support and institutional knowledge for success, This will talk about how I worked with Autodesk and Team D3, and then also internally with city staff.

Advantages of cloud versus email and paperwork. This is becoming more and more obvious as people get into cloud applications, but I think we'll have a lot of examples throughout this presentation that help drive home that point. And then how do you avoid legacy software and processes pitfalls with updates and re-examinations? That's one thing we found, is not just cramming this old process into new software, but also revisiting the process entirely, and seeing how the new software tools can change for the better.

What were our targets, our objectives for change orders? We wanted to maintain the same look of review documents. There's a comfort level there. People are used to it. Reduce manual data entry. We have several Excel databases and spreadsheets and access databases as well. We want to expand the usefulness of the data.

And finally, track review. There's a lot of complicated approval processes we need to do with the city to cross our T's and dot our I's. And pre-COVID, for paperwork such as plan routing, we'd literally take a set of plans and move it from one desk to the next. And it was easy for plans to get lost on people's desks.

Then with COVID, we switched to email, which was worse in a lot of ways, because we had so many emails, and you couldn't find plan approvals being done via email. So we're very much looking forward to fixing that process as well. Big part of the process for us too was saying no, no easy way out. We had clear rules, so no paperwork, no mail, no scanning, no hard-copy signatures. No leaving the platform, no manual downloading, no printing to PDF or manual assembly of pages. No duplicated data entry, no more tedious, time-consuming error-prone tasks.

Now I'll talk about collaboration and who helped advance the project. First, we want to look at the numbers. This is for all ACC/APS work and not just change orders. 209 meetings over a year and a half, everything from one-on-ones with my boss, weekly recurring meetings, to emergency meetings when things seeed to break. 551 ACC support emails for a variety of things, me being new with the software, there being bugs, and then actual feature requests as well. In a similar vein, Autodesk Platform Service support emails.

Finally, 8,338 test account emails. So this is across over 100 accounts that I made, and these were a series of fake Autodesk trial accounts that I kept rolling through every 30 days to test things out, because we only had eight licenses. And it wasn't nearly enough to test all the roles and interactions and permissions we needed to test. And I didn't thankfully have to send that to a bunch of human addresses. It was just something that I could test out on my own.

Here, we've got a nice diagram that shows our collaboration connections. We've got internal connections with the solid, colored lines, and then the dashed, dark lines showing the external, except for me. I am outside of the city just to make those connections clearer, because this was my life for the last year and a half. I was in direct communication with everyone working with change orders.

So I navigated a lot of internal decisions we had to make with the city. We had legal considerations, such as the fact that change orders are changes to contracts. We had to follow state statute. We had to look at our public works specifications and how our contracts are written to make sure it works with a cloud-based system.

They're controlled by ordinances. That governs a lot of rules. So we're seeking to append and change everything. We still have to abide by the ordinances for our change orders. And we needed to allow for digital signature. This was a big one for us. It would just be so much better to eliminate having to print things out, sign them, and then email or scan them and mail them. So eliminating physical signature in favor of digital signature was a big undertaking.

With our administrative support staff, I've determined what and when info is needed. A lot of times, we'd have public meetings to review change orders, and the software didn't really support a specific time that they would need to have the data sent to them. So we had to add that in.

And they had a real desire for change. Our administrative support staff, they pick up the pieces when the project managers don't do what they're supposed to do, and they definitely know that some staff don't do things that they should, that they're getting a different process for each person they work with.

So having software do a lot of the work for everyone and it enforce these things more, they were really excited to see that, and they had a lot of good input. Finally, deputy engineers. Everyone reports to a deputy engineer in City Engineering, so they guided the overall process, the look and feel of our review documents. After all, their only interaction with a lot of the stuff is at the final stage when they see those review documents.

And then finally, pushing through barriers was a big thing. My boss in particular was instrumental in this. She saw the vision of what the cloud had for us, and we had numerous budget and just getting people on board obstacles to overcome. How do we convince people to commit to this product for three years that John just spent the last year and a half alone developing? That was one challenge.

And then we had a lot of budgetary issues. It's not inexpensive at all, and we had to go out for bid. So it was uncertain exactly what our license price would be. We had to get approval from finance, our own internal finance, City Finance. We had to get approval from purchasing IT. It was no small feat to even acquire the license. And with that, I'll hand it over to Joey to talk about Team D3's role of collaboration.

JOEY BAUGHMAN: Sure. So to build on what John said, we wanted to help in the most efficient way we could possible. So kind of to just cover our roles and approach was really to be a mentor and consultant to John, and just guide on some of the integrations, best practices, and various approaches we could take, offer technical assistance when necessary, whether it was with API calls or syntax issues, that sort of thing.

Occasionally, just custom development, and then also debugging, error handling, looking for ways to improve really the overall solution in general while keeping John as like the primary integrator. So it's really, just like I said, we were a consultant role and really kind of handed him the puzzle pieces, if you will, so he could integrate them into their solution. The next slide.

So just to cover some of the best practices, we've covered recipe modularity. So again, the middleware we're using is Workato. It's ACC Connect, which is Workato with ACC connections and that built into it to make it a little easier to use. So we use that to make the solution scalable and easy to navigate throughout. We looked for areas for optimization and efficiency using the right searches versus for-loops and that sort of thing, recipe functions.

I gave some guidance on the dev environment. That was one of John's pains, was deploying updates once the thing was in use, deploying updates, kind of ongoing. And then again, error handling, just making sure that worked as seamlessly as we could. And again, this is all kind of consultation to John. He was really the principal architect for the solution, but with our assistance.

Then some of the technical mentoring and development. First webhook creation and management. Webhooks were introduced kind of during the project, and those weren't available to begin with. So in order to take advantage of that, there was a lot of architectural change that had to be made and planned for.

Function recipes, kind of going back to that modularity aspect. Postman set up and guidance. It was easier to work-- oftentimes, it's easier to work in Postman than it is just making API calls in Workato directly. You can experiment a little faster.

Workato's specific functions and syntax. There were a few times just giving guidance or working through issues on that with John. And then development of just general new automation. I think one of the last pieces we worked on was transferring attachments between change orders to prevent users from having to do all that manually. Next slide.

Next, let's get into ACC support. So this, really, John and I both worked with ACC support, initially just to set up the Workato account and configuration and get the users in, and that sort of thing, but also just navigating the tool, learning it, learning about its features and building-- sometimes, we'd ask for questions to build out specific functionalities within Workato, and that team was helpful.

The next slide is working with Autodesk's APS Support team directly. That really was helpful when we encountered API or software bugs. They would offer assistance and guidance and debugging on that, or help provide with workarounds that John could put in place to keep moving forward, as well as API documentation and guidance. Not all the APIs are exposed, or sometimes, they're new and coming out, or the webhooks are coming out, that sort of thing. So we worked fairly closely with support throughout the project as well. And that's it for me. I'll hand it back to John.

JOHN SAPP: Thanks, Joey. For the next section on automation, Michael's going to talk about automation in general, why it was needed, and how does this all fit in with the Autodesk suite of products.

MICHAEL PARES: Thanks, John. So if we pop over to the next slide, one of the things I want to talk about is the sort of wonderful thing, wonderful opportunity that the city of Madison had in landing on a platform decision like the Autodesk Construction Cloud. With the budget constraints, the time constraints, the different stakeholders, it was important for the city of Madison to reduce their need to decide on things too early and converge too soon on specific solutions.

They had so many different legacy systems and different stakeholders, and bits of data that they needed to connect. So in order to keep those things running and essentially not misstep when it comes to the various regulations and things that they needed to contend with from a legal and governmental standpoint, it was just important for them to keep those systems running, keep those things in play.

And landing on something like a common data environment built on top of ACC allows for, especially when you incorporate ACC Connect or Workato, or any of these other middlewares, allows you to connect and automate on that common data environment, allows for prototyping, testing out solutions, exploration, and to drive to the right solution while keeping track of what is the current legacy and future systems and arriving at the right mix, basically, the right mix for now, and also to have the flexibility that you need for the future.

So one of the things with Team D3, the way that we played into this, we've been a long-time [INAUDIBLE] partner and have deep experience in integration and middleware, but we didn't have a tremendous amount of experience early on Workato and ACC Connect. But we brought all of our past integration experience to our work with John, with ACC, and using Workato. And Joey and the integrators have now gained a good bit of experience through these kinds of situations.

But regardless, what we commonly see across platform decisions, especially when it comes to common data environment, is examples like this. You're trying to drive a connected data strategy, and driving to a CDE and the ability to leverage and utilize and realize that strategy.

So that's why you're in such a good sort of position with something like ACC and ACC Connect. You have already 200 native integrations to various construction applications. You've got partner cards. You've got all the Platform Services APIs and other APIs that you can call from there. You've got really access to hundreds of different workflows, and there's always a way to drive at a solution.

But the other piece of it that was important to meet the City of Madison's requirements and their goals is landing on top of a CEE like Autodesk Construction Cloud. You have a robust enough place for all of your data to be stored to stay in one system, to meet those needs, and just to stay out of the silos, but also to take that approach in steps. And that's what we've seen here with the City of Madison. Let's go to the next slide.

You know, more and more AECO organizations regularly add all kinds of different apps, all kinds of different systems, to their tech stacks. And that trend just doesn't slow down. So the standalone software applications, legacy applications, new applications, all of that creates those data silos, those disconnected workflows.

The integration that you're able to pull off with these systems, the integration that the City of Madison has done with their change orders and various things, making that data, those notifications, consistent, available across tools, making sure that people are working from the latest data, all of that becomes enabled when you work with something like us.

So everybody needs to integrate dispersed software applications, so your organization can do more with less, right, the whole idea, the whole concept, be able to actually take advantage in reality, and quickly, of sort of what's really possible. So let's go to the next slide. The way that Team D3 approaches this overall sort of connected data lifecycle, it basically looks like this.

This is our view of what a management process fundamentally should look like. The business processes that you see there all the way on the left, that includes processes across all different areas. It can be all different industries. But all those things used to plan, define, build, support, improve projects or products, or services, those things that are so deeply rooted in the people and their expertise, and their abilities in your company, all of that is really the lifeblood of an organization. It directly impacts the ability to thrive and grow.

And over the course of data lifecycle management, nearly everyone in an organization, including internal consumers and external consumers, suppliers, partners-- everybody plays a role with connected data like this. So it's impossible to overstate the importance of these processes and these things to the overall health of your organization.

So I'll leave it with this last slide. Basically, if you go to the next one, John-- yeah, this one really encapsulates the condensed, boiled-down version of what I'm trying to say, that the way that we see it, it starts with connected data.

From connected data, you derive structured information, which leads to knowledge, and from knowledge, you gain insight that you never had before. And from that can come the wisdom to make the best decisions possible going forward. And that's what we want to enable with a connected data strategy on top of a common data environment like ACC and ACC Connect. That's what we hope to bring to the City of Madison. So I'll pass it back to you, John.

JOHN SAPP: Thanks, Michael. The next step of this process, we're talking about Autodesk Construction Cloud, Autodesk Platform Services and Workato. How did it all come together to work for change orders? First, just want to clarify one thing. Autodesk Construction Cloud includes several modules, and cost management is what the developers intend you to use entirely for change orders. But we found that we needed build as well. So that'll come up later in the presentation, that we use an aspect of build called Forms.

But there were a lot of things we liked in Cost Management out of the box, and we did use a lot of them, such as custom attributes. You can have different things for users to input in different formats, such as date, text, checkbox. Not shown here, you can also have a dropdown selection tool.

Document templates. These are really nice because instead of having to manually generate all the data you see on the right by typing into an Excel file, you have all this data already in the system. And it's just a series of simple clicks for the user to generate it. Some legwork goes into creating the initial document template you can see here on the left, but it's very customizable, very powerful.

What you see in curly braces are document variables. Very good documentation in the Help section of Cost Management about those. You can have multiple rows using correct code show up based on how many items there are. You can have checkboxes. You can have formulas execute. All very powerful.

Approval workflows. So this gets back to that paperwork, moving paper pre-COVID from desk to desk, and then post-COVID, being emails filling up people's inboxes. So this still does email notifications, but it's still an all-in-one platform. You have a home page where you can see review processes assigned for you.

So this is a change order approval workflow, and the way it works is an example. As our construction manager sends a change order for review, it would first go to the deputy engineer. Deputy engineer gets the email, follows the link, and is taken to a page where they can review the document package. They can also review the data live in the system. There are a variety of ways they can interact with things.

Then if they are good, they can simply hit Proceed to push it to the next step. As shown here, that would simply be Finance or Accountant. Or they can comment and ask questions, do any form of communication. If things need to restart, they have a revised option. And you can have multiple types of workflows being triggered by different conditions, which we'll get into later.

Connectivity of the data. The apps have change order data. This was a big one for us. We used to have to have a separate spreadsheet for pay apps, and every time you did a change order, you'd have to go back. That would be one of the spreadsheets that you had to update. So having that data automatically populate through was huge for us.

In spite of all this, we found cost management lacking in key areas for our process, thus requiring automation. It was too permissive. In order to give the contractor the ability to input and review things, they could edit the data at any time, and we didn't want that. We simply wanted that input, and then we wanted that approval later.

Look of the input method. It was a bit bewildering how much stuff there was you could set, a lot of it not applicable. And that was the early feedback I got from our staff early on, was what am I supposed to do. What am I supposed to hide? Why is there all this stuff? So simplifying the input method was something we needed to do.

We needed a different set of calculations. You could only do markup and tax, and we didn't even need tax. But what we needed, we need GC markup, subcontractor markup, GC supervision of subcontractor, and bond. We needed to document each step and subtotal. And we also needed to move custom data from previous stages. When you have those custom attributes, they don't automatically move from step to step, so we had to automate that process.

And then finally, complicated review workflow conditions. As I stated, there are multiple review workflows you can set up, but the conditions to choose which process executes was complicated. And I'll explain that more later. So we're going to go through the change order process start to finish and see how we used all the tools.

So the first stage of the process, the contractor submits change order requests. So for this, we used Forms and Build as the input method. We like Build because there are detailed permissions. We can allow it. So that the contractor could only create a form and submit it. Once they've done that, the data is locked, and our construction manager, the city's construction manager, can review it and sign off or send it back.

Throughout, there's communication. The communication happens right next to the form. Everything is within context. Since it's a smart PDF, the look can be customized. You can do any number of boxes, any color, any font, anything you want. You can capture as much data or as little data as you choose.

Complex calculations. You can have numerous boxes calculate on other boxes to get any desired calculations you'd like to see.

So we needed automation, though, to bring in the cost management. We like cost management, we need to get in the data and files. Also, since this wasn't what the developers intended, we needed email notifications to let people know this was happening. So here, you can see the form we came up with. At the top, blue boxes pull data out of the system.

The green are input fields such as the change order request name. You can see here, it is populated through to Workato on the back end. There's also a checkbox. And then we have that final grand total for this change order request populating through, and then even other fields, such as a check box that will come up yes if it's checked, or even a subcontractor name, that kind of thing. Everything else in blue you see below the top is all calculated within the form itself.

Here, you can see the data that was in Workato now going back and creating and updating a change order request. So this is the first stage within cost management. So here, that name is going through to that change order request. And then the type contract extension required is being filled out here.

The next stage, the city needs to package several of these change order requests into one change order. And here, we went completely out of the box with what cost management had to offer. And I will show that in this demonstration here. So the first step, we are in cost management. Everything's been imported by default the way it should look. You got the change order request name, the committed value, and the type. This first step, we're selecting an account. This was nice. You can have these accounts pre-set-up.

And then we go into what's called the fly-out. And you can see here, we've got that cost.pdf, the first file. That is a hard-written PDF of the smart PDF that's locked. And then the second file is a file that was referenced to it, such as material supply receipt or wage report. Then for custom attributes, we have these in order to justify it.

So the review staff wants to see why are we doing this change order. Oh, existing electrical panel is undersized, and another reason, check box differing site conditions, and the design did not adequately anticipate field conditions. And here we like to combine several change order requests together. It makes the review process easier when you can approve multiple at once.

So very intuitive. You just click and then assign to a processing change order. Processing change order step, you can see we've expanded the hierarchy. We have change order requests underneath it. And since we have a time extension for the contract, we have to set a new end date. Another custom attribute. You can do it in the flyout or you can do it in this table view.

Here, generating the document template just takes a few clicks from the user. Polls in data already in the system. And then we can bring in data from the change order request. Those documents that were attached to those change order requests are brought in automatically. Those change order documents are now all merged into one document. This first was originally an Excel file turned into a PDF. These others are PDFs. You can have word documents, JPEGs, PNGs. You don't have to print each file separately and then combine separately in Adobe.

Next step of the process, we had to use forms again as a confirmation method. We needed to get this data before the contractor to approve it, since some time had passed since they first submitted the change order request, and we needed to get it in as a official change to the contract. So having forms as the confirmation method, though, they were tedious to create and it was tedious to set up referencing. All these automated activities, we had to do manually, as the next demonstration will show.

So in this video, you can see here we have what I call simple clicks, simply clicking to advance things forward, and input events, where you have to select from a list or type the input. And this is the manual process. We had this for months. So you have to select the right reference, which is a form, the right form type.

You have to manually type in a description. A couple more clicks to create that. Then we're going to follow to the form. We're still not done. We have to attach the document package file from the processing change order. Going far outside the box that the developers intended. So we do a search. You have to select the right result.

And for this step, you can see the form from the processing change order, but you can't see the processing change order from the form. We want to establish that link, so we simply go and grab the URL of that processing change order and paste it into the notes section of the form. But again, another tedious manual step.

So that is the manual process, 14 simple clicks and 8 input events. We can do better than that. So this process, I'm going to pause it just because it goes so quick. It actually only takes about five seconds with the automations, but I show a little bit more just to verify that it's done all the same stuff.

So one click to kick it off. Another to expand the link references section. And it's already created. We're simply following the link now to verify that the data is in there. Got the description, got the file referenced. And the URL has automatically been pasted in.

So three simple clicks verses 14. And for me, the big point was 0 simple input events versus 8. We got a summary there. And really, those eight input events are all just using data in the system, and we're requiring the user to move it around. So that was just a prime candidate for automation. Last step is the city staff approval, very detailed set of requirements here.

So we had numerous applications for automation. We had to copy data from previous stages, those custom attributes. Notification and status changes to key staff. So statuses change but don't always send people the notifications at those key times. So we needed to add additional notifications within Workato.

And the one I'll talk about here, determining the type to trigger approval workflows. So you can have an approval workflow triggered by types that you pre-configure. So you can have one type be a more complicated versus another type being a simplistic review process.

And a lot had to happen to make this work. We had very complicated review conditions for a more complicated-- what we call the BPW, or Board of Public Works process. It's a public meeting that only meets a few times every month. It's a set schedule. You have to prepare the agenda a week before. So there's a lot that goes into it, and there's ordinances that guide whether you have to go through that process or not.

We have three conditions to look at. One is, will it be over contingency if we push the change order forward. So we had to read in a budget and a budget contingency factor of 8%, and do the math of all the change orders, how much they add up to. Is there a time extension? And then is this over 20,000?

Over 20,000 alone was simple, but the fact that we needed all three of these was why we had to go with automation, because if any three of these are true, we had to go to a Board of Public Works approval process versus that non-Board of Public Works approval process, which is much simpler.

Failures, what went wrong and how we responded. So these are failures related to Autodesk ACC and APS, not my fault. So first, forms, the way that they're important to cost management wasn't working, and it was due to reviewer by role not working, key functionality of forms that I was relying on. And it's simply a software bug that as of the date of this recording, September 25, 2023, is still awaiting a fix. They've kept me in close contact. I've got a workaround, and we are both looking forward to seeing this resolved.

Cost management. Links from emails didn't work. I mean, that's a big deal. Didn't even know what the cause was because thankfully, it was just a software bug the development team fixed. Finally, Autodesk Platform Services. Change order type was incorrect, and this is because it was not pulling in change order data incorrectly. So I had to rewrite the automation.

This is a good example of where I leaned on Team D3 to help me. It was something that we needed Autodesk Platform Services to help with, but it was very bewildering, and it came at a bad time. So they were able to use their tech support skills to work with me and Autodesk Platform Services, and ultimately, passed on the code that I needed to change to make this work.

They had access to all my automations and could see how I had things set up. So what were my mistakes, or honestly, what were my worst mistakes? Thankfully, Team D3 helped me through a lot of those mistakes. So one thing that broke were multiple projects. I did early work for just one project so had to completely rethink things and change the architecture of automations. I had a couple meetings where I floated different ideas.

And I think the most insane one was just create a new set of programs for every project. Thankfully, Michael and Joey talked me out of that one. Automations during troubleshooting. When it went down to make it work for multiple projects, it didn't work for any projects, because I didn't have a development environment.

So again, went back to Joey and Michael, and came up with different strategies. Joey looked into what was probably the best option, but it was another yearly subscription to connect to make that development environment. So we worked well, I think, within the confines of the tools we had.

Missing events, having long recipe time, the automations were running for too long. So missing events, I just had bad filter use, where it was just not picking up any data, or it was picking up all the data, but then having to look at excess things that I didn't need to look at. And I spent probably the better part of a day looking at this, and finally, I was like, oh, let me just ask Joey, send him an email of what I was trying to do and where I was at with the syntax. Within 10 minutes, he got me back a response that fixed everything for me.

So lessons learned. You have to think ahead. You're going to have multiple projects and need that development and production environment. You need to stay flexible. There's interim workarounds that you can use. You're just going to have to accept failure sometimes. You need to learn from it and work around until you can resolve the issue.

Test, test, test. Think of everything that could possibly go wrong and make it happen all at once in different combinations. Just the more you test, the better. You need to lean on those collaborations, because sometimes, there's bugs you can do nothing about. Sometimes, they're your mistakes, and it's just hard for you to see your own mistakes. Either way, collaborative teams can solve quickly.

Let's review our results. What have we achieved? First, our learning objectives. What did we learn today? How to deliver change within municipal constraints. You need those champions for change. You need your rule experts, careful budgeting. Software support and institutional knowledge for success. So there, we had our collaborations with Autodesk and our consultant team D3. We had the collective experience of city staff. We had my experience working in a variety of roles, and then all the staff I worked with over the years and throughout this project.

Advantages of cloud versus email and paperwork. Just reduced data entry. We have the data entered in once, not having it entered into an Excel spreadsheet manually, not having to enter it into a pay app again. It's faster, and the data gets reused. Avoiding legacy software and processes pitfalls with updates and reexaminations.

This is ultimately a software-as-a-subscription product with integrated updates. It's still important, and we look forward to doing this, to reexamine our processes periodically, because we haven't actually done a change order in the system yet. And as we do them, there's going to be big changes, I'm sure, to make things better.

So did our results meet our objectives? Let's look first at our change order objectives. We wanted to maintain the same look of review documents. The change order solution here was forms and cost management document templates. We can make them look exactly the way we want, both the input and output methods. We want to reduce manual data entry. We used automations by Ricardo to transfer data for us.

Expand the usefulness of data. Pay apps are closely linked to cost management. We'll finally track review. Using those approval workflows, we can see right in the process where things are, and people can see on their home page what items are due or close to due. And finally, the future, what we have to look forward to.

As I've gotten more and more into this process, come to find out that there is a lot involved with project setup. Started out as like a 15-page document. Now it's 36 pages, and I had to take someone completely unfamiliar with the system after all my development. And it has been a lot of learning for both of us to try to get a process that works. So team D3 has some exciting tools that we're really looking forward to implementing for project setup.

MICHAEL PARES: So I guess I'll go ahead and talk about those. Thanks, John. So as we look to the future, you know, one of the things that the City of Madison wants to improve, project setup. And this is a fairly common ask from a lot of our ACC customers. And so we've been steady at work building out ACC Power Tools on our ForgeFlow platform, which is our own sort of cloud product that has power tools for various things on platform services.

And one of the things you can see over here on the right is sort of the project setup wizard. And so other things that we are going to be building out here in our ACC Power Tools product in addition to initial project creation, bulk modification of projects, template selection, and sort of complex folder structure application, folder validation checking, setting up new companies, internal users, external users, folder permissions.

And of course, you can't get away from the spreadsheets as much as you'd like. We will enable those capabilities to load those things from spreadsheets because so many companies have those existing setup spreadsheets where they go collect the information.

But we'll also enable other methods like through APIs to essentially simplify the data and what you need in addition to offering sort of this greatly enhanced set of experience that you're seeing over here in the wizard. So that is some of the things that we're looking forward to releasing to the public and rolling out for the City of Madison over the next year.

And is that our last bit? Yeah, so I thought. So I'll just say, thanks, everyone. If you're interested in learning more about ForgeFlow, those upcoming tools, reach out to me over LinkedIn or find me on the Autodesk partner website, or AU website, TD3.com.