Autodesk Construction Cloud: BIM 360 Template Development to ISO 19650 Standards and More

GREG SMITH: Welcome, everybody. This is going to be a presentation on ACC and BIM 360. It's going to be on the template development that we did for the firm that we work with called Mott MacDonald. And it'll be between myself and Richard Payne.

And a brief introduction about ourself before we get started. I'm Greg Smith. I'm the BIM manager at Mott MacDonald. And I have been BIM manager and design technologist for 20-plus years now getting to be more than one account, registered architect, and I'm also an adjunct professor at Pratt University, where I teach a BIM in document control class.

RICHARD PAYNE: Hello, everyone. I'm Richard Payne. I'm from our Mott MacDonald's UK offices in Sheffield, which is central UK. I'm a principal digital consultant with 20 years multidisciplinary design and delivery background. I feel like my whole entire career has been with Mott MacDonald, so straight out of trousers.

I'm an engineering technician by trade. I'm a member of the ICE, which is a corporation, and institution within the UK. I'm an identified super user and subject matter expert for common data environments, whilst also providing an experienced outlook from my previous stages of the career of an advanced user of major software packages.

So our company, Mott MacDonald Is a global consultancy. And our purpose is to improve society by considering social outcomes. And we relentlessly focus on excellence and digital innovation, transforming our clients' businesses and communities and employee opportunities. We're a workforce that works in around 140 countries across the globe with approximately 18,000 staff, and the business has been active with a heritage of 150 years.

GREG SMITH: So just a brief introduction what we're going to talk about. We're going to outline the components of the template that we thought was essential to creating a template and to aligning that with some sort of national standard. And we've chosen ISO 19650.

We were trying to make a consistent data environment between multiple platforms, and we'll mention, briefly, we also used ProjectWise and SharePoint. So we tried to align those environments. And we also wanted to create a really robust template that could adhere to those standards, and it could be applied to multiple regions. So we'll see in a bit how we can actually disable that a bit so that it works in a US project without quite so many restrictions.

RICHARD PAYNE: So the topic is raised of why. So why did we need a template? We had to provide justification for doing this. And simply put, as Greg's also touched on earlier, we used additional platforms within our corporation. And we had to generate an air of consistency that was evident in the competitor environments. So what we were looking for is standardization across our ACC and BIM 360 common data environments in comparison to the other two environments that we regularly use throughout our workload.

We obviously had to take into account potential possibilities and host of impacts, overall project performance, current circumstances which within those environments for BIM 360 and ACC, on previous occasions, without the definition of a template which led to this project being part of our recent history, is that we were experiencing inconsistency in workflows, so workflow management of information.

One of the most glaring problems was the lack of uniformity across our projects. We had different teams, different regions, individual project managers often different approaches by all of those levels. The inconsistency then generated and hindered a project's efficiency and collaboration across the network.

Through loss of efficiency, we obviously experienced team members having to invest time and effort figuring out solutions to problems, which varied across our countries, across our regions to provide, basically, an unproductive platform.

We faced difficulties with collaboration. So the challenges were that we wanted a successful environment to establish that didn't hinder our process. We needed to adopt a unique approach with exchange of data, model information management, access of information between different environments, how did our stakeholders and external parties engage with streamlined efficiency.

We then had to harvest and harbor out a risk of error, due to the above. So the inconsistency and inefficiencies were creating problems that could be potentially cost detrimental to the projects. And to address this issue, we proposed defining a standard group-wide template that met, not only Mott MacDonald's standards, in terms of business management systems, but identified a roadmap that aligned with the internationally recognized standard for a streamlined and consistent approach to create that efficiency.

GREG SMITH: So just briefly, what we're going to talk about. If we think about the template, we can break it out in certain components, and our process that we used to start thinking about the template. So it really was a well-organized process, where there was an appointed board that found some subject matter experts, some people that were really passionate about the topics of BIM 360 and ACC.

We all decided to align it to a national standard, and ISO 19650 seems to be the logical choice, since the US is lagging quite a bit in finding a standard. We'll go to the template definition break that down into some components.

Managing the templates has its issues, both in ACC and BIM 360. We'll touch on that and how you manage the distribution of a template across a global firm and actually multiple hubs, multiple Autodesk hubs. And we developed a process where we could educate the teams and support the teams as they started to use the template.

