Autodesk Construction Cloud Design Coordination and Scope Management for Contractors

ADAM SHEATHER: Welcome, everyone, to Autodesk University 2023. My name is Adam Sheather I'm the Managing Director of Autonomation, and I'm here to talk about the Autodesk Construction Cloud Tools, and specifically the design coordination and scope management processes we've developed for contractors and builders.

So really quick, what does automation do? The business, our workflow, basically, there's three areas. We do technical advisory. We do software engineering for startups and AEC companies. And then the thing that we're going to talk today is around our BIM management. So this is where we help develop BIM plans, execute on them, audit the files, all of that sort of stuff. So that's the focus of the talk and how it relates to the Autodesk Construction Cloud platform.

The types of projects that we do it on, today's talk is about the work that we're doing with health. But in addition to health, we do a lot of work in other areas, so roads and subways, so infrastructure. We're doing a huge $7 billion project with technical advisory with renewable energies. And we help commercial clients with tenancy fitouts and making sure their models are FM-ready for their tenants. It's not just me. There's a team of us, so I just want to really quickly shout out to the whole team who make all of this work possible. So thanks, guys. It's definitely not a single effort.

So the agenda for today is really a number of things. So we're going to look at specifically the health projects that we're dealing with and how we've configured those for the Autodesk Construction Cloud. So we're going to do a bit of a dive into the Queensland Health BIM Standards, what those are, how they came about.

We're then going to get into the project workflows. So this is how we've set up the projects on ACC. Then we'll be diving into the model work sharing, so how we've configured the Revit files and the IFC files to work, how we then start to audit and check those files for issues, then diving into the Navisworks and ACC Model Coordinate clashing workflows and issue creation workflows.

Finally, jumping into scope management, how we manage the scope and the rate of change, and change for all of these projects, and provide all of that information. And then finally, we will provide some data validation and how to extract all the assets from there from the Autodesk Construction Cloud.

So a deep dive into the Queensland Health BIM Standards. So really quickly, Queensland is a state in Australia, where I live, and what happened was basically they adopted the ISO-19650 policies back in around 2016. There was a major government mandate to start adopting these frameworks. There were the hard time deliveries that the state governments had to meet this in 2020 in 2023.

All health care in Australia has a large state body. There is a private body as well that has private hospitals, but there's a large state government health care run set up as well. So the key pillars of this was really around the ISO-19650. I'll just turn on my little laser pointer here. So adopting the ISO-19650 policies.

We put our Australian flare on those policies and guidelines to localize it. An open BIM approach has been adopted by the government, and then these national standards. So this then filtered down into these contacts and state contacts until we finally get the BIM project requirements. So this took about five years before it could actually head down to the supply chain.

And as a result, we now work with a number of different data sets. So every time you get involved with a project in Health, we get given all this information, so Revit schedules, we need to comply with, design BIM execution plan templates, IFC mapping guidelines, and data export as well. So it's quite rigorous. And version 2 just came out in December, which even takes that further.

What does this look like in terms of real world? We have a lot of documentation that we get given now. It does take a while to pass through. It is quite meaty. So this is all the requirements. These are then the feasibility inputs that are given to us by government stakeholder outputs. And then we have the BIM plan, so we start to deliver on, and then finally the outputs.

So our scope of work and the design team and construction team's scope of work really comes in here. So do the project information requirements make sense with the feasibility? Are there any exceptions we need to make? Updating the BIM plans, and then delivering those and auditing those outputs.

So one of the ways that we get some inputs is in Australia, we have a AusHFG website. This is a website anyone can go to, and basically, it's all the standard practices for recommended practices for health care in Australia, so how the room should be set up, the hospital should be set up, the schedule of accommodations, the level of care. All of that information is here.

But with the BIM policies, there's been a lot of investment into providing these sort of initial specifications. You don't have to use this Revit content, but it is provided as a guide as what best practice looks like in terms of a guideline. So these form a lot of the specifications that we need to adhere to, and communicate if we're deviating from them why. So it makes it a lot easy for firms without a lot of this health care data as well, and content, to be able to work on these projects if they're growing skills in this space.

The other part of this that's pretty important is the government constantly updates feedback. So I said Standard 2 was just released. There was a Standard 1 that we'd been working to the last couple of years. And what this allows us to do is it gives us-- the government requires this dashboard to be filled out every single phase of a project and put back to client.

