Ditch the Server – All in project management with Construction Cloud

DAVID NEILL: Welcome to CES3108, "Ditch the Server-- All in Project Management with Construction Cloud." I'm David Neill, Design Technology Manager at WSB. And joining me here today is Dan Lench and Matt Adams, Corporate CAD Managers at WSB. Today, we will be presenting three learning objectives. The first is Setting Up for Success with David Neill, Document Management with Dan Lench, and then closing it out will be Bringing the Team Together with Matt Adams.

WSB began its journey and the common data environment with BIM 360 in 2019 to store and collaborate on InfraWorks models. That rapidly grew into pilot projects in BIM 360 and then Autodesk Construction Cloud. Between early 2020 to September 2023, we put roughly 50 projects to the test, working through configurations and learned on project templates, user permissions, file naming templates, best practices with desktop connector, bridge, model coordination and collaboration, clash detection, and quality management tools for review, markups, and issues.

In September 2023, we went all in, all new projects created in Autodesk Construction Cloud. In this industry discussion, we will discuss how WSB transitioned over 400 users and more than 400 projects to Autodesk Construction Cloud within a year, eliminating the need for a server. We will discuss lessons learned and enhanced file management techniques, including desktop connector and minimizing file management errors and circular references.

Learn to use file naming templates to streamline company file management standards, explore the user management systems and ways to effectively manage users. Permissions and project templates, understand how bridge can create connections across the projects and clients using Autodesk Construction Cloud. We will conclude with strategies for bringing the entire team together, regardless of whether they use a CAD platform. Learn to utilize review tools, markups, create issues, and leverage quality management tools to keep your team communicating and connected.

Setting up for success. We'll be covering templates, user management, user permissions, and file naming templates. The first step to a successful integration in ACC is setting up functional project templates. We discovered at WSB pretty quick that the old network project template needed a makeover. There are many factors that go into creating a project template, but the most important revolve around member access and team collaboration.

In our project templates, we built out our initial template from our old server template. We quickly discovered that its linear structure did not lean towards the ability for us to provide permissions across user teams to create logical team shares. It became quickly relevant or quickly obvious to us that we needed to modernize our template. WSB as a whole quickly revamped our project templates into a more logical system to be compatible with common data environments, not just ACC. We set things up so that we could logically set permissions across different file folders, to set things up in order to have logical areas in which project teams, both internal and external, could have shared environments for sharing files and working collaboratively, as well as bringing our standards into the project so that we could utilize and take full advantage of things like Sheet Set Manager for web.

One of the important things about establishing a functional project template is how you manage the users and permissions within it. First step at that project template level within the configuration is permissions, setting up a solid admin team to administrate the environment. But within that, we need to be cognizant of the fact that we've got to publish this template. We can create projects from an unpublished template, but if we don't publish this, the users and the admins that we establish in here, even at a member level, won't automatically be added to the project. So we need to make sure in this functional template that we publish it so that we can add users.

WSB also, in our lessons learned, learned that we only add our admins both for environment and project to our templates. We add our users after the fact, either through various means, through the ACEC portal or through automations to keep our Desktop Connector project list small. We can or you can add your entire user base to the template, but that slows down your project creation and creates a longer list within your Desktop Connector.

User management is definitely a daunting task in ACC, especially if you're trying to go user by user. There are tools available to speed that process up that don't require automation or APIs, that we can do bulk exporting and importing, as well as the standard individual import and small member imports. One of the things that we need to be cognizant of is that as we import our users, we need to make sure that we are setting up companies, buying companies, and also applying roles to these users, because that's going to be a very important factor in user access later on.

Bulk exporting is start with what already exists. Go into your licensing management portal and export your already licensed user list in an Excel file from your management portal. Once you have that Excel list of 100-plus users-- in our case, we're pushing the neighborhood of 450 users-- you can go into the ACC portal, and under the account admin BIM 360 admin, go into the Members, Add Members, and download the member list template. Once you have that, you can take your user list that you exported from your licensing portal, copy and paste into that template, and then import that into the BIM 360 admin portal.