And of course, this is the initial development of the template. We have a good base template that can be distributed and modified to accommodate several different project types and client types, but there's always ongoing development. So we'll touch on that, as well.

So the process of discovery, we had an appointed board that set aside the business case to identify a few people that could start to see what it means to have a template. Because it's quite a challenge to assemble a template that could be used across a global firm that's really large, that has many different regional requirements. So we started to identify which pieces of that template could be consistently could be used as a base for the template across all those regions.

RICHARD PAYNE: So as part of the defining our discovery process, we obviously, engage with an organized, structured team. So identified a group of subject matter experts as a resource. We developed that team. We identified the personnel. Ranging levels of experience and different outlooks, different project types, different regions to make sure that we covered all bases.

We then looked at how we could adopt a system that would define this template. How were we going to manage it? So we looked at options that would consider a discipline-based system that was managed by permission role groups. Naming conventions that could apply that set within those environments to meet project requirements, make things efficient, and align with group standards but allow adaptability and flexibility across these different regions to meet different client needs.

We also employed a classification system to this. So we had global discussions to identify best practice across those regions. We engaged with Autodesk Services on numerous occasions to identify where we had gaps within the product, where we had inefficiencies in our knowledge, to gather all the essential requirements that provided the insights for us to create the perfect template for development.

Following the process, we supplied a testing environment, which led to a high-level, experienced-user, subject matter experts that weren't defined within the project across all different parts of the business, where they were allowed to test, criticize, provide input, provide positive feedback.

This led to a section where we had a spectrum of established information where we could then generate valuable input to present an adaptation, a refinement to those structures to adjust where necessary to define an end goal, which was a suitable solution to meet a vast majority of an 80-20 scenario of project situations.

Following results of our final product, we then let out a feedback session. So there was a range of surveys meeting different particular requirements, aiming at different levels of personnel in terms of what their roles and responsibilities and outtakes were, and how they would see and receive the information. This ranged from a range of everyday user to a management system through to project board level in the sense of trying to establish the best practice then did it meet expectation.

GREG SMITH: So considerations of the templates, one of the original ideas that we had was to create some sort of, at least, consistent environment between the different CDEs that we have. So as I mentioned before, we use ProjectWise and SharePoint and Autodesk Construction Cloud.

And each of those have their own sort of special areas of efficiencies. But we wanted to at least create an environment so that when you switch from a project from one to the other, that it's not a completely new environment in structure. They all have different details that can't quite be aligned, but we tried to make it as consistent as we could. And the intention of that is to create good habits. No matter what environment you're working in, you can see a nice consistent in a structured way to work through a project.

RICHARD PAYNE: SO we touched earlier upon the definition to align with, not only our internal business management systems but an internationally recognized standard. Part of the justification for this was that we needed a starting block. We also had certain regional requirements that resulted in-- the UK specifically, has accreditation with ISO 19650, therefore, implementation of a suitable structure that provides compliance and governance within that lane, it's a demand of the projects that we produce if we're defining that we are working towards those standards within our supporting documentation.

However, we wanted to provide adaptability. So although this structure is aligned with ISO 19650, the flexibility of the environment controls information via process driven and familiar method throughout the organization. So just because the definition is aligned with ISO 19650, it doesn't mean that it cannot be appreciated by those projects that do not define currently to those particular standards.

So our other overarching goal was to establish a standardized approach that not only streamlines project workflow but also enhances the collaboration and the efficiency of project success. We understood that consistency in our process would be key to achieving that objective. And a pivotal driving force behind this was to adhere to an unwavering commitment to aligning with ISO 19650.

So ISO 19650 sets an international definition of standards to govern the information during its life cycle. Particularly when using building information modeling, these standards have become essential for mainstay and competitive nature within our industry, and as such, we've embraced this wholeheartedly.

So by adhering to ISO 19650, we not only elevate our own practice and our performance but also the position of ourselves as industry leaders. We look to upgrade and educate our clients in this lane and to what these standards will adapt. And we demonstrate our commitment to excellence in ensuring that our clients receive the highest service and quality of information possible in a controlled manner.

GREG SMITH: So our simple definition, let's get into what actually creates the template. So these are the pieces that we sort of have broken out that we have broken out into components to think about it into components. In the center of that diagram, is containers and probably closely related to that, is permissions. It is really hard to separate how you describe the structure of the template with not relating the containers of information and the permissions that control people and control the access.