Now, it's not to sugarcoat. They really are interested in how BIM is being procured and incorporated. Is it working? Any comments from the client? Were there problems from the client side? Were there problems from the delivery side? Was it too onerous, too easy? Did it not add value?

So every step of the phase, we sit down, we work and go through, did the procurement work, did the collaboration effort? Was it improved by having 3D visualizations? Were the open BIM format requirements a hindrance or a benefit? And then is there value in the structured build-up of BIM rather than the last-minute cobbling together at a milestone, which happens a lot?

And then with all those frameworks and recommendations, those are applied on all health topologies in Queensland. So what I mean, we're working currently with a number of projects into the billions of dollars, so these really large-scale, brand-new Greenfield hospitals and Brownfields, these smaller rural or satellite day care, day surgery sort of setups, where there's a limited amount of level of care, but it's accessible. And then even down to the DFMA and these sort of modular and the really rural areas.

So pretty much from $10 million up in capital expenditure requires the delivery team to meet these BIM requirements. The way that the BIM requirements and the plans break down are into two key areas. So we have the design BIM execution plan, which is really around the architectural and the engineer structural and MEP consultants, assembling their data, making sure that the program actually works, making sure they've got the right quantities and the general coordination, and spatial constraint validation is done, and really having the models ready for tender.

Typically, at this stage, we find that the structural models are frozen. And then if the contractor is brought on board at this stage, they will then take over the construction BIM execution plan. So the design BIM execution plan usually would be led by the architect. And then in the construction BIM execution plan, we'll have the subcontractor data.

So this will be, the subcontractors get on board. They start putting their fabrication installation models. And then also there's a requirement usually from the [INAUDIBLE] architect and the MEP subcontractors to update all the critical assets to include all the FM data that's needed for the asset registers for the facility management.

So what this looks like as a final deliverable set from all of these recommendations is really something like this. Every major milestone that's defined at the project level, there is a client side audit to validate that we are delivering what we said we would deliver in the execution plans.

There are IFC models handed over for each consultant. The native models are also provided. The federated model as an Navis and/or IFC is provided. The extracted asset register from the model with all the metadata is provided. And then finally, some coordination reports and any other reports that we've listed in the BIM execution plans are required.

Now, from the facility management side, a lot of this is to focus really on these core items that they've identified, so these system objects, major equipment, minor equipment, and miscellaneous. So it's quite a limited number of items in the model that need these asset data requirements, and it's not every single object.

But the contractor might ask for specific validation objects, say for quantity surveying or quantity takeoffs, things like that. So this is the client side, but the contractor is allowed to add additional requirements. Same with the design team in order to get internal or those lower-level benefits during delivery of the project.

Really quickly, also do some AsBuilt validation we provide back to the client. We use Drone Deploy for the site and the port capture. We use StructuctionSite and for photogrammetry and the 3D photos at a space and room level just as work in progress.

And then finally, if it's required, Matterport. We'll go and do a Matterport and just make sure the rooms and everything's aligned. Surveyors are still used a lot for the point cloud scan. So anytime something specific or a risk area or critical is deemed, those will be engaged separately, and we might have to incorporate their data.

So what I want to touch on now is the project workflows. So with the project workflows, this is a number of things that we look at, like who's involved in the project, how are we getting them the information that they need, what information do they need into the jobs, what's the contractual makeup, and then getting into the technicals of how we use the Autodesk Construction Cloud and what pieces.

So there's always a conversation beginning of every project because some contractors are using it Autodesk Construction Cloud completely. Others don't use it at all, and we'll manage the entire system on their behalf. So here's all this for? There's a really quick breakdown, all these smiley, stuckey people.

But most of the time, we're brought on by the contractor in this health space, So there's us, and usually we sit in with all these team members of the design manager, design team subcontractors. And we're really helping trying to focus on building tools to better bring in the design managers and the contract administrators into the modeling approach, because the more buy-in we get from them, it's better. And then they help drive that with the site teams.

On the other side of that is we got to make sure that all of these data sets are ready for the client side so that the client audit goes smoothly. There's not a lot of back and forward. There's minimum friction there. The data sets are all verifiable, and then finally, at the final handover and during practical completion, there's no major issues.

