Creating Connected Ecosystems in Autodesk Construction Cloud to Manage Multiproject Frameworks

DEPAK ANANDABATMANADIN: Hi, everyone. Thanks for joining this call. We'll be talking today in terms of how we created a connected ecosystem in Autodesk Construction Cloud to manage multiple project frameworks. So myself, Depak Anandabatmanadin, service lead for information management, and I am accompanied with Harikrishnan A K, who is a service lead for 5D.

A quick introduction about ourself, I'm an information manager, with a decade of experience in BIM and information management, working across multiple large scale frameworks, and also working on different regions. I'm a civil engineer by background, and I've done my master's in construction management. This is the first time I'm speaking in Autodesk University. And my area of focus are information management, standardization, data driven design delivery, process improvement, change management. Now I'll ask Hari to introduce himself.

HARIKRISHNAN A K: Thank you, Depak. I'm Harikrishnan. So I'm also a first-time speaker in Autodesk University. I've been with AtkinsRéalis for about four years now. My current role is playing a service lead for 5D and Information Management Analytics. So I have around 10 years of experience in the AEC Industry across various VDC services and practices, across multiple regions in the globe.

I'm a civil engineer by background, but I've done my master's in construction management. And my key areas of focus is trying to drive change through thought leadership, and data is something that I'm really passionate about. And so I've set up some workflows and processes related to data driven design analytics, and how we can bring insights from the models, and how we can improve the process of digital transformation, and also in terms of how we can make the services more scalable.

I'm passionate about lean-- I've also had a certification in lean leadership, which involves me in improving the current process in organization. So quickly going through the learning objectives for today, I'll briefly explain what we'll be learning today in this class.

So the first objective is to understand how the common data environment, like ACC, would help us deploy large complex frameworks, like airport frameworks. And the second thing is how we can create a strategy for structured information and automated workflows to ensure a seamless information exchange, again using ACC. And the next one is trying to explain the advanced features of ACC, which is not available in the common CDEs that we have seen so far. So that is something new that we have found, and it was very valuable that we have applied.

So there is a feature called Bridge, which will help us collaborate between multiple frameworks and multiple stakeholders. And what we'll also been covering is compare the usage of ACC, Autodesk Construction Cloud, with BIM 360. So what are the additional benefits that we are getting out of the ACC? So we'll be capturing that.

In terms of the agenda, I'll quickly brief on the agenda. We will start with explaining what a framework contract is, what is the benefit of that. And we'll give a quick background of the project and then jump on to the goals that we are planning to achieve using framework. And we'll also cover the digital strategy in terms of how we want to deploy the digital implementation. We cover the challenges and the solution for them and then the value addition by implementing this whole process.

So talking about the framework, so since this is a eight year framework project, we just thought we would like to first explain what a framework contract means. So framework is basically a long-term contract which establishes a common terms of conditions for the future service that's going to be offered. So it encompasses a lot of small projects within the framework.

So there may be some other scopes like for example, design stage, construction stage. There can be redevelopment. So there are a lot of activities that happen as part of the framework. So all of those different work packages come under one umbrella of framework.

So the advantage of having a framework contract is, it's more efficient, and it helps us in doing a continuous improvement of the process. And it helps in building the relationships as well between the different stakeholders, and it also allows us to do our manage risk in a much more efficient way.

And quickly providing a project background, so this project name is Dublin Airport Authority. So AtkinsRéalis is the design management consultant or the lead appointed party for the entire framework. And the duration of the framework is five years, but we have got another extension of three years.

And AtkinsRéalis is helping in both the design stage and the construction stage as the lead design party, and it's located in Ireland. So there are two airports, which is part of the framework, both Dublin and Cork Airport. And the project is worth about $2.9 billion, which is a huge project. And they involve both existing assets and the new construction, so the existing assets are something where we are doing improvisation, and there are also some new construction elements that is happening in the site.

And the client is quite tech savvy, and they are open to test new workflows and implement new digital strategies. So we'll be talking more about the digital strategy and how we have implemented in the next upcoming slides. So I'll hand it over to Depak to continue with the presentation.

DEPAK ANANDABATMANADIN: Thanks, Hari. So now we'll be looking at what are the key goals of the framework that we have set initially for ourselves and along with the client. So the first one is the collaboration.

As Hari mentioned this is a large framework encompassing multiple years, and because of the size of the framework, there are going to be a lot of stakeholders that will be involved. So one of the key goal for the client is how we can efficiently collaborate with different stakeholders, how information structuring can happen so that the client can use it for their asset phase of the project, and how consistent the information exchange between different stakeholders can happen, and most importantly, how do we effectively communicate across the framework with all different parties involved.