Since BIM 360 and ACC share the member list, this is the function to do a bulk import of more than 100 users. One thing to keep in mind is that the BIM 360 import only does company permissions. So when you import these, you will need to make sure that you go back through that list and make sure you apply role-based permissions to each of those users because those will be important later.

We can also do individual and small group imports, which, when you're working on a large project that involves members outside of your company, you'll need to add those email addresses to give access to your project. So under the Account Admin Members, we can add a single user. Or we can, if you're managing a smaller CSV or Excel files of member lists, add up to 100 members within the dialog available in the ACC members.

This might be a better way of bringing in some of your larger member lists, because at this point, this is where we can globally apply role and company. So depending on how you're trying to manage that list, you may want to maintain your CSV or Excel files by roles versus a master list. That way, you can easily apply roles as well as companies.

Role-based permissions. There's multiple ways we can apply permissions within a project. At WSB, we learned pretty quick that to work on a large project that is multidiscipline, multi-company, company-based permissions get daunting. As well as you can only apply role based permissions to a template, you can't apply company permissions.

So in our templates, when you're in files of your templates and go into Permissions, we use all the roles available as a default in ACC. We'll add a few here and there. We added the project CAD coordinator role as a quality management position, and we utilize the BIM manager as our administrative position. The remainder of the roles are default, and you can set those roles to either be a administrator or a standard user, project team member.

At the root project folder, we set everything to admins have either edit or manage, and everyone else is D plus download. And then once you dive into it, you can get into subdirectory permissions where engineers have permissions to a design folder and a different discipline, such as a survey, as permissions to their folders. Once you create a project from this and add members, because these roles are predefined in your template, the users automatically populate within these categories, which is why you want to set those roles on your user imports. We found pretty quickly that establishing role-based permissions creates a much better quality management system across the project than using the company-based or everybody has access or permissions feature within adding to the projects.

File naming templates, that's another one of those quality management features within ACC. It's not a mandatory, but we learned pretty quickly, in addition to our role-based quality management use within our templates, that this is another functional way to maintain consistency across your project and maintain your standards. ACC comes with a predefined file naming template, the ISO 19650 template, that you can add into your projects.

And keep in mind that when adding file naming templates, you can't add that to the template itself. You can only add a file naming template to a created project. So once you use the ISO 19650, create your template, you'll want to export that file as an Excel file so it can be re-imported into your projects later.

An example of how we use our naming templates shows up in project files. Here, you can see within our holding area, we've got a file that's breaking standards. We come in under Docs, File Templates-- file naming templates are under Docs-- Settings, Naming Standards. We can apply multiple naming standards and view, edit, and select folders that we want to apply those naming standards to.

So in this case here, we've already got some selected. When I come in and look at this, you can see I've got naming template and apply. But I can also take a different naming template, if I've got multiple styles of naming templates based off my use, and apply another naming template to other subfolders.

Once those are set and a user adds a file within ACC that violates the naming standards, it goes into the holding area. Once you see your file in the holding area, you can validate that file and come out and fill the form out that allows you to bring that file current to company naming standards. And once you resolve it, it puts it back in the correct directory.

The one thing to be aware of with the naming templates is Desktop Connector doesn't recognize that file is in a holding area. So one of the policies that we applied at WSB is that even though we're using Desktop Connector and our software that accesses files through Desktop Connector, we tell all of our users, always use ACC web. Always have that open. Use that as another tool to manage and follow how you do things within this environment.

And then that leads to document management and how, once you're using this environment, how does the document management and the other tools work within ACC. And with that, I'll kick it off to Dan Lench.

DAN LENCH: Thank you, David. In talking about document management, there was a couple of really interesting thought exercises that came to light when we are working with a group of users that are traditionally used to a server environment. Moving to the cloud reveals that the way that people have worked in the past simply doesn't work for the future, and change is hard.

The most important thing is that you're able to explain the workflow changes that the users will encounter when switching from a traditional server to a cloud solution. The Desktop Connector and ACC simply do not use some common workflows that users are used to from a Windows file and folder environment. On top of that, we've added role-based permissions to folders, and that complicates the training.