So that's who all this is for, but we really try and focus on building information repositories so the design managers can get involved. So then what does that mean? What do we do on these jobs? So for Autonomation, we really work on set-up and manage the solution. So we can set up and configure ACC to make sure that's working. We provide training around that. We do a lot of automated data extraction around the ACC data and help put that into Power BI charts and analytics that the teams can work with.

We do a lot of the interoperability, and then on more bespoke projects, we've actually been engaged, and then help with the FM asset integration, so building the 3D integration with these systems. For the client side work with the builder, we typically help with the scope negotiation, so making sure the BIM requirements aren't too onerous, taking into account feedback, and just making sure they're clear.

So sometimes, the BIM terminology is quite a third-letter acronym, so you get too much high level, I guess, language that people can't pross. So we turn a lot of things into plain language so the subcontractors then could clearly understand the required points. We finish the BIM out auditing plan. We generally help audit and then provide support around that, and then occasionally, we also do the design management support. So we will support the coordination workflow, support the issue and clash workflows, with the design management team. But typically, we leave that to the consultants.

What is the typical technology stack for all of this look like? So really simple. We have an IFC and Revit workflow here. We get the data in the health space from the dRofus databases. We pull in any site in AsBuild Capture Data. That all gets punched in through to Autodesk Construction Cloud, where we do all this coordination work.

And then if the contractor sometimes has its own common data environment for issue contract costs, the Construction Cloud is really just then used for the federation and internal working of the design and subcontractor teams. The other data is handed in there. The contractor CDE, and occasionally the client has its own CDE that we have to adhere to as well.

From an ISO-19650 lens, what that really looks like is this is the work in progress is done within ACC collaborate, the shared repository. Publishing and work sharing of models is also done with NACC Collaborate. Model Coordinate, the federation, we have a number of tools. So previously we used to use Navisworks. We have some Revista workflows as well.

However, we believe now with Navisworks 2024 and ACC's current implementation that most of this work can now be done all within Model Coordinate, which means there's just no transferring or extracting or exporting of models anymore. All of that exporting and federation is just automated with the Autodesk Construction Cloud platform. And then lastly, the publish and archive data is potentially on the same CD, or passed to the requirements.

So what does this look like? So at the top level, we have Autodesk Construction Cloud, and the features that we're going to cover is really around the design collaboration, so how we set up Revit work sharing. How we use the Autodesk Compare Tools and then extract all of that data into databases so we can start to do trending, which is a very, very powerful feature for design management and the contractor teams.

A breakdown of how we do the issues and clash management, both with ACC and Navis. We will touch on the progress. It's something we've started working on, but I've got enough content at the moment, so it'll be something for next year. And then lastly, how we're using assets. Originally, we did start using Takeoff, but we found some limitations, so we did have to swap the snapshot. But I will talk about that. But that's essentially our makeup at the moment for helping contractors deliver these projects.

So the work sharing approach. Bridging, which allows you to share models between hubs, is now out. But we are trialing it, but we're still finding that having the synchronized data between all the contractors' maze-like live linking work, which is a really easy way to manage this. Setting up publishing once a week is really important so that data flows into Model Coordinate.

We don't really restrict whether people want to use publish or consume, workflows or live linking. We let them control that. And then underneath all that, we have our own discipline called BIM, and we have our container files, which will link all of the other data from the Revit models to support the other workflows that we do.

So one of the other features that I really want to highlight is within design collaboration now, there's this feature called changes. And if you're working within the hub, of the nice features is between the last time you published and the last time you've synced the model, so published the Revit version out to all stakeholders versus syncing, you can now start to set up these changes.

So the structural engineer can watch the architects model for specifically structural walls to change. So what that actually looks like is something like this. I can click on changes, set this workflow up so I'm watching just so in the structural walls change. So without even seeing the model or needing to know about the models, the engineers can then click in here, and instead of seeing all the changes, they only see the changes that are important to them. So they can get an understanding of what work is coming up and how to target that work.

OK, so very, very easy and powerful way to just see the changes without having to open the models and do those compares. So saves a lot of time, and very simple setup. So with the model sharing setup now, what we're going to start to get into is just really quickly how we do these sharing setups. So what this looks like is how we set up the Revit container file and those sorts of things.