And as it's a framework, we are looking at standardization because it's going to run for multiple years. So standardization is a key for us to increase efficiency and do savings. And also look at what could be the continuous improvement that can be done throughout the life cycle of the project. So these are the key goals that have set ourself.

To achieve these goals, we have defined the digital strategy. So in terms of digital strategy for the framework, we have done it at two levels. So one is at the framework level. So at the framework level, we defined all the components, which are going to be consistent across the framework. It could be hundreds of, two hundreds of projects that will be there.

At the framework level, we have defined, these are the few aspects that we want to make it consistent, such as, how the whole project will mobilize. What will be the information exchange flow? What will be the standards and methods that we'll follow across the framework? What should be the coordination process that we should follow in all the different projects under this framework? What will be the software and the packages and the versions that we'll be using?

And we also used MS Team for how effectively we can communicate between different stakeholders. We also are looking at CDE, or the common data environment, what would be set up and how it will be worked along with the client. As I mentioned, the asset information management is a key. So we have defined what should be the asset information strategy, how the different structuring of the information, which should be there.

And main aspect, in terms of people, we have defined the roles and responsibilities across framework and for projects. So everybody is aware what each of these roles have to do. And because of continuous improvement, we have also defined the reuse across the framework, where we will be able to reuse different components, reuse design, reuse the whole strategy that we are using across the framework. So these are different components that we have initially strategized that would be common across the framework.

But considering the fact that there will be individual project requirements that will come, so we have also created a project level requirement, which can have specific to the project, such as the BIM uses for the project. What would be the named responsibility matrix?

What should be the volume strategy for the particular project, how clash matrix will be defined for that particular project, some of the survey points and base points for each of the assets that we are going to work on these projects, and finally, looking at the MIDP or the TIDPs, the master information delivery plan, which we'll define what are the deliverables that will be coming as part of this particular project, and what would be the level of detail, and level of development for the particular information that we are creating.

So that's the strategy that we have created at two levels. And we'll be looking at how we implemented it across the framework.

So now the next part that we will talk about is the common data environment. So in terms of common data environment, what it means, what is a common data environment? So common data environment is a centralized information space where different stakeholders work together.

They have access to the information. Everybody gets single source of truth, even it could be a design team or a construction team or anybody in the client or the owner of the project. They'll all be able to have access.

In terms of this particular project, we have different contractual requirements. So you would be able to see there will be a project CDE, which is hosted by the client, the DAA. And there will be individual work in progress CDEs by the design team, which is AtkinsRéalis. So that's how we selected BIM 360 as the CDE.

So in terms of the selection, we started with BIM 360. And as it's shown in the diagram in the left, you see that we have used two different internal CDEs. One is SharePoint site, which is used for non-graphical data. And finally, those non-graphical data will be moved into BIM 360, which will store both graphical and non-graphical data.

The reason behind having this segregation is, in terms of SharePoint, it works better with Office documents, such as your Word, your Excel, your PPDs. And even though BIM 350 supports it, but we felt that SharePoint is more suitable for us in terms of how we collaborate. So that's the reason we have segregated these two information. But because we want to keep everything as one single source, we have moved all our published and shared information into BIM 360, which will be finally shared to the client CDE, which is DAA BIM 360.

In the right, you will be able to see how we have set up our BIM 360 sites. So at the top, you will be able to see that there is a DAA framework. So that's the whole common project that we have created across the whole framework. So this particular folder or the project will have information related to what are the different standards that we'll be using, what are the templates that will be used across the framework. example like, title blocks, your Revit templates, what are the standard guidance provided by the client.

So all these are saved under this particular framework. So everybody across these different projects will be able to access this particular project site, and they'll be able to know what the information requirements are from the client. And based on that, they'll be able to deliver on each of their projects.

And how we have set up the individual projects is, we have followed a naming convention. There will be different work orders, which will be called W01, and then followed by the project number and the project name. And as you can see, there will be multiple projects that will be there. And each of these projects serve a particular task order or a work order where we have been contracted to deliver some of the deliverables as part of the framework. So that's the whole setup in terms of BIM 360 that we have done.

So what are the key challenges that we faced when we did this setup? So as I mentioned, this is a framework, and we have two segregated CDEs. One is from the client end, which is DAA framework CDE. And also, AtkinsRéalis has their own work-in-progress state.