We've found that users might want to bypass these changes by saving files to a local storage, old drives on a server, a different cloud service, and that by running pilot projects with some of the technical leaders in the different departments is really key to a successful rollout in their department. They become the trusted users that can disseminate knowledge. The graph here is the emotional cycle of change I'd like to share with you.

This happens every time there's something new that a user or a person has to integrate. Everybody is very excited because they think this solution will solve all the problems. As they start to dive into it, though, they start to doubt their choice to change, and eventually they will hit the valley of despair.

Well, I would like to offer WSB's experience and along with this talk to try to help you stay above this optimism horizon and allow you and your users a success that we have recently found. Some of those workflows that I mentioned that do not translate are how xrefs and data references are managed. In a server environment, you could xref or data reference from one project folder to another with no consequences.

However, in ACC, each project is an island of data. The x references and data references must be relative to the project. Careful attention to this file management, the training materials, and mentoring is essential when sharing data across different projects. The idea that a project is an island plays into the tool that is used to connect projects together in ACC, which is called Bridge.

We found at WSB that some of these new workflows created a interesting opportunity. When moving from a server to ACC, we saw that it was a perfect time to implement the folder layout change, as David detailed, along with their role-based permissions, and an opportunity for us to look at past lessons learned for storing and sharing data within the company and externally. The Construction Cloud environment stores the files and manages permissions. The Desktop Connector allows users to select projects that will be available to them on their local design applications.

Effective practices involve only selecting projects that a user is actively working on and deselecting all projects at a maintenance interval of every month or so to allow Desktop Connector to clear out its local cache. Highlighting the importance of syncing and conflict resolution and informing users not to exit the desktop connector or log off while tasks are still pending is also key to a stable environment. At WSB, we've decided to change the default location for the Desktop Connector workspace from the logged in users local folder to a common folder location company wide, and we've called that C:/ACC. This allows all paths in the ACC environment to have a common root and eliminates issues that users may have when x referencing or data referencing.

Everything in ACC is relative to the project it belongs to. It is so important not to cross link projects and data. Things will break, I promise you. But I wanted to show that the Desktop Connector is not just a client to synchronize data. It's also a tool.

In the Help section of the Desktop Connector-- or I'm sorry, on the Gear section of the Desktop Connector is a troubleshooting tool that will go in search for issues that are preventing a project from synchronizing and a Reference Explorer, which, as you can see in the below graphic, will create a tree of how the data is spread out through a project. These two tools are invaluable when troubleshooting issues that prevent users from opening files, issues where there are circular x references or data references, or missing x references or data references.

If you hold down Shift while you click on this Gear icon, you will get an extended help menu for logs and troubleshooting in case of an instance where you need to talk to Autodesk and give them diagnostic logs. You can use the tools available in Desktop Connector and the Manage Data shortcuts tool in the Civil 3D application, along with the Reference Manager standalone application to audit, repair, and address issues such as the missing and broken references. Cleaning up and resolving these issues ensures fast load times and stable files.

A bridge in the ACC environment is something that connects internal and external projects, basically linking project islands. When I think of an ACC project, I imagine an island of data that's floating in the cloud. The bridge is the connection between these two that allows data to move across.

The individuals in the projects that have been deemed responsible will be the only ones allowed, because of permissions or roles, to share data across this bridge. Only project admins can create them, and the users-- or the receivers are the ones that dictate the method that will be used over that bridge. Shares or packages are the two main methods. Shares is used for the supporting and submittal documents as well as internal design data. Packages would be used for design files that leave the company.

So internally, x references or data references are going to be shared between projects using the share command. It's a simple click on the three dots next to a file or folder, preferably folder, because, unlike files, folders can automatically sync changes to target project. Once you share your data to another project internally, you can go through and associate that file with the working folder and publish data shortcuts for users to make a shortcut to. Doing so makes the xref or data reference relative to the project it's receiving.

When sharing data externally, the share function is valuable for use in exhibits, spec submittals, and other supporting documents. By that, I mean files that lie outside of the direct design pipeline, files that you wouldn't necessarily reference directly into your design files. Packages allows users and teams to view a timeline of data that has been shared along with the historical version of each share. There's tracking date and user, and all the teams that are connected over the bridge will receive the same data at the same time. This eliminates email attachments with design backgrounds or questions over who has what and when did they receive it.