So what we normally do on these projects is, as I said, we let the consultants and subcontractors manage their own processes. We try not to get away too much in that, but then we have on top our Revit container file. That runs a bunch of extractions. So we send a bunch of data. We update the model with things like, we create room masses and things. I'll explain that in a little bit. And we send a lot of that change to the Autodesk Construction Cloud.

And then we also have some data extractors that extract a bunch of data that's just not easily accessible within ACC or the Revit models. We send that to our own database, which is built on top of BIM base, called trackworks. All of that pushes into Power BI, which then pushes back into ACC insights. So everyone can access that information.

So one really, really quick tip. When you're linking files for container files, definitely make sure you don't use the desktop connector. You'll lose links, whereas if you have a file that's cloud-shared set up, you can quickly use this external resource, then go through Autodesk Docs and make sure it's linked. So even if you don't have desktop connect, it will still pull all those model files together.

So with the automated extraction, what our teams will do is they'll open up this BIM container file once a week, twice a week. It depends where you're at in the life cycle of the project. They will then run a bunch of checks and processes that do the following. So first we'll run an automated check that will extract out all the data for non-compliance. So these are grids and levels that don't match. So usually, the architect model has the correct grid levels. So we'll compare that to against all the other files send out the ones that don't comply.

We will also create rooms as masses, and the value for this is by default, the viewer does not capture rooms as 3D volumes. So you can't have metadata. You cannot compare it to briefs and things like that. So by setting it up like this, we can color-code these. We can have them in the 3D model so they are available to stakeholders in ACC.

We'll also create clearances. We'll automatically create a ton of views, usually broken down by rooms, level ceiling space, and then all the disciplines separate. And I'll cover that shortly. We run the Autodesk model checker, which I'll cover shortly. We do some snapshot extractions, which I'll also cover shortly. And so we'll export all of this out to ACC and our Trackworks Tools. So a typical room export with all the disciplines might look like this, but then they're all broken down into their three disciplines.

All right, so what this looks like from a model validation perspective. So we use the Autodesk model checker. This is a really simple example of showing how it works with the interface. So you can open up a model, start running checks, and it's going to extract that data and give you a breakdown of the results.

Now, the way we do this is we set up a pretty comprehensive set of checks that are usually broken down by design phase and discipline. So each discipline gets the specific checks they need. So we have a Work In Progress Compliance, so that'll check if all the levels associated are the structural level.

So to be clear, we don't do data checks on here, as in the asset data. This is all about, does the model actually comply. Are there duplicate elements? Do any elements have warnings? Are there in-place families, any bad modeling practices? Because if the model fidelity isn't good, using it in these other areas downstream doesn't work.

Now, we can then extract all of that data and put it into these reports, and I'll show you how to do that. So after we've run these checks, what we get is something like this. So we get this Model Checker Report. You can see it's 68%. You include all the links automatically, and then the key thing here is we've got this Excel feature, Export.

And all of this can be automated. The details of the automation are in the handout. But once you automate that, you can automatically upload that into a database and start to pull all of this particular data and start to analyze it in ways outside of Revit. So again, this is where we can share these results with stakeholders automatically.

And so what does that look like? That looks like something like this where you can have your errors, and then all the stakeholders can say, OK, some people are on the wrong version of Revit. Ah, areas only, so the volumes haven't been turned on. Some models are not workshared. So all of these criteria that have been set up as non-compliance, they will have access to all of that in real time. And that's really useful at the technical level to resolve those issues.

Obviously, warnings. Again, not all warnings are important, but there are a lot that are especially like highlighted geometry, high overlapping geometry, duplicate instances. These are all things that will cause issues with downstream data if they're not corrected, so again, extracting all this information. But again, this is pretty low level for design managers. So what we've found and started to work towards a lot is this sort of trending. So we just aggregate that 68% score for each of the files and start trending it.

And so the design managers now and the contract admin, they can just look at something like this and go, OK, we've got the architecture model, and it's now fallen below our pass/fail line. So I need to go and engage with them. I don't need to know the specifics, but I can go and engage with them and see that, OK, they're starting to really fall below the thresholds of what's acceptable, and I know I'm going to get pressure from the client if we hand that over.

So again, really just abstracting the data to this level, and again here, you can see there was a file that fell below. And then the consultants have picked it up. So this helps the design management team and the contract administration team know how to help the guys get visibility into improving their deliverables during work in progress.