So what we faced is, as we have multiple work orders coming in, in a particular year, we were able to see we have more than 50 projects under this framework. So there is a lot of information exchange that we have to do between our different projects.

And in terms of standardization when we are looking at, there will be information such as templates, your standard title blocks, your Revit families, all saved under the framework level project. But if the team wants to use it, they have to download all this information from the framework level folder and then use it across different projects. So there is a lot of manual effort required to pass this information from one particular project to another.

And also, when we also want to share this information with back to the client, when it is in a published state, so we have to again manually download this information from BIM 360 side of AtkinsRéalis and then upload into the DAA site. So we had a full-time document controller to do all these different downloads and upload.

And also because of the size of the framework and the number of projects we started getting, we saw this is a big bottleneck that we were facing. And that's hampering our collaborative effort in working across the framework. So that's where we were looking for an option, and we went ahead with ACC, or the Autodesk Construction Cloud, as the preferable solution because that was the time when Autodesk released ACC, and we were initially testing out with the client to understand what are the benefits and how it can happen.

So Autodesk Construction Cloud as a software, how it is different from BIM 360. So Autodesk Construction Cloud was able to provide more connected ecosystem across different projects. So what we have decided is, we'll be able to work with the client to understand how we could use ACC rather than BIM 360 as a CDE for this particular project, and how it can help in sharing information between different parties, and work towards more collaborative effort.

So in this process, we defined a migration strategy where we were able to define three key steps. One is defining what would be the strategy for this whole CDE migration, and then doing a pilot testing across internally and also with the client and defining all the process, and finally how do we implement it once all these testings are finalized.

So in terms of the strategy when we defined, we were able to differentiate different projects, as you see. Like when I talked about BIM 360, the same strategy that we followed, there is a framework level ACC created. And there will be project level ACC again created in terms of folder structure.

As you see, this is compliant with ISO 19650. And you will be able to see the resource folders, which is common across all the framework and also individual projects. And you will have information such as WIP shared published archived, which is again common across all these different projects. So one of the key aspects that we want to do as part of this strategy is, how do we ensure some of the information that we get as part of the framework consistently passed on to individual projects? So that was the key strategy that we wanted to formulate.

So now we are going to look at how we have done a connected ecosystem of projects using an option called Bridge. In this example, right now I've opened the framework project. As you can see the folder structure, so you will be able to see different options in the resource, such as templates, frames, which is going to common across all the different projects. So that's why it is saved in the framework folder.

And as you can see in the right, these are indicators which shows this particular project is now linked to different projects across the framework. And the right arrow button, which was showing, was trying to say that the information is going from this project into all other projects. So these are the different projects that has been bridged. So you can see a lot of projects have been whatever under this framework have also been bridged.

And also you will get an information of what files are getting transferred from this particular project to all other projects. So that information log will always be there. You can always come and check it.

So now I'm going to open another file, other project, which is going to be the standalone project. And we will be able to see how this information from the framework is getting passed on to these individual projects. So I'm going to open [? PR ?] 3, which is a individual project in this framework.

The structure of the folder is going to be the same. So we will be able to see an ISO compliant folder here, which is again resource and work-in-progress shared publish. So in terms of the resource, if we go and see templates, we'll be able to see in the indicator an arrow, which is showing to the left now. It means the information is coming from the DAA framework into this. So any kind of information or upgradation of any of these existing file will automatically upgrade this particular file.

So you can see there are two different projects that we have bridged. One is the framework level, which is an internal project. And also, we have bridged the client hub. So we are able to now bridge or share information, not within a particular hub. We are able to do this across multiple hubs. So as an example, this is a particular file that we have been able to bring it from the client system into this particular project. So if we go into outgoing, again, we'll be able to see how much information we are sharing from this particular CDE into the client CDE, and you'll be able to take a log out of this.

So that's about how we are able to enable a connected ecosystem in terms of using Bridge, that we are able to set up automations from our framework level project to individual projects and also how we are able to set up from individual project to another hub in the client system. So this is how the strategy that we have formulated. And the next step is how this whole exchange of information happens.

So we had initially mapped out what are the different software that we'll be using. And as I mentioned, we are using ISO compliant folder structure. So we'll be looking a work-in-progress shared published areas. And in the left, you will be able to see different disciplines, which are part of this project, like drainage, runway, topography.

So these are the different disciplines, and we have mapped what will be the software that will be used across these disciplines, such as Civil 3D, Revit. So these are the different authoring tools that we use. So any information that we first are going to start will always be in the work-in-progress area. And then from there, we'll be able to move that file into the shared space through workflows. So we have used the workflow review options inside ACC to move files from one folder to another.