We'll touch on the naming convention. The review process that we set up, we have created custom folder and file attributes. We'll touch on the issues. It's able to be customized now in ACC. And the way to set up teams and model collaboration, design collaboration is a bit different now in ACC. We'll touch on that just briefly.

RICHARD PAYNE: So our subfolder container structure provides a level of granularity for adopting various levels of access due to permission basis that is being accounted for within the account admin. So not only is our permission organization limited to the folder content, but it's also accompanied within our review workflows, which we'll touch upon later.

So the outer level of this information and this work tree, if you like, covers work-in-progress environments, a wider project content such as shared and published information, as well as an accessible library of resource material. This typically could contain information such as project defining templates for drawing, Revit families and parts, resource materials such as background data for the project, income information stored in a logged way in accordance with document registers.

So this would be mandated at your project setup. Additional content could be line styles, print files. This is an accessible source to the project. The discipline nature and contributing party, if you like, has a segmented approach, whereby, privacy of information at discipline level provides local access at team level so that you can have an iterative process between a contributing authoring team and a checking team and a kind of team-lead environment prior to that content being subject shared with the wider project team.

At the next level down, we have a further substructure which provides the most opportunity for further segregation. However, this section, which is entitled Content Type, also covers the fact that this is the most flexible in the terms of the potential possibility of increasing or simplifying the number of folders.

Renaming them to suit a project's requirements is then not detrimental to the overall project structure, whereby, the permissions that apply to this folder are inherited from the disciplinary parent folder above.

As you can see, I've kind of delved down a little bit deeper now within what we're classifying as a common container. So this will cover our resource environment, our shared environment, and a published environment, as already touched upon. So as you can see there from the example, the Resource Center supplies a wealth of accessible content to aid the user with templates and therefore, required outputs for the information to be generated.

Our shared environment, as you can see from the image displayed, replicates the work-in-progress parental-discipline structure. However, the permissions within this environment, which we'll add more depth to later in the presentation, provide a level of granularity, again, which provides a differing level of access to the wider project for visibility for coordination purposes.

Our published environment, again, a repeat folder structure but providing another level of visibility, also permissions in terms of how you can access that data and what you can do with that data. Published environments, though, are therefore, to capture and freeze frame information distributed in time as part of an issue process.

This is a record of information, an archive of information that should not be-- it has no edit rights. There's no permissions to extract this data and edit this data. This is, as I've mentioned earlier, a complete replica and freeze of the information submitted.

So now we have a video file, which will play through an overall structure to present the depth of granularity within an environment for participating parties within our projects. So we've provided environments for client and contractor level with a simplified folder structure, just documented by type, which they will get overarching permission for in terms of folder permission to add and remove what they need at that level but not at parent level.

Our Mott MacDonald's environment as a work-in-progress area, has been discussed with levels of privacy for iteration. Our third party replicates the Mott MacDonald environment. However, the difference here is that the permissions applied here are high level. So there is, in simple terms an authoring element, a checking element, an approval process within that team, however, providing a level of split with that team.

The team within a third party will obviously, potentially, have access to reevaluate project level that, for example, if a structural lead project by Mott MacDonald's as the host, may involve M&E environments. However, our subject party may have a subcontractor that's carrying out the electrical works or the architectural works. And therefore, our permissions and folders are movable and interchangeable to apply a set permission group.

How we've combated this environment to cover design collaboration on a full scale scenario is that we have also noted the fact that we would cover-- an acronym at the end of each discipline, so should two participating parties be producing the same content so that design collaboration can cope with two teams of the same discipline.

GREG SMITH: So controlling the access to the folders is by the roles and permissions. When you apply permissions in ACC and BIM 360, as well, there's three different ways to do it. You could apply permissions by user. That is the most labor intensive way to do it, and it's the hardest to manage as the project goes along.

You could apply the permissions by company, but then that's going to give them too much freedom to folders and to the level of document editing control that you might need inside of folders because one company would have all the same permissions.

A finer way to control that is by roles. So you could create a role. You give that role a definition. And on the folders, you could assign the level of permissions by the role. And you just add the users. You assign the roles to a user.

So as you can see in the example, we've created a role for all the common disciplines that we have in an AAC project. There are actually 183 roles on the hubs that we've created. And we've covered most of the common disciplines. Of course, there's always new requests coming in, so we can modify as needed.