If you are good at building bridges, you will never fall into the abyss. It has been a challenge to implement these into WSB. But through these challenges, we've been able to network with other ACC administrators at other firms.

We've been able to build our documentation that strengthens our ACC environment internally, and we've been able to share our experiences with others, as we are today. And I invite you to engage others and your Autodesk reseller, and share your friction points because they may have information that can help you and help bring the team together. And to that, I turn it over to Mike.

MATT ADAMS: Thanks, Dan, for that introduction. Now we want to come full circle into this and bring the team together in this collaborative environment. I want to start with a famous quote. "Teamwork makes the dream work," which was first coined by John C. Maxwell in his book by the same name, Teamwork Makes the Dream Work, and essentially saying that, together, we can all do the impossible. I believe this is imperative with what Autodesk has done introducing the Autodesk Construction Cloud for our teams to be able to utilize one collaborative environment and a common data environment.

Let's be honest here. Construction projects are becoming more complex, not only with design elements, but collaboration, communication, and coordination amongst all the different disciplines, different teams, subconsultants, subcontractors, et cetera. But what does that mean for us? This is why we introduced the Autodesk Construction Cloud environment for our teams at WSB.

We introduced this methodology of a single source of truth. What that means to us is a single source of truth is essentially the common data environment to be utilized. It represents the centralized storage data platform for all of our project data to be stored in one singular location. There is no ambiguity between any of the communication and coordination amongst any of the teams within the environment, and it creates that one team environment that everyone has functionality out of.

Let's take a step back for a second. Traditional server workloads, when we introduced ACC, we were talking about project data being dispersed amongst many different environments, many different servers, depending on where those product teams lived. And then we introduced multiple different communication channels, i.e. multiple phone calls, flooded inboxes trying to either utilize a Dropbox location or present data through an email, but then end up getting that mail daemon notification saying that your data in that file is too large to send over an email. Within that common data environment, we have the capabilities to share all that data. Everyone can access that shared data for all the teams in that one-stop shop location, essentially.

Now, how do we utilize all these tools? Well, when we start implementing collaboration amongst all of our teams and communication, we start really leveraging the tools and functionalities within the ACC environment, and the first tool that comes to mind is markups. Having the ability to mark up immediate, real-time feedback necessary to tackle the problems at hand and early on design phases was crucial for our team. So once we implemented and went full in for all of our projects, all of our design projects, we wanted to be able to implement the capabilities of markups within the environment for all our teams.

Now, as many of you know, there's two versions of markups. There's an unpublished version. By default, they are unpublished, or you can have a published markup as well.

One of the key factors that we thought were a good key success to implementing markups, unpublished markups within our team environment, because it basically gave our designers and our technicians the ability to take pride in a sense of ownership and accountability of their own work by implementing self-check. That was part of our quality management QATC process that we implemented within the teams, to be able to have the ability to see a drawing within the ACC viewer or a PDF document within the ACC viewer before we even get to the point of milestone review checks or interdisciplinary review checks, or even engineer project manager review checks for that matter. It created that sense of ownership, like I mentioned, and accountability.

And that kind of takes us into the next step in evolution, I would say, within the environment, which is creating issues. Now, creating issues was a huge factor for us on our team moving forward with this environment, as we saw, because with the capabilities of issues, it does hold those individuals accountable for some of those design efforts being produced. Some of the design efforts I mentioned, so we can track issues throughout the entire project lifecycle.

We have that history capability. We have a log capability of all those issues being created, whether they get checked off, signed up, or more communication and collaboration needs to happen amongst those issues. That was a key factor for us implementing issues on all of our projects, projects moving forward.

Another portion of issues that we wanted to incorporate was the design technology team started creating issues from a standards adherence perspective. So as you saw on David's screen earlier, that mentioned the holding area and our naming standard templates, well, we started doing audits on our project within the environment. And that gave us a capability to create those issues of standard adherence, saying the naming convention doesn't follow ours. We need to fix that. And the best part about that is that we can directly contact that person by creating that issue and assigning it to them to make sure that they are fully aware and fully capable of making that correction.