And then adding to all this, so really, really quick, I didn't want to get into it too much and I might skip over, but all of these cards can be added, and this includes Power BI dashboards as well. So in ACC and Insights, you can go load the internal dashboards. You can go load third-party Power BI dashboards. So again, this is about bringing all of the data to that centralized position so people can look at it and they can add those cards to their dashboards.

Now, what we're going to move away from is model coordination stuff. And now we're going to start to look at the issue management here. So what does that look like in terms of issue management? So this is our Navisworks workflows, our ACC workflows, that sort of thing.

So just a high-level overview. So we've talked about the Revit side. We've created these views. We created these room massing elements. We created some clearances. We published that data to ACC. So now we're going to get into how we use the Autodesk Construction Cloud Model Coordinate set of features and utilize those to understand what clashes are, just understand the views and the models that are in there, and interrogating those. And then we'll get into the depths of how we then integrate that with the Navisworks clash workflow.

So the reason we export all of those views is if I click on models now in Model Coordinate, every single one of those views is now here. And what this means is you share-- your non-savvy 3D guys can go, I'm just looking for room 3020. I can then see the arc MEP instruct disciplines. I can click on them, and now I can open those in the viewer. And just that contextual viewer, I haven't had to learn how to create section boxes yet. I haven't had to do all this hard work.

We found this is a really easy way to onboard people without delving them into all of these sort of tools that you'll see in a minute, and being able to find the information they want really, really quickly, being able to just see what they need to look at as well in context.

And so what this is as well is, as I said, you don't have to teach them all the filtering tools, which are very handy, but I find are useful at later stage and for deeper work. But they can just click, turn on these filters, and understand what's happening in those rooms. And this could be rooms, levels, structural framing, or any particular area of risk or importance that's needed.

Now, beyond just providing all of these as basic models, this thing gives the designers the flexibility to create their own views, their own aggregations of this information. So if they're happy with that, they can now save this. Maybe this room's of interest to that particular team, or design team, or site team. They can save this as private or public if they want to share it.

And now they've got that aggregated version of all of those disciplines as a view here. Now, one thing to note is this Save to Docs feature. By default, Autodesk Docs cannot federate models. However, your Model Coordinate administrators can save those federated views back to Docs so that any team members without Model Coordinate can still interact with federated models.

What this then looks like from the Navisworks approach is in-- with 2024, this is really important-- views are now a Navisworks NWF file. And what this means is I can open any of those views, like the view I created. And if I've already done clash reports, if I've set up search sets, if I've created views in Navisworks, that data is now stored here.

I can see the previous clashes. I can run the clash again. I can check out the report. And what's really powerful about this is I haven't had to append new models, update the models, reload the latest models or anything. Just as soon as you publish those data sets from Revit, all of that data is here available in Navis. So you never have to manage files again, and I can't tell you how easy that makes life for anyone who's doing the deeper coordination.

And then from here, you can still set up all your really detailed clash tests and that sort of thing. Once you've run those clash tests, one of the really, really cool features as part of that coordinate is you get this ability to group all the clashes. So this will give you a breakdown of the actual clash tests you're interested in grouping. You can then set how you want to group them. So I'm going to use the item name.

You can select whether it's the first file or the second file, so Arch or Str, which name to be used. We can then set today's date and group by these other fields. But then below all that, we get this example. So now we can see how that's going to group. So I can see it's basic wall, the idea of the wall, and how many elements are going to be grouped.

Press a group clash, and that's automatically going to group all the things in those tests. So really, really easy to clash and keep this data updated and keep all your active reviewed and approved saved as well without any file management. So super important tool.

Second to this is issue management. So once we've created all these clashes, how do we turn them into issues. So obviously, selecting all of these one at a time is really cumbersome, but there is this great feature where you can select the groups of clashes that you found important. And really key is this hidden button called Actions, Create Issues.

Now, if you've set up a view template, rather than typing in all the data, you can click on that template. That will automatically assign who the clash is for, which discipline, when it's due, what locations it's in. All of that information can generate all of those clashes as eight separate issues to be actioned now.

So again, very, very easy to get into the weeds, then generate a lot of the issues, unpublish them for draft if they need to be reviewed, and then share them with the entire team or within Navisworks, OK. Separate to that too, the other advantage of creating all of those Revit views is it activates the automatic Autodesk clash checker.