But we've developed a pretty comprehensive list now that's applying to a wide range of projects. There's also a higher level of functional roles. And you can think of it as sort of technical people that will be on the project that may not be assigned to a specific discipline, such as a BIM manager and coordinator and doc control people. And we have one user role that's identified as a power user that will have a higher level of permissions on most of the folders.

But the goal of this has been to control the information management on projects. So when you create a project with one of these templates, it comes with a well-structured container or folder group. And then each one of those folders have the roles already predefined on the folders. So it comes set up and ready to go and perhaps, be customized to the project.

RICHARD PAYNE: So we'll delve a bit deeper now into the kind of roles provide a little bit of insight into how this might work. So from a work-in-progress environment, we cover a permission level. So we've kind of focusing here on one particular discipline to provide a consistent view for everybody so that you can see how this would split.

So from an architecture perspective here, what we have is that you will notice that different role groups from a work-in-progress environment. So we have categorized these within an author, a checker, and an approver of this team. So that would go down to different levels of information being produced, reviewed, and accepted.

Everybody, however, within that team at this particular level, will be subject to being able to produce content within this environment. We'll touch again, later, as I mentioned, the fact that how this links with the authority roles in terms of initiation and approval actions within review workflows.

You'll also notice from this view, how the functional roles will kind of adapt a level of visibility of information. So we're ranging here from an authorizing role, which might be a project principal, project manager, design manager somebody with the highest level of authority of your project, down to-- the reasons that we have our document controllers and BIM managers with a higher level of permission here, is that a BIM manager, essentially, might work throughout the whole work-in-progress environment, so therefore, they would need to manage those environments and develop consistencies. This may include CAD coordination, BIM coordination.

The document controller, that we've become accustomed to using on a vast number of projects, is that they are there to assist with any naming difficulties, metadata application, and correcting of any errors, potentially, that may allude to. However, we have tried to strip that possibility away. We'll cover it in our naming standards later. But we've enforced throughout our structure, aside from a particular environment, the fact that the naming enforcement is part of the template. And we'll touch upon that later.

Slipping down into the shared structure of this, and again, from the perspective of an architect, is that the level of permission will drop. Because obviously, we don't want editable content here. This is information that is upload only providing access to markup, review, and kind of contribute in that manner.

However, once the team has approved that for sharing, the information is-- it's essentially a record at this level, an intermediate level. So what happens within this environment, as you can try and portray from this view, is the fact that the discipline themselves will get an upload perspective. However, an author won't be able to carry out this action because they're not part of the review workflow process that's enabled.

But a checker and an approver at this level, will have the upload function to approve a workflow enforcing that there is a direct path via that workflow for information that may be shared outside of the use of design collaboration that will adapt and automatic copy function to this location.

Touched upon design collaboration there. The environment of this is also filtered with the fact that design collaboration for model functionality will also, once a package is published and shared through there, models will also define in this location. So we have to provide a level of visibility in terms of permission to this environment for all of the contributing parties.

So what we do have in this environment as a base-level template, is that not only do we cover our responsibility of each and every user, so there's a company level permission applied here, so it provides a general user, but also the fact that, as you can see, a mini-breakdown, is the fact that the disciplines that are covered in entirety, so a fraction of the 183 roles will be able to see this should they be added to your project at a work-in-progress level.

We mentioned earlier about the adaptability of the folder structure. A simple example of that would be if we were to swap out the architect for AV Aviation, we would have a role group pre-assigned throughout the whole common environment shared public resources. All that covers that permission by default.

The only editing that is required by the Project Administration Panel is at the work-in-progress level where that team is adapted. The only addition changes at the sublevel, shared environment common level, would be to actually rename the folder to suit its requirement.

So the video that you're seeing now, is a quick run through to try and highlight the common environments to provide a granular approach to where we sit with sharing information at a higher level. So our published environment, just for kind of simplicity of definition, is the fact that each contributing party has their own environment to associate their information by team.

Within that environment, there is a subfolder structure that would be accustomed to your working party. So again, we go down by discipline. The third-party environment, as we've mentioned earlier, does distribute information here.

And you can see the level of granularity with the permission group at a high level. So instead of having an architect approver, we have an approver for the whole company. The likelihood is that that party will only contribute on a mass scale to potentially one, two, to three disciplines.