The other factor that issues brings to us is the ability to mark up our 3D models. And this was a big factor as we start moving away from the PDF plan set and kind of into that full model delivery basis on all of our projects moving forward. What does that mean for our teams? Well, with the, like I mentioned before, the trackability and holding accountability for these issues, we can create the issues on those 3D models. And then to even take it a next step further, we started implementing that model coordination in a collaborative workflow environment.

Now, when we speak about the model coordination, there are three factors to keep in mind with this environment. First of all, under the Model Coordination tab, you either need to have a BIM Collaborate Pro license or BIM Collaborate license or a Build license. You will not be able to function off of just a pure Doc license.

The other factor of this is when we set up the model coordination space, you have to be very cognizant of where that space will live, necessarily, within the ACC environment, within that project environment. So when we go through that model coordination space, we set up the folder, as you saw on David's green again mentioned earlier, kind of following that corporate standard directory structure that we put in place, under that O5 discipline folder. Since that O5 Discipline folder is where majority of our design and our work lives, and it is broken out by department or by discipline, for that matter.

And so once we were able to set the model coordination workspace to that specific file location, we were able to manually select the individual files that were needed and necessary to be able to fully utilize the capabilities of that model coordination, one of those capabilities being automated workflows of clash detection. And so, for example, we can pull those base files that we have on our drawings from any of our civil design drawings, architectural models, biological models, or any other models, for that matter, that we're working with, pull all those into that one collaborative workspace, and be able to run automated clash detection.

The next step in the process that we implemented at WSB as part of our standard operating procedure of workflows was the federated model. Now, the federated model, essentially, is that holistic view representation of the model of design-specific models into one common file format. This allows multiple people to be able to view the model, to see it kind of holistically in that view, from a perspective that allows clients, their owners to be able to see the model where they don't have to be bogged down by the nuts and bolts of the design and kind of see it holistically for what they are expecting or what their vision is necessarily for that particular site development. So we saw this as a key thing from not even just the Autodesk side, but also on our Bentley side of the house as well, to create that federated working model for all of our design teams across the board.

And that kind of moves us into more functionalities within the ACC environment, which is continuous improvement through your data. So we all have access to the insight page within the environment. The Insight page pulls that data metric. You can pull all of your issue metrics, your issue logs, your project [INAUDIBLE] logs, your submittals, your design packages, all of that can be pulled within that Insight page under your dashboard, kind of as a, again, one-stop shop location for, say, a project manager to go into that project and see all the project data metrics and project details that they need to investigate further if they have to.

The other portion of that, what we implemented on our end, was we ended up linking our federated model, as mentioned before, into this project dashboard on the Insights page. So this gave, again, that holistic view, federated model view within the dashboard in that one-stop shop location where our product managers can go look at the model. As you can see in this image here, we have our issues created. You can see the two orange dots being the issues created on that federated model, so if they need to investigate further, they have access and ability to open those files if necessary. And then they can kind of cross-reference between the root issue causes and the issue log within that environment as well.

And so to recap, for WSB's perspective, we wanted to implement this process of a evolution, necessarily, within the ACC environment, starting with markups, which allowed our teams to communicate and make updates to changes that were necessary or also introduce those self-checks. And then that next evolution stepped up into the issues creation tools, where we can mark up on 2D, 3D models. We can assign issues. We can track and log all of that data from those issue logs.

Moving into that model coordination aspect, when we start talking about 3D model collaboration and coordination, where we have multiple different disciplines and designs needing to collaborate in one common environment. And then being able to pull all of that product data into a one location for all team members to be able to access. So this is our process and the steps that we took this past year while implementing ACC from server.

As we continue these efforts, there will be a lot more tools available to us. For example. I know, under the Build licensing or a BIM Collaborate Pro licensing, we have the Correspondence section, which the Correspondence section will allow us to attach and process email correspondences, for example, all within that one-stop shop location, in that single source of truth common data environment, under the project, so it's specific to that project and it's not just flooding everybody else's email inboxes. So as we continue to grow and as we continue to progress forward, these are some of the steps that we have taken for our teams at WSB.