Description
Key Learnings
- Learn about setting up civil projects in the Autodesk Construction Cloud, including folder structure, data shortcuts, and Desktop Connector.
- Learn about cloud collaboration, and the setting up of bridges between designers and client.
- Learn about meeting management and issues handling, as well as the sheet set manager and the review process.
Speakers
- PFPéter FarkasPeter holds a masters degree in Civil Engineering and has over 15 years of design experience. He enjoys trying new workflows and taking on challenging tasks so he has worked on roads, earthworks, pressure and gravity pipes, geothermal and airport projects and 3d project visualization. Apart from Civil 3d and Infraworks being his strong suit, he enjoys finding new ways to make work easier with dynamic blocks, dynamo and recently C#.
- RCRagnar Steinn ClausenRagnar is a Project Manager and Airport Designer at Verkís Consulting Engineers out of Iceland. Ragnar holds a M.Sc in Civil Engineering and as an airplane enthusiast has had the honor of working in the field of airport infrastructure design for the past 10 years. Ragnars career started as a designer but quickly evolved into project management for civil infrastructure and airport projects. Ragnar interests are in the field of delivering projects which provide a positive impact on society through engineering. By executing projects in a structured and organized way, as streamlined as possible, with open communications and active collaboration so all team members feel valued is a key for success, a key to keep costs down and critical to avoid scope creep. With a constant desire for more knowledge, Ragnar has an ever growing drive towards finding and developing a more streamlined version of yesterdays design and solutions. Whether that is through Civil 3D, Generative Design, AI, Quantity Takeoffs, Collaboration Platforms like ACC, minimizing disruptions and or clashes during construction, no stone is left unturned and Ragnar believes there are always opportunities to learn and improve.
- JTJames TuiteJames Tuite is a Solution Engineer at Autodesk based out of London. With a background as a Civil Engineer, James has expertise in Geotechnical and Temporary works design. James specialises in Infrastructure Design at Autodesk covering various products such as Infraworks, Civil 3D, Recap, ect. If you have any Autodesk related questions feel free to reach out.
PETER FARKAS: Hello, everyone. Welcome to our presentation, Revolutionize Your Civil Projects, an ACC Blueprint for Effective Civil 3D Collaboration. Safe harbor statement. Please do not make any purchasing decisions on any forward-looking content, as this is subject to change.
So let's dive into it. Firstly, let us introduce ourselves. My name is Peter. I'm a civil engineer, mainly working as a designer and have worked in various civil fields. For the past several years. I've mostly been working with Ragnar on various airport projects.
RAGNAR STEINN CLAUSEN: Thank you, Peter. My name is Ragnar Steinn Clausen. I'm a civil engineer and an airport planning specialist here at Verkis. And for the past five years, I've been a project manager for various airport projects in Iceland and have continued to work with Peter to develop our Civil 3D workflow internally at Verkis.
JAMES TUITE: And my name is James Tuite. My work is a solution engineer at Autodesk based out of London. And before joining Autodesk, I worked as a civil engineer, as a temporary works designer.
RAGNAR STEINN CLAUSEN: So as we mentioned before, me and Peter, we work at a company called Verkis in Iceland. So Verkis history dates back to almost a century, making it the oldest engineering consultancy here in Iceland.
Verkis was established by a merger of five companies. We have our headquarters in the capital of Iceland, Reykjavik. We also have several branch offices around Iceland and a handful of branch offices worldwide, with the largest one in Oslo, Norway.
So just a quick look of our project portfolio, we are a multidisciplinary engineering company. We have all major engineering disciplines represented at our company, and here are just a few of our examples of our project from the infrastructure portfolio, so more specifically from the airport marine and highway divisions. As you can see, we have had protests from all over the world. Most often, these protests are related to energy industry, hydro or geothermal, but not exclusively.
So enough about ourselves and let's dive in. Before we do so, here are some ground rules that would be good to keep in mind. The goal of this seminar is to explain concepts and workflows that we develop and use at Verkis. This presentation should help you get started in the ACC, and we'll try to focus on the topics we struggled with initially.
However, there are many ways to skin a cat. What we are showing today is our approach to the ACC Here at Verkis. You should tweak the processes to really best fit your project needs. The presentation is only roughly one hour. We cannot fit all details in the presentation, so make sure to check out the handouts for details.
PETER FARKAS: First, we're going to go over where we started and how we got where we are today. Then we'll go over our current workflow. We'll continue with project management on ACC, and in the end we'll briefly cover some ideas that we're looking into exploring in the future.
RAGNAR STEINN CLAUSEN: Thank you, Peter. OK, so we get started. For the past decade, we've been working on our local server, providing our designs the traditional way. However, in recent years, we've been working with a local/BIM 360 hybrid model, where we execute the design locally but upload our models for coordination on BIM 360.
All of our document management is operated via our internal system and on a separate platform, working in bigger projects and where the team is compiled of branch offices and partners. This way of work has proved to be not really efficient. Also, after COVID-19, more people started working from home, which required VPN connections to connect to our internal systems.
All of the above caused problems in bigger projects, risk for multiple versions of files flying around, stress within the team, and it really required a lot of housekeeping to keep the oversight. This led to our ACC pilot project where we developed the workflow we will present today.
Here, you can see a diagram of what I described earlier. It's quite complicated. So we work on our own working server. The common workflow is a local BIM 360 hybrid model. The design is executed locally. Clean models are uploaded to BIM 360 for coordination. Documents, reports received from partners via teams move to our internal document management system, files being received via email teams, et cetera, et cetera.
The long story short, this is a lot of platforms our team members have to study and understand. So over to our new workflow. What did we want to do to change? So the previous workflow was causing some concern. It was overly complicated, and we were really spending a lot of hours on housekeeping.
The solution we decided to go with was to migrate the whole project process over to ACC. We really wanted to go all in and create something we refer to as the project bubble. What we mean by this is that our ACC site became the single source of truth for all files-- design files, et cetera-- used for project delivery.
Above all else, the main goal is to simplify the process. We believe that will lead to a more efficient work and less stress within the team. With fewer platforms to study, we can focus more on the design and solutions and less on the complications with document and file management. So the results from this new workflow, even though many hours went into creating it, are, for example, revisions during constructions were down by 20% to 60% compared to previous projects.
So to begin with, what do we want to do? We looked at three options. They are all compliant with the ISO19650 BIM standard. The first one, the first option was where everybody works on the same ACC side. Second one was to work on our own ACC side, create a bridge to deliver documents and files over to the client's ACC side. And finally, the third one was to work from the client ACC and bridge back home for backup purposes for our model and drawing files.
We preferred option 2, work from our own ACC due to many reasons, but few of them are we want to control over our data. We want to control the access so we can efficiently add members if external support is needed. We want less overall access restrictions. We want to have everything on our ACC-- sketches, draft reports, calculations, a lot of things that aren't necessarily being sent to our client. And our team can learn this one workflow and not everybody needs to know other's processes. We bridge our documents as needed per project.
This ISO standard also mentioned that work-in-progress areas should not be accessible or visible to anyone other than the team itself. It's an example. You can see a graphic from the ISO standard, where it shows an example of how this could be set up. Here, we can imagine the client ACC is marked with an A, and it is in the center of it all. As the designer being a discipline or company, we could be bubble B. The data exchange or bridge is then the arrow that moves from A to B or vice versa.
So to summarize, this really became our ideal setup. This became our vision. We strive to work only on our own ACC, clients, on theirs. We deliver as much as possible through bridges. Client delivers to us through bridges. Collaboration is on one central ACC. We work directly off the cloud, ace through the desktop connector, and ACC Build is only used at the construction stage.
We would also prefer that our PM, BIM-CO RE would have access to the client side. A big portion of the team does not have to jump between ACC sites with the related confusion. Spoiler alert. This didn't quite work out as we wanted, but we'll explain that later as to why. So now, I'm going to pass the ball back over to my colleague, Peter.
PETER FARKAS: Thank you. So we're going to take a walk through with you through our work process. We'll start with how we set up our models and drawings. Then we'll go over how we share models for coordination and what views we always set up. After that, we will look at our review process. And finally, we will cover some points around project delivery.
So let's start with models and drawings and go over how we set up our folder and file structures and why. It's important to us to create a project bubble and capture anything and everything that is project related on one central location. Set up our folders 1 to 4 according to ISO19650, and created the rest of the folder structure so we could store all our project-related documents also on ACC. Some examples of files stored in these other folders are reference documentations from past projects, project reports, specifications, cost estimates, site photos, or anything that could be produced during the project.
So as I mentioned before, our first four folders are set up according to the ISO standard. The first folder, the work-in-progress folder, is where we were all live modeling or CAD work is carried out, where are model information is delivered developed. One of the reasons we prefer to work on our ACC is that we agree with the ISO standard that we should be able to own and control our own work area. Others outside of our company don't need to see it or access it. This is easiest to achieve by having our work-in-progress folder in our own ACC.
The second folder is the shared folder where all coordination and motor-related data exchange takes place. No work is done here. This is purely a coordination sharing space. There is a process in place to move files between folder 1 and 2, which we will cover later.
The third folder is the published folder. This is where our end products at the end of each design phase end up and gets shared with our client. The fourth archive folder is where we should house an audit trail according to the ISO standard. With the ACC keeping track of all file activity, this folder has become somewhat redundant and wasn't used.
For future projects, we see this folder as a place for archiving project files in case a project gets paused for some time and possibly continue years later with changed requirements. But in each team, inside the work-in-progress folder, we organize our files into three categories.
We have our design files that have only objects in model space in the root, because these are open most often. We have a subfolder for what we call our clean or coordination files. These are usually empty files with our designs, either data source started in or 3D solids copied to them. These are the ones we share to folder number 2 and are used for model coordination and clash detection. Strip any information out of these files that could make the coordination view crowded like text, labels, profile views, anything that is not 3D or down on zero elevation.
Our other subfolders for the third category, which is our drawing files that contain only xrefs, shortcuts, and are drawings and layouts. We found this folder structure to be easy to work with, and finding what you needed was simple and quick.
So I mentioned earlier that we use ACC for all our documents as well. We have folders where we keep our PDF drawings, bill of quantities, cost estimates, reports, and so on. This way you can take advantage of the fact that within the ACC, you can directly view and edit a lot of file types online.
In addition to this, you have a file history where you can see who edited what and when. You can also revert back to previous file versions at any time without IT help. Once this information is stored in the ACC, we can also reference, these talks within issues, meetings, or RFIs.
Once you have your folder set up, the next step is to give people access to these folders. There are two main directions to go with this, high trust or low trust, but a hybrid approach is also possible. High trust is basically, when everybody has access to everything. We like to have high trust, especially within our own organization. One of the main reasons for this is because it is much easier to set up and maintain. This might not suit if you have sensitive information that you want to protect and access control of.
Low trust is when you access control and people only have access to certain folders. You should use this if there are several companies working together and you have data that you don't want to share. This definitely is a more difficult process to set up and needs to be well thought out, who should have what sort of access to what. This also creates more administration when folders or new people are added to the project.
Once you have your folder set up in the cloud, the Desktop Connector allows you to work on your files effectively. Other than a few kinks here and there, we had no major issues with Desktop Connector. We found it really simple working with it, and we had no issues. I'll pass over to James, who will cover this topic in more detail.
JAMES TUITE: Thanks, Peter. So now, we have our work area set up on the cloud, we need Desktop Connector to access that data locally on our machine. Desktop Connector allows you to work with your cloud data by temporarily caching it onto your local machine. It manages the complex reference structure of large, Civil 3D projects, allowing different designers to collaborate as if on a local area network.
Desktop Connector will lock files being accessed on the cloud, maintaining clarity in design teams. When a change is made to a file accessed locally, Desktop Connector will upload this new version to the cloud. As a result, this is integral to the collaboration for Civil 3D workflow.
Next slide. So as mentioned before, Desktop Connector synchronizes files between your local drive and the ACC cloud. Once you choose the projects you want to sync locally with the Desktop Connector, you'll be able to access everything in Docs available in File Explorer. You can see in the free screenshots how you can access the same files and folder structure on the ACC, your File Explorer and the Civil 3D start screen.
Locking of files that I mentioned earlier, you can see with all three images how one of the files is locked and it's in use by someone. Now that these files are synchronized to your computer, you can also use all of the File Explorer commands. You can copy, paste, or zip anything. You can also upload files by just copying and pasting them from one folder to the other.
One issue that Verkis noticed was when using ISO196050 naming standards, the Description field you see in the ACC screenshot does not carry over with the file, neither to the File Explorer or to the Civil 3D start screen. So when you're searching for a file, these codes don't help you find what you're looking for.
Building on this further, the Desktop Connector has a dedicated reference explorer, which allows users to visualize all reference files in a data set, as well as see the relationship between these files. You can use this view information before uploading to the cloud to clearly identify missing references or broken links. This comes with various graphical views to visualize these sometimes complicated file structures. This is a great way to use as a pre-check before adding data to the cloud.
The DWG Migration Tool for Docs. So with Desktop Connector version 16 and beyond, we can further use the DWG Migration Tool to move DWGs into the ACC. This can be seen as a way to push multiple DWGs to the cloud safely. This isn't something that Verkis have used yet, but it's definitely on their radar for future projects.
The DWG Migration tool checks for the following. It performs data integrity checks; indicates fixes, including re-pathing broken references and reference files stored outside of that migration set; notifying you about long paths, circular references or any unsupported files in the upload set.
To summarize how this would work and what workflow you would use using the tool, you can select Files to upload set. You would then check for any data integrity issues. You would fix any locally detected errors, things like long file paths or unsupported file types. You could export an issue list as a CSV file to check as well, and then you would upload these files again and review the migration summary. This tool is available to download at the Autodesk App Store.
Finally, I just wanted to give a couple tips around some mistakes I see people use when using the desktop connector. So the first thing I would say is definitely check out the Desktop Connector Help Guide. It contains information on nearly everything you need to use and around the tool. This includes guides for installation and upgrading the tool.
Another point is the Desktop Connector is designed for file management, but not for bulk migration. There's other tools like the Autodesk Replication Tool, otherwise known as ART, that are a better fit currently for bulk migrations. Another point is, once on version 16 of the Desktop Connector, you do not need to uninstall to upgrade the tool. An upgrade with the Desktop Connector keeps your local cache connected, while installing the tool requires the local cache to be cleaned up, and this can lead to what we call a bad environment error.
And then finally, I would always start with the troubleshooting tool when you come into issues with Desktop Connector, as it informs you and fixes any sync issues you have with the tool. Now, I'll pass back to Peter.
PETER FARKAS: Thank you. We work with Civil 3D, so data shortcuts are essential in any civil workflow. This requires a BIM Collaborate Pro license. Based on our experience, everything worked very smoothly, exactly the same as when we had our shortcuts on our own servers or when working locally.
And this is by design. Managing data shortcuts to a user on the cloud should feel the same as if working locally. Sometimes sharing shortcuts across projects can cause issues. We at Verkis share the DWGs, and other companies we work with create their own shortcuts from those files as needed. That way we had no issues.
Autodesk recommends having your data shortcuts folder in the root to make sure you don't have any long path issues. In our project, we had our data shortcuts deep in a subfolder and had no issues. From now on, we will have both our data shortcuts and our sheet SAT files under work in progress. That way, all CAD-related work will be stored under work in progress.
We used to use Sheet Set Manager at work, Verkis, many years ago. I think few people understood it then, and it wasn't possible to integrate it into our old document management system. So it disappeared. But now, we have rediscovered the tool set, and this time, it's here to stay.
You have to do some upfront work configuring your drawing frame, but you don't need to do it for every project. This content can be reused. The title block attributes connect to Sheet Set Manager through fields, as default attribute values. You can have project-level attributes like project number or project name and sheet-level attributes like scale revision, number, designer, and so on.
Now, that Sheet Set Manager is web based. You can have multiple people working on the sheet set database at the same time. With the global attributes, for example, you can change the project name on 100 drawings without opening them in no time.
Another nice feature is that you can execute plot orders on the cloud, and your drawing sets get published to the ACC in the background while you keep working. I also got excited when I saw that you can manipulate Sheet Set Manager with Dynamo, so we are exploring our options with that as well.
ACC has an inbuilt ISO19650 naming standard set up out of the box. Can create your own standard from scratch or customize the ISO standard. This is what we did to follow our clients' needs. You can even export the standard you use to Excel and use elsewhere.
You can choose which folders have naming standards enforced on them and their folder icon changes. In our case, we had strong requirements for our drawings, so we set this up on those folders, but only on those. We didn't want to risk naming standards becoming hindrance on our DWGs.
Any file that ends up in a naming standards enforced folder that does not follow the rule ends up in a holding area until the naming is fixed. Document control has easy oversight over the holding area because it is marked clearly.
The big advantage we see with having every project file on ACC is that you can view all your model and drawing files' documents online. The ACC Viewer supports a wide variety of file types. Certain documents can even be edited online. All of this happens in your browser. You don't need to have software installed.
ACC keeps all of the file versions, and you can even compare two versions side by side. We noticed, however, that in the ACC Viewer layout of taking plot styles into account, and that gray shades in PDFs might look different than in PDF viewers. So when looking at documents, you have to take these into consideration. I think it would be beneficial if the viewer would take plot styles into account. I'll pass back to Ragnar.
RAGNAR STEINN CLAUSEN: Thank you very much, guys. It's a lot. So we've gone through the grass root here, the models and drawing process, really, where the majority of the design takes place. But we're moving up the ladder, so now, we're going to look at the design collaboration and model coordination.
All right. So our project has started taking form. Just as a reminder, we set up our Work in Progress and Shared folder to have the same folders that represent our teams. You could skip creating the folders in the shared folder because they also get created automatically, but we prefer to have them saved in our template project so nobody would feel tempted to create the folders.
So let's see how a team is set up using Design Collaboration. So for this demonstration, we're going to use a demo project. Let's say that for this example, we have set up our project according to our project template. However, we need to set up a team for landscaping. How do we do this? We go into the Design Collaboration tab. From there, we go to Settings, and we can click on the Select Existing folder. There you can choose the Work in Progress folder, and ACC we'll set up a team for you.
From here, you can choose to retrieve this folder to another project by clicking on the Bridge Team Automation column, but we'll cover that in more detail later. Now, note that because our template had already generated the shared folder for 06, landscaping ACC does not replace that folder with another copy, it simply uses it. Now, finally, in Docs under the Work in Progress folder, you can see that 06 landscaping has generated its Consume folder. This means that you are up and ready to start design and model coordination.
Now, that we have our team set up, we need to make sure our bridge is set up with the receiving ACC side. This is done by going into the Bridge section under the Design Collaboration Module. By clicking on a Bridge to a Project, you will be sending a bridge invitation to the other ACC admin. And once the connection is approved, you can create all the bridges you need.
But how does that really work? So let's find that out. So having both our teams and bridge established, our next step is to move into the Design Collaboration space to share a model package. Creating and sharing a model package is done via the Swimlanes, under the Design Collaboration tab. But before we go there, let's see how this really functions.
When a package has been created, it's really copied from your Work in Progress folder over to the shared space as seen here on Note 1. When another discipline chooses to consume your shared model, ACC copies that model from the shared space over to a Consumed folder within the other disciplines' Work in Progress space. See Note 2.
All models you consume from other disciplines will end up in your Consume folder. Note that this is only needed if you do not have direct access to the models. We prefer to set up a live working environment within our company. So that multiple disciplines within the same company have live access to each other's models or for more efficient collaboration.
Now, let's discuss what is a bridge and how it works. So we begin by looking at the host ACC side. Down on the right side of each team ribbon, there's a small indicator that tells if the team is bridged or not. Over on the receiving end, the same team appears with the same indicator.
This means that every time the team on the host ACC side shares a package via the Design Collaboration, the package will be sent over the bridge and will appear in the Design Collaboration stream lane at the receiving end only minutes later. So what you see on the screen here with the arrows in between labeled bridge, this is really what we call a bridge, or we refer to internally also as a Design Collaboration bridge.
But what files to share? That's often the question. It really depends on the project. But really, we only want to share our clean models via the Design Collaboration. And why? Because those files are meant to be used by others for coordination purposes.
Work in Progress files and Sheet files are rarely used by other teams. If the client wants to have access to all files at all time, an automatic Docs bridge can be established between the bridge projects. This gives the client access to Work in Progress and Sheet files, and it's really, also beneficial for showing project progress and/or for backup purposes. It's also worth noting that this bridge type is also used to deliver documents to client review and when documents, models, files, et cetera, are published.
So when setting up, we generally go through seven steps when creating a live bridge, which, ultimately, ends up with activating the bridge between sites. Now, note, only documents, model files in the folder is shared. Subfolders or files inside subfolders are not synced. They need their own bridge.
So moving on, we're going to be looking at our model coordination, and how we set it up is that we generally just use three set of standard views. So to create a holistic view of the project, these are our existing conditions model, you can see here; our interdisciplinary model; and then our third one is the project interface model.
So this is an implementation of the standard R1110-- sorry about that, let me go back-- model [? grundlag, ?] which is a Norwegian standard. The existing condition model is a view which gathers all of the existing models that have been constructed into a single view or a model.
The interdisciplinary model is a view which gathers all of the disciplines, models together, and the project interface finally permits the new construction against existing. So each view will allow for class analysis with focus on either interdisciplinary classes or project classes with existing facilities or infrastructure.
These three views will generally allow the whole project to be planned and integrated into the site. There's also the option of adding the fourth view at the end of the project. This would be the earthworks and excavation used for machine controls, which is becoming more popular in civil works and sometimes requires these models from the engineer. The earthwork model is often utilized in the beginning of the contract works and beneficial for the contractor to visualize all excavations in the project.
So let's dig a little deeper. We're going to look at our project interface model. So these are only using, as you see on the image here, we're only using the clean version of our model files as construction lines help lines, xrefs would just crowd our coordination view. So these are usually empty files with one data shortcut or bunch of 3D solids or even have 2D geometry that can be beneficial if it's lifted up to be around the right height and not in the zero elevation.
We use this part of our project to experiment with the asset information provided with our deliverables. We added a lot of attributes to our objects with dynamic blocks and using Dynamo scripts. Here you can see an example of a manhole with setting up coordinates, rotation, elevation information, what HL transformers are inserted, what HL lights are connected to it, and what size it is, and so on.
This really was a test, and we wanted to see if our client can use this added information during operations and to see if this helps during construction. We can confirm now because the project is in the closing stages of construction and has been commissioned that during our construction support period, this has proven to be very useful. We see and feel the increased efficiency and improved communication with on-site crew when RFIs are raised on site or if issues are flagged. We are much quicker, on the same page, and we have often been able to solve issues relatively quickly together with everything locked on ACC.
Now, back to you, Peter.
PETER FARKAS: Yes. So let's see the workflow we used for quality control. We use the Inbuilt Review feature for our review and approval workflows. When set up many different types of reviews, one step, multiple step, multiple step group reviews, and so on, but we mostly use the one and two-step approvals.
You can customize what statuses you want your workflow to have, and reviews can be set up to move files with or without markups once approved. We utilize this behavior to approve file movement to bridged folders. That way, everything that is automatically bridged to our client is first reviewed.
We use this same principle to quality check all our documents and model files. Due to this, all our document folders have similar folder setups. We have folders that accommodate Work in Progress files, internal review, external review, and publish docs. In our project, we use markups to comment during review, but we are exploring using issues or normal PDF comments from an editor.
So let's see how that looks. In our review, our first step is an individual step. When done, we move files into the internal review. Our second approval workflow is the internal review. We loop between 1 and 2 until everything is approved.
The third approval workflow is for a project manager to approve moving files to our client for external review. After the external review, we do step 1 and 2 again and deliver our files with our fourth review workflow.
Now, let's break that down and look a bit into the details of how we plan this would work. Our first step is an individual step, check. Once the drawing owner is satisfied with what they have in work in progress and that individual check has been done, the files are moved to internal review. And there, we use the first approval workflow.
This could also be copied, but we wanted to record this step with approval. Here, we initiate our internal review. Once reviewed, we do a loop back on files that got rejected and approved with comments. We attend to anything that needs to be fixed or changed, and then the internal review process is repeated until approved.
Once our files are approved, we initiate the third approval workflow that moves the files into the Bridge directory and the files automatically move to our client for external review through a bridge. There, are client does the review process. Both the review and the one in step 2 can also be initiated by a new feature that can automatically send files into review called Review Auto Trigger.
After that review is done, we wanted their review to move files with markups to the next folder upon approval with comments, and we wanted to automatically bridge that folder back to us so we could work only on our own ACC. That didn't work. Markups and issues don't bridge, so we ended up having to process the external reviews on the client ACC.
This process, however, could have worked if commenting had been done with PDF comments, instead of markups. When we have fixed everything, we do move files again into internal review with an approval like in step 1. We do our internal review loop like in step 2.
And when everything is ready and approved, we then initiate a final and fourth approval workflow. That process is only for the project manager to provide a formal approval for the delivery. The files are moved by the process to the bridge folder, and the files get automatically delivered. This is how our process looked like.
Since things didn't work out as we planned, we're exploring how to modify the process in the future. We can imagine using an external PDF editor for adding comments, because that way, the comments would always bridge, and that would mean that our original setup would actually work. But we will experiment and other than trying PDF comments, we will also try using a combination of issues and markups because they are well trackable.
We end up using issues and markups. Since issues and markups don't bridge, the bridge from the external review back to us is not needed. But if that bridge disappears, the folders that facilitate this movement are also not needed. And in the end, the external review can also be set up not to move the files. And this is how our process would be modified if we would use issues and markups.
Here, I wanted to summarize the different options available for reviews in the ACC and highlight the main points. So the best things about markups is that they are easily visible in Docs, both on the drawings, you can see all markups at the same time, and in Docs, there is an icon that shows if the file has markups.
It's also great that you can move markups with the review process if you choose to. The things that I miss most in markups are that they don't bridge and that you neither can assign markups to people, nor can you add comments to markups. Not being able to report on them is also negative.
The best things about issues are being able to categorize them, assign them to people, and being able to have a discussion ongoing with comments within the issue and you can report on the progress of them being closed. The downside of issues are that they don't bridge. File attributes, also don't show if drawing has issues or not.
The third option we are considering is the PDF editor. The best thing about using PDF comments is that they get embedded into a certain version of your file. While an issue or markup might hang on the drawing if forgotten, PDF comments are part of the given version, and that also means that they bridge with the file.
The main things that are against PDF editors are that they leave no footprint on ACC and that you can't assign them to people, and reporting on them is very possible, is a manual process and is an extra task. So in my opinion, there is no clear winner. If I could, I would pick and choose the best things from all three, but I think at this point you have to accept that each have their strengths and weaknesses.
Our plan is to test the markup issue hybrid on one project and a PDF editor version on another and see how they work. Now, back to Ragnar.
RAGNAR STEINN CLAUSEN: Thank you again, Peter. So we are now moving into the project delivery phase. So let's do a couple of slides on that. So as discussed before, when all documents and plans are ready, a review process is utilized to facilitate movement of files. And for the sake of tracking over the public folder, the BIM or BIM-CO or PM can then send a transmittal on the receiving end notifying stakeholders of the delivery package.
This can be scaled and new public folders created for each stage delivery-- concept design, design, development, technical design, et cetera. And the final deliverables for each stage is then always available under the corresponding folder. So this means we are in a happy place, and we have delivered our project.
Now, a few slides on the PM side here is that we wanted to briefly mention that during design, we deliberately opted to not use ACC Built. The only feature we really wanted from Built during design was the RFI feature. So we solved that by creating a custom issue type for RFIs, and that, actually, worked very well during our project.
Overall, it was a great success to operate the project on ACC, and we are really excited to evolve this further in our upcoming projects. So to keep in mind that this was just our pilot project, a lot of hours spent developing this, but however, we notice that with this project, our cost for construction support per meter of the infrastructure was cut by 15% compared to our two previous projects, and design changes during construction were limited to only two, which generally is very, very low.
We held all of our meetings on ACC, and we had take care of the minutes. Assigning tasks in the minutes was handy way of keeping track of open tasks. Instead of having a decision log in the project, we did experiment having a decision topic in our meetings. So this meant that our task list, ACC would automatically display all of these decisions made in the project. These were date stamped, so did actually come in very handy.
Also, it was very handy to be able to reference files, issues, and more in the minutes. And for emails and notifications, it was very good and very handy to use the Correspondence feature, sending emails to the whole team. And finally, I mean, as a pilot project, a lot of effort really went into the development of this all.
And when teaching the designers, the inspectors, the contractors, the client how to operate on ACC, this was a lot of effort with our first project and even a lot more effort than we really anticipated. So for future project, we really need to consider this as ACC onboarding as part of the project and an important part.
So now, you've seen that you can have processes for everything, and you can control and have access control for everything and everyone. And you can organize things with attributes and custom types in many, many ways. However, what does the project need to be in size or scale to be fit for ACC so it's worth it?
In reality, no project is too small for ACC. It's a natural fit for us here at Verkis. We design our project in Civil 3D and when this project template and workflow we have set, we are very quick up and running with a new project. Of course, things have to be planned in the beginning and depending on some size, some features are not good and some are needed, some are not needed. That's just the natural phase of starting up a new project. But the bottom line is here. We believe in ACC, and we believe that ACC can add value to any size of a project.
So generally, this quote became our mantra these days, and has been used frequently between me and Peter. "Perfection is achieved, not when there's nothing more to add, but really, when there's nothing left to take away." So what we want you to take away from that is to be careful not to overcomplicate things. These tools are supposed to help achieve results, but they can also cause complications.
Think about what is necessary and creates a real value in the project and what is not, because it can save you some time. Me and Peter here we are a very good team here with Verkis to doing this, as I am our project manager and he is our technical lead on this. So he wants to keep things very simple, but I want to have them organized and trackable. So generally, we find the middle ground between us, and that's a sweet spot that we want to be in.
So I'm going to pass the ball over to James to wrap up our presentation, and he's going to take us through our next steps with this.
JAMES TUITE: Thanks, Ragnar. So looking forwards at these next steps. We've really only hit the tip of the iceberg when it comes to features and functionality of an ACC stored project. And I just wanted to cover some topics that we would look into next for our discussions.
The first being increasing asset information for model coordination. As you saw earlier, works have gone through a process of populating objects with detailed asset information. It's an ongoing process here to evaluate if this information is valuable for the construction process and for operations going forwards. If it is, indeed, useful, we can look into utilizing tools like the Standardized Data tool for Civil 3D to bring efficiencies to this process.
Looking at multidisciplinary projects, currently the work done with Vasavi and Verkis is purely been done on their two ACC environments. In future projects, we want to look at how to accommodate a third party and how would this be done.
Automation. So Peter mentioned earlier that he'd like to automate some processes in the ACC, specifically around the Sheet Set Manager. We can look into automating processes in the ACC with Autodesk Platform Services, ACC Connect, or Dynamo.
And then review workflows. As you've seen before, there's multiple different options when it comes to review workflows, all with benefits and drawbacks. With the ACC constantly evolving, this will be something we need to further evaluate going forwards.
And then issue dashboards. So if issues are, indeed, the way forwards in selected process, then we can look into various dashboards and reports that can be generated with issues on the ACC. Users can see issues on their home page and get a list of a report of everything that needs to be carried out by themselves.
The Reference Explorer on the DWG migration tool. So as shown earlier, there's multiple tools available to check and manage data before being uploaded to the ACC.
The Review Auto Trigger function. So Peter mentioned earlier, the ability to set up an automatic review process. This is something that could be potentially set up in Verkis' folder structure going forwards, so it would automate the review process.
And then finally, the Local Save app. So this is a tool that allows users to make local saves of files before making the cloud save, thus, reducing the total number of versions of the DWG saved on the ACC. And with that, that's the end of our presentation. So thanks for watching.
Downloads
Tags
Product | |
Industries | |
Topics |