So therefore, there may be a requirement to potentially move over your permissions from your host environment to this environment. However, we've tried to cover the wider-scale, vast-majority case where a consultancy may be contributing as much as Mott MacDonald. So therefore, we needed to have a competitive environment that can accommodate that.

The resources, you can see here that the subject parties will also have a level of access. By default, that can obviously be controlled at project level too if you don't feel that is a requirement.

However, we've tried to share the responsibility that on a large-scale project that there be contributors from each party where they would manage templates, they would manage resourceful information that is coming from that party that suits not only the project needs but those the contributing parties specific needs. So in terms of a management system, we wanted to provide that flexibility that our stakeholders, our contributing parties had a level of control of their own information and resources.

So as we touched upon earlier, this is a mass overview of the whole registry of information that is accessible within our cloud-based internal pages for materials in terms of common data environment, our training materials. Within this registry, there's an accompanying sheets, as Greg mentioned earlier, that there is a process deployed for additional role group requests that is then assessed and reviewed by a board of whether how useful that would be for a wider project scenario, or to provide a subject matter expert to provide a solution to that.

You'll notice that in this environment, there's additional kind of role groups, as well, that we'll cover on the left-hand side about halfway down. There's a circulation set of teams. These can be used within subject environments relative to collaboration or coordination. So you might have a clash-detection team that come from different role groups.

So instead of just being assigned as an architect, a structural engineer, or an MEP personnel you might all be responsible for communicating in a single-source way via a circulation team that can be assigned to carry out your task at hand.

GREG SMITH: So then in this template, we set up the teams. It's interesting, if you think about the difference between the way you could create teams in BIM 360 and then ACC. One of the happy benefits in ACC, is that you could go ahead and create workflows in the template. You couldn't do that in BIM 360. So that actually defined a difference in the way we set up teams in ACC.

So in ACC, we fully created the teams because it's a bit of a time consuming thing to do in a project. We fully created the teams for each discipline so that will by default, define that you have to create the shared folders for each discipline, so it's already in place.

And you contrast that to BIM 360. We only did a small sampling to roll out with the template because it seemed like it would be a waste to have all those extra folders and shared that aren't used. But as you'll see in a second, we can create workflows. And the process that we use there, copies files between different folders of the shared and the published environments.

So it was necessary that we create all the teams. But it's nice to have a fully built template to create a project, have all those components in place when you start up the project.

RICHARD PAYNE: Yes, so we touched upon the reviews earlier. And the justification for doing this was that we wanted to provide an example of something where a team, a project, may not be experienced. They don't know what they need. And these base-level workflows, which is a single-step workflow with justification for four group sets providing the level of ability to distribute information or review information for a particular purpose.

So the reason for it being a step one, is the fact that we have an initiation process and an approval of that particular stage. So approval, in this sense, is not deemed to be an authorization. It's deemed to be accepting of that particular stage or phase of that file's life cycle.

So from the first image that you see on screen, we present, with as much information but in short form, to say what the action is and what it does. So obviously, this is an architect providing a content review resulting in no copy action. So this is a team level function for an iterative process throughout the design development stage within your own internal team.

What happens here is that, upon approval, you can use markups and raise issues as a team level, but nobody else can see this information until you are moving to the next stage, which is the third one in the list due to alphabetical organization, where we would share information. And as you can see, where the action upon completion stage is that these are predefined per discipline to land within the shared environment.

Mirror of that, is a replicated process for the published. So the same status is applied, the same actions apply. However, what differences is are here throughout all these groups, is that the permission groups that are applied for authoring can only initiate within a content check review.

Sharing for publication, for example, that can only be done so by a team lead, so a team approver. And then that action can only be approved by a project member who is classified as an authorizer, so a project principal, project manager, for example.

Then we have an intermediate example case, where they may be a requirement for privacy of information but coordinated throughout our internal teams. So we've provided the ability to share information that sits at a high level within our work-in-progress environment but provides a granular visibility to all MacDonald disciplines. So this means that if we're working with additional consultants, that we may want to get our own house in order prior to sharing that information with a wider audience.

The image at the bottom left, also kind of defines a little bit of scope here. And we'll touch upon this later in more detail, is the fact that we incorporate and capture additional metadata via related attributes. And what we're trying to say here, within the reviews panel, is that the required approver has the possibility and functionality to be able to review but review within a viewing capacity to ensure that the actual detail within the file itself is correct.