So what this means is, yes, you might have hundreds of videos in your model, but then you get a list of, OK, the corridor, the architectural view of the corridor, has 512 clashes. The AHUs use 464. So it's very easy to scroll and get a high-depth view of what the current clashes are in the projects, OK. But again, the challenge we have with just reviewing the clashes like this is it doesn't give you a rate of change. Are there more or less than yesterday? Is this better or worse than yesterday?

So this is where we have to just step beyond the bounds, and we created a simple little tool. You can do this just by exporting the Navisworks clash data to XML, and then open that up in Excel. and you'll get raw data, and you can push it through into Power BI. But you could also push this data into databases as well.

So we use our Trackworks Tool where we just extract all that data to the database, and then again, we get to move beyond single clashes to look at something like this. So this is where we start to get our general clashes, you know, how many are we getting, when are they getting closed out, how many are they getting, when are they getting closed out.

And this actually aligns with schematic DD and SD design over these weeks, and then how many new resolved clashes are happening week by week within Navisworks. You get this with issue management too, but clashes also have a separate correlation to issues, because issues are created by people where these are generated automatically.

So the other thing we'll move across from the clash management and issue management is really into scope management change. So scope management, there's some key areas here that we want to look at with scope management. And the first one that we want to start with is the schedule of accommodation.

So the schedule of accommodation is where you get the original brief from the client. And these days for us, on any larger project, we almost always get a dRofus, access to a dRofus database, and that'll have all the rooms required for that scheduled accommodation determined by the client to build it.

From there, the architect will start to build up the brief based on the inputs and site constraints. So the two key things we're worried about there is, does the brief change, have the requirements changed from the initial feasibility to tender, and are those getting tracked. Then we want to understand, has the plan changed. There are site constraints where we can't fit certain things or level the cares or something, so the architect has had to make changes that differ from the brief, OK.

So some of these changes are contributed by the architect. Sometimes they're contributed by the client or the builder. Now, usually, the plan changes should be connected to the model. And again, this is why we create those room masses and load them into ACC, because it gives us the ability to constantly see the latest takekoffs of that. Does the total room area meet the brief with the dRofus database?

They should be synchronized. Sometimes, there are cases where that doesn't happen, so just being alerted to that. And then finally, the change we want to know is, is the room still a standard room. Is it that AusHFG compliant? So all of the objects that are supposed to be in that room, has that deviated? If it has, we just need to understand why. Who triggered that deviation? Was it a stakeholder, a subject matter expert or something? And then just tracking that for the client.

So again, all of that data from dRofus can just be wrapped up and put into something like this. So this is a pretty simple Power BI dashboard. Again, it can be pushed all the way through, and we get an idea of the room templates or the brief, the room itself, so the actual changes. And we can see all of that detail. What are the old values? What are the new values? Who changed it and when?

And again, just allowing anyone in the design team to quickly go through and navigate those changes during the middle of a discussion without not having that data at their fingertips. Just again, makes a huge difference. And a lot of this is just about bringing this data to those who need it when they need it.

The other one is the Model Compare Tool. So comparing the difference between models is another huge one. So we can manage the brief and the changes within the brief within the database, but comparing data around the models outside of rooms is actually a little bit tricky. So Autodesk has this tool here, which is the Model Checker tool. And this is a fantastic tool for getting a change between two versions so we can see what's been added.

We can narrow down into that, understand specifically what's changed. We can see what's been deleted, and we can also see what's been modified. So again, this is that ability to drill down, but this only allows you to compare this between two versions of the file. So again, you run into this problem of, if people aren't in the Model Compare Tool, how do they get access to these changes.

OK, so what we ended up doing was all of this data. Sorry, I should just quickly show. All of this data can be extracted as a CSV, and that appears right here. You can just download it from this point here. Now, that is missing some information. It doesn't know what room it's in. It doesn't know these other things. So again, we bridge that data within and load that data up, and then add all this other data by checking where it exists in the model, what room it's in, what category it is applied to, all of that sort of stuff, push that into Trackworks.

And again, this is where you can start providing these high-level dashboards to your design managers. So a design manager can now look at, OK, what are the major items that are changing in this current phase. OK, walls are changing a lot. So walls changing a lot is obviously going to affect a lot of other disciplines, versus where if it's more the internal furniture and things like that, that's going to have less repercussion on other stakeholders.