As you can see in the right hand side, there are different icons that have been mentioned to show how information gets transferred. We have our internal review process, which is called OCRA, originator, checker, reviewer, and authorizer. So based on that, our information gets moved from one folder to other.

So this information exchange, what it denotes is how we are able to manage information across ACC, and finally, how this information once it's in a published state, we have set up this automation through Bridge, which can automate the transfer of information directly into the client system. So we don't need someone manually downloading information from the AtkinsRéalis ACC into client system. So this automation will take care of that. So this improves a lot of efficiency that's a strategy that we have initially formulated.

So now we are going to look at how we have piloted this whole strategy. So the first part, we had to set a project and set the Bridge functionality. So how do we set it?

So we have initially tested out internally, where we have created a test project, and then we have to click on Bridge option in the left pane, where you have to select which project you want to bridge. So this is where if you want to bridge it to a particular framework project within yours, you have to enter the name of the admin of that particular project. Or sometime in this test, we also had tested with client, where we have mentioned the client's email address if required. So that way whoever is going to get this, so they'll be able to set the bridge between these different projects.

So now as a next step, what will happen is, once we enter the name of the individual-- so what happens through ACC is, it will automatically send an email notification to the receiver saying that this particular project is asking for a bridge option. So once they accept the bridge, you'll be able to see the acceptance of the information, and you can set up which project under your framework that you want to accept to.

So this way you are enabling two projects to be bridged. So this is as simple as setting up the whole automation process. So once this is done, we were now able to set up automation to transfer information between multiple projects in this part.

So now once we have set up this process, we also have to look at how information exchange happens between different folders and how it finally goes into the client system. So we have defined, in terms of work-in-progress area, when our file gets created. We set that into a review process.

As I mentioned, we have a four step review process. So each of these steps have to go through a particular reviewer. And based on their acceptance or rejections, it goes into another step. So the file, once it's reviewed, it goes into the shared folder. And if it is once it's approved, it finally moves into the published state.

And once the publish state is done, the file gets automatically bridged to the Dublin ACC account, so that way we don't have to manually inform the client that there is a new file that has been sent. This automation will trigger email notification. But as part of our process, we have also created transmittal so that it becomes a contractual deliverable to the client, informing them that we have submitted our deliverables, and we use transmittal to do the work, which also allows us to set what is the status code for each of these deliverables that we are sending.

So this is how we have piloted initially. And in terms of the implementation part, so we looked at three key points for implementation. One is the people. So we define clearly the roles and responsibilities. So all these are defined in the BIMx solution plan for the framework and for the projects.

So each of the roles and responsibilities define what they have to use, how they have to use this whole process, who is responsible for sharing this information, who's responsible for sharing the transmittal, who's responsible for the whole OKRA process that I mentioned as part of the review. So all these responsibility matrix have been created and have been defined in the BIMx solution plan.

And now in terms of process, we had intensive trainings for our team to understand this whole new process that we implemented through ACC-- how this whole bridge functionality works, how they can share information with the client, what are the different process and tools required for them to do this workflow. And finally, we also define some success factors, such as how we can improve collaboration. We will look at continuous improvement. We will work with the client to understand if there is any issue in the transfer of information, and failure, if it happens, we also record that.

So we have a clear implementation plan that was done to ensure that when we are going to implement this particular process, we were able to track the key success factors and understand whether the implementation going in the right direction or if there is any corrective actions required. So that's in terms of the implementation part.

So now we are going to look at the data analytics part, which Hari is going to talk about.

HARIKRISHNAN A K: Yeah, thanks, Depak. So what we typically do as part of AtkinsRéalis process is, we deploy a bunch of dashboards, which will help us govern or understand the data in a better way and facilitate decision making in terms of, for example, if there is some permissions that needs to be taken care for a particular project, we look at the reports, and we try to see how the permissions are there, who are the users that are using the CDE and things like that.

So as part of the CDE insights dashboard, what we have done in this framework is stepped it up to the next level. So what we have added is-- so this is the CDE dashboard that we have in our organization. So what we have here are some key analytics in terms of some number of files, number of folders, what are the type of files, and how many of them are unique. So we are very much keen to understand if there are any duplicates in terms of the files.

And it's possible that some of the duplicates are accepted if they are sitting in different folder states, for example, work-in-progress are shared, but we would like to highlight and understand, at the first place, whether they are acceptable or not. So in this project, what we have done is we have created this dashboard for all the work orders as a framework as a whole. So what you can see is the ability to filter the data, slice and dice, based on a particular work order for example.