And if that is the case, we're providing them with the opportunity to rather than reject based on a metadata input that solely relates to whether the revision status or the classification in terms of the file or the suitability status of that file is applied correctly, as per the viewing platform of the data itself, it's simply applied here, which then translates, not only through to the target folder but the actual source folder therefore, removing the requirement to restart the process.

As we've mentioned many times, we're looking to drive efficiencies and trying to not backtrack where possible for unforeseen circumstances that it can only cause delay. These example workflows are then replicated for each and every discipline provided as part of the base-level template.

Again, subject to change, if we were to swap out a role group, I'll use architecture again and replace with aviation, not only would you change the permission of the work-in-progress environment for that permission group to apply at folder level, you would then just rename the architecture workflow set to aviation and go within the Edit function and swap out where the architectural users were applied and at their different levels and replace them with the aviation from the role group list.

So these review workflows not only capture business management systems within our organization, but they also encompass the status through ISO 19650 requirements in terms of sharing and validating information.

So to touch upon the naming standards, what we've tried to apply and adopt to this system, is the fact that we want to eliminate confusion. We want to facilitate a data retrieval process. So I'll apply flexibility within the search functionality accompanied by our subfolder structures that can guide people in the right direction.

The naming convention enforcement of this, also doubles up via related metadata within those environments so that you can search by a particular column. So if you're looking for a particular originator, you can search for that party. You can search by a functional or spatial breakdown. You can search by a particular discipline.

Having this granular approach provided by a naming standard, allows that those additional metadata columns to be enforced within your metadata fields of each and every folder throughout the structure. This provides an enhanced organization. And as we've touched upon already, it provides a level of good governance and compliance throughout enforcement.

So the image to the bottom left, provides a little bit of an insight to where the breakdown of this structure applies to file attributes. In the section of that, certain sections are relative to the naming convention, so what is compatible, what is applicable to the particular project.

Having the enforcement, will also provide an automated level of checking if something is non-compliant, so it is flagged in the holding area to an administrator. So that requires a file to be fixed. And then there's the related attributes that can also be enforced and applied at this stage.

The company and attributes will provide the clarity on revision. So aside from just version control that is default within ACC and BIM 360 platforms, we're looking to provide revision of content. So that will grade the level of information in terms of what it is deemed acceptable for.

This is accompanied by a suitability status. So we're using S suitability status throughout a preliminary revision system. What this does is this provides the level of purpose of that document. Once we advance through to a stage approval, we'll go through a publish state, which means that the document itself becomes a contractual state, meaning that the definition of a suitability status here is applied via A codes to define the stage that the project is at.

We have also adapted a uniclass classification system. So this will provide an extra level of depth for categorization, which is an industry recognized system for construction projects. We've chosen the FI index in this case because what we're looking for is information management. So we're looking how information can be controlled by type. So the FI index stands for Form Index. And moving on, we will look at issues.

GREG SMITH: Yep, issues in ACC, another nice feature that you could add to the template, couldn't do this in BIM 360. So you can customize all the fields that are associated with the issues the types, build your own custom types, custom pills, the root causes. You could create a template that can combine all those settings.

And then the statuses, it was actually quite annoying in BIM 360. When you created a template, you had to go in and set the statuses to be active so that people could use them. And that's one more thing we can take off the BIM managers plate now, as it gets predefined in the template.

The issue in the category and the type there. We did a polling across several projects. And there are fields that are typically used over and over in projects. So now we can set those up in the templates, pretty good.

And in managing the templates, just a few words about managing the templates. And the first notion of that is, any time that you build a template, everybody puts their most dedicated work, which really turns out to be a best guess, about what you need in a template.

As it starts getting deployed, as it starts getting used in projects, you can see what works, what doesn't work, what needs to be refined, and what you can add to the template. So it's a management process.

And it is also the Holy Grail that you could build a single template, and that's going to work for all conditions. It's not going to happen. So our approach was that we would build a base template that we could modify that we had some control to modify, and that would we could create variations from that single template.

It was quite easy in BIM 360, with the JSON file, because she could create a project, export it as a JSON file, open it up in a text editor, make the changes that you needed to make, and you could coordinate without so much manual input.