Which rooms are now changing and what's changing in them? So I can see here this is all attributes. So I know this is metadata changes, and which rooms are undergoing the most metadata changes, so maybe some spec changes. Over here in transformation, these are the rooms where things are moving around. So things are shifting and that.

Then we can get into geometry and add and remove changes. Which rooms are having new items added to them and which rooms are having items deleted from them? So again, providing that ability without having to delve into the model of accessing these sort of changes, understanding that rate of change.

OK so where we started, then, taking us to-- is we did look at the Autodesk Takeoff Tool. And originally, we proposed that we spent a bit of work trying to get this tool working. So when I propose this talk, we said yeah, we're going to use Takeoff. We had the client convinced. We'd done some early proposals and we were like, OK, we'll get this working and get it through the approval process, and that sort of thing.

So what we found though, is that the workflow, basically, you can grab the models that are sitting on Autodesk Docs. You can then transfer them and the version into the Autodesk takeoff commands, and then you can start generating a package of work. And that package of work will then open the model up. You can set some filters.

You still have to manually select the quantities, and then it will extract those quantities so we can go and get the areas, we can go get the perimeter or the volume. We then select this. We select the actual objects that we want, and then that will assign it to a group of quantities and we'll get those totals.

Unfortunately, there were a few things that we just couldn't export, and I'll cover that in a second. So there was some data that you can actually see in the interface, and you just can't export it. So that made it very, very hard to trend. So things like element IDs, element category names, element names, these are all really important data points if you want to trend information.

So again, the goal here isn't to do a takeoff, because quantity surveyors do the takeoff. Our goal is to help the design manager understand the rate of change and what's changed since that last quantity extraction was done by the quantity surveyor. So you know, has steel gone up by 4%? Yes. What is the impact of that? There's 100 tons of [INAUDIBLE] added to the project. What is the implications of that?

So giving them those trigger points, the exact quantity doesn't matter. It's the rate of change that matters. So unfortunately, after a lot of trialing, we did have to shift to another solution. And so here's an example of this working. So what happens is you grab your version of the model, grab it here. So we have version 1.

When you select you want to move to version 2, it does has this really nice, handy tool where it goes, OK, I've compared between the columns. They're the same. I've compared between the slabs. They're the same. Now, you can see here wall types. There's a previous quantity and there's a new quantity, so there's actually a reduction. So you can then press the Move, and that will move that data across.

And then from there, we can start to look at those breakdowns. So there's my column slab, wall types, column slabs and then wall types, and then the individual takeoffs. Now, unfortunately, this is where the system becomes a bit unstuck. So what happened here is, for instance, you can expose this object name, but you can't export it.

So we were unable to export any identifying data. So all you get is this quantity, but you don't know where it is. The other issue that we did struggle a little bit is you can't define any rule sets to allow you to grab walls by wall type. You literally have to go through the user interface, and so it becomes pretty cumbersome in terms of grabbing that data.

So what we ended up moving to instead was the Bimbeats Snapshot Tool. So Bimbeats, again, we use a lot of their data on the database. You can set up this snapshot. It creates an Excel set of settings which basically says which properties you want to use, which elements you want to trend. And it will do a really deep dive, just grab all that data, timestamp it, and register that onto the database, OK.

And so all you have to do, again, is just open the file once the trending set, hit the Snapshot button, close the file down, and again, this can be automated. What this looks like, though, and what we're trying to do with takeoff, is extract that one-time takeoff data or that snapshot from takeoff into this trending.

So what this really means is now we can start to get an idea of, OK, what wall type. So this is just a dive into wall types, because in health care, walls are always the major challenge, because there are different wall types, because you've got to deal with the acoustic, thermal, structural. All of those sorts of things become really important, and then they get managed by the contractor in terms of then setting out.

So here we've got the walls. This is all in meters, the total counts, what the walls are for each of those phases, so which walls are most used. So are there any opportunities to amalgamate walls that aren't being used very often again to make it easier to install? But then second to that, we've got our walls by length.

So this is that trending. So this is a snapshot of a particular point, but now we can start to see where particular wall types are coming down, particular wall types are coming up. So again, over these time gaps, we can start to understand, OK, which will walls are being added, which ones are being removed, what are we getting more of, and then getting down into, we can look at a pretty high level by walls by count.