So right now, I have selected work order 11 or work order 21, and you can see the dashboard is showing the data according to that particular selected work order. And what we have also done here is given an ability to filter based on the week. So if the data is based on a particular week, we can do that.

And we also have the ability to select the data based on a particular folder. So here you can see at a particular project within a work order, we can see the folder's structure, which is exactly reflecting from how we see it in the BIM 360. So this dashboard brings up all the data, and it serves it up for every user. So even if they are not part of a particular framework and they would like to know how the other folder structure is available or they would like to organize or navigate to something that is there in the framework, so this dashboard helps them to understand the whole data, and because this is a connected ecosystem, we are able to bring up the data in a more streamlined fashion for all the work orders at one place.

DEPAK ANANDABATMANADIN: Thanks, Hari.

HARIKRISHNAN A K: Over to you, Depak.

DEPAK ANANDABATMANADIN: So now looking at how we have done this implementation, what values we were able to achieve through this exercise was that, the first is we were able to centralize the data through this connected CDE. Now what we are able to do is we are able to consolidate all different project data documents in one common location, which could be a particular project. But this information can then be synced across multiple projects, so that way the data gets seamlessly transferred across multiple projects. So that's what we're calling it as a connected ecosystem.

The second one is, it improves collaboration. Now as you saw, that in terms of how we are working with the client seamlessly, how we are working with our internal stakeholders, different project teams are working together to share information, it's all seamless now. That's how we are able to improve the collaboration between all the stakeholders.

And in terms of the version control, any updates that happens to any file in the framework level, it could be a template, as an example, it could be a Revit template that from version 1, now it's a version 2 template. So that information gets passed down to all different projects, which have been connected, so that way we don't have to manually inform each of the team that there is a new template that have come, you should use that.

Now the system will allow it to get everybody informed that there is a new update. And based on that, the team will be able to use the latest version. So always the latest version is what every team will use, and the confidence is what we are able to bring.

And also it enhances the communication by facilitating effective communication through [? addition ?] threads, such as, like, we use different platforms like SharePoint, Teams. We also use the issue functionality within ACC, where we are able to communicate effectively. All the different stakeholders, in the design and also in the construction phase, they were able to understand these RFIs, these issues, and everything is tracked and audited within ACC, so that way we are able to enhance this communication.

We are also able to get value in terms of data security now, because there will be a strong security measures and access restrictions available across all the different folders, all different projects, so that way, as it's a sensitive project, as an airport project, so we have to ensure that all these safety measures are in place, and ACC allows us to create these different permission levels, and that way we are able to manage the security restrictions.

It also helps in reducing the risk, because with the centralized data now and connected seamlessly across different projects not just within our design team but also with the client, we are able to reduce the risk of using old information or using an error that is going to happen to manually download and upload information. So all these risks have been mitigated or reduced in this current workflow.

And we are able to now save a lot of time and money because initially, as I mentioned, when we use BIM 360, we had a dedicated resource to upload and download information from the client system to our system. And also whenever there is going to be any change, they have to be manually told to all the teams through an email or to SharePoint site, where we inform every team that there is a new update that is happening. But with the new connected ecosystem, we are able to automate all these different notification, the information exchange, so that way we are able to save a lot of money and also time through this process.

This process also allows for efficient workflows. As I mentioned, we used approval workflows across the project, which allows us to transfer information from one state to another, and that way we are able to track each of the information, which goes to the client, have been reviewed, approved, and checked before it's sent to the client.

This system, as I mentioned, we are already crossed more than 50 projects in this framework within a year. So this whole system is done once as a strategy and implemented. And now this can be scalable across any number of projects, across the whole life cycle of the framework, so that way it's a very scalable solution. So these are the main values that we are able to achieve through this effort.

So where are we headed now with this strategy? So now we are able to use the same strategy across multiple large-scale frameworks. As an example, the strategy we have currently using it across different airports frameworks such as Heathrow, as an example, and other large-scale frameworks, where we are able to replicate similar strategy across these frameworks.

And what else we were able to achieve is-- able to show the client and demonstrate the ability of using a more collaborative platform using these connected workflows, so that way the client will be able to simplify the whole information management process, if they adopt ACC as a CDE. So we are able to show these values and able to bring all the different stakeholders of a project to a connected ecosystem, so that way we are able to achieve a lot of efficiency in information management processes.

So that's the whole key takeaways from our project. And thank you, everyone, for joining this class and hope to see you all later.