That feature has gone away in ACC. In modifying the templates, the JSON file is not available. So in the ACC projects, it gets a little more tedious because if you have multiple templates that are built off of a base template, you have to modify in multiple locations, which is one of the basic rules in computers. You want to create it once, modify it once, and figure out a way to automate the process.

And what we did discover is quite a low-level approach in ACC is, we've tried to build a master template that will have a base template that's going to have most of the conditions that you're going to need, so starting with all of the folders and all the permissions.

And then what we discovered was that we could create a really low-level command script, which means that you create the project from the base template. It's going to have all the folders in the [INAUDIBLE], in the shared, and in the published environments.

And then you can run a command script. And the one that's on the screen, it's really just got two pieces to it. It can either remove a directory or it can rename a directory. And that's an easy thing to find these days with ChatGPT.

So what we do is create a project. And you have to select a project in the desktop connector let it download, then you can drop that command script in. Run it, and we have several of those scripts that will convert it to different project types. You can run that script. It'll change all the folders take out the ones that you don't want.

And a bonus on the desktop connector, that's a .CMD file. So that's one of the file types that the desktop connector won't upload. So that script is not going to accidentally get uploaded to the project. So the person that runs the script can just go in and delete it, and we actually have all of those instructions set up with IT. So we can manage the template, let them run that script, and then it sets it up for a different project condition.

And we have projects on multiple hubs. This is another bit of complication that we haven't figured out really an easy way to do it. So we are maintaining that base template on multiple hubs. And then we can create the variation projects from that base template.

In education and support, we are supporting the projects and have defined a bit of content that's living on a SharePoint site that's available for everybody. Richard?

RICHARD PAYNE: Yeah, so to ensure that we provide a successful adoption of our templates and generated a level of awareness and upskilling, is that we had to provide a level of detail that provided, not only user level of information of how to navigate the system, what people shouldn't do where and when and how the general makeup of this worked.

We also needed to provide a level of information that would support an administrator for the continued process of their education, or their knowledge sharing, or a referral system to refer back to. What we wanted to provide was material that was easily accessible, easy to read in simplified terms as far as possible to explain not only the intricacies of the template but also how it can be adapted to suit particular requirements.

So we did this via some comprehensive educational initiatives, where we provide a repository of informative guidance. We provide learning pathways that are hosted on our training hubs. So you have two potential paths here, which is a short, sharp, crib-sheet style accessible document that is shorthand very, very rough around the edges but gets to the base level points and probably more, in fact, describes the actual structure itself.

Then you get to the detail. So this can be done as a long-winded process. It can be combated in a series of hours, in the sense that we have modules available that not only inform but test people's understanding. So there's an associated quiz to the panel to make sure that people have understood the requirements.

And this is not to enforce a nature of catching people out. This is to provide people with the kind of self-awareness that they understand what they need to do and how they should edit to still maintain the integrity of the product that's being defined as a base level.

And accompanied to that, we carried out a series of pre-recorded presentations with accompanying slide decks. So if there's not the opportunity to sit and listen and watch a half an hour video, there is the opportunity to read in your own time the equivalent slides that were accompanying for that presentation.

The presentations are done on two levels and for two different reasons is we kind of touch upon the principles of document. So this was to go out to board members. This is to go out to project managers, resource managers to try and understand the reasons and justifications of why we are doing this and what benefits it will bring. And then there's the details.

So this is again, project administration, general everyday users of the environment to provide that level of granular approach to each and every task that may be required or understanding of the task that's required.

We then have our self-directed learning paths. And in addition to this, we provided what is known as a kind of a super-user subject-matter environment, where we have team sites, internal intranet sources of material and access where we can raise and ask questions and people are can reply accordingly or have a general conversation to discover new ways of doing things. This is an open source and an ongoing process.

So at the final end of projects roll out, we did a soft launch back end of 2022. And the soft launch was then followed by a pilot program. The pilot program was to approach newly formed projects following the successful bid process to winning that particular project of work to allow them and give them the opportunity to get first-hand experience of using the template with an allocated resource.

So in short term, there was either myself or Greg would be assigned to work with that team, provide the kind of high-level training, the understanding, and then guide them to where the advanced training material was. We would share our knowledge throughout the life cycle of the development process to each give a background. And we provided that opportunity to those projects for a limited period of time.