Description
Key Learnings
- Learn about organizing teams for integrated BIM and information management.
- Discover the skills and technology required for successful implementation of BIM in digital delivery.
- Learn from practical examples of challenges and successful outcomes from major transportation projects.
- Learn about making key strategic and project-oriented decisions for enhanced project delivery.
Speakers
- SHShruti HarveShruti Harve is a seasoned professional with over 17 years of experience in design, construction project management, and Building Information Modeling (BIM). Her diverse background includes roles within engineering and management consulting firms, owner's representatives, general contractors, and software developers, providing her a comprehensive view of the AEC project ecosystem. With a track record spanning multiple sectors, Shruti possesses a distinct vantage point on major projects. Her responsibilities have encompassed design, project and construction management, as well as BIM implementation for both transportation and facility projects. Having been immersed in the evolution of BIM since its inception in 2005, Shruti has adeptly tailored and executed BIM programs across all phases and elements of projects. From construction operations and technology to virtual design and construction, architectural design, and project management, she has consistently delivered results that harmonize technology and human expertise.
PETER STARNES: Welcome to our presentation on integrating digital delivery and BIM, where we will look at how two organizations, Mott MacDonald and PGH Wong, have worked together to set up a collaborative and connected environment to promote quality and efficiency on a major transportation project.
We hope that by the end of the presentation, you will see some of the journey that we've been on, how we've organized our team for integrated BIM and information management, some of the skills and the technology required for successful implementation, and practical examples of challenges and successful outcomes.
There'll be two of us presenting today. I'm Peter Starnes, digital delivery lead and BIM manager for Mott MacDonald. We're a global engineering design company working across many sectors. And my previous experience is mainly in the BIM production for the design phase of transportation sector and heavy civil works.
SHRUTI HARVE: And I'm Shruti Harve. And I have extensive experience implementing BIM across various project types. My professional journey has encompassed roles such as construction project manager, project engineer, BIM coordinator, and Revit instructor.
PETER STARNES: So this presentation is based on an ongoing project that Shruti and I are working on at the moment. So the BART to Silicon Valley phase II project for Santa Clara Valley Transportation Authority is a $9 billion project for a heavy rail extension through the city of San Jose and California. The project consists of four stations, five miles of tunnel and track, a storage yard, and maintenance facilities.
So we're going to look at some of the challenges that we've experienced on the project, and then talk through some of the ways that we've tried to mitigate those challenges, and hopefully, in some cases, we've come up with successful outcomes.
It's split into four main parts. First, about defining digital, what it is, and what are the expectations? And then how do we set up our team for success? After that, we look at the data and some of the issues and problems that we have with extracting and reusing data. And then lastly, we'll talk about complexity of models and some of the steps we've taken to make that information more accessible to our stakeholders.
So let's start off by trying to get some rough definition of what digital delivery and BIM management mean. The digital delivery refers to the use of digital tools and technologies for planning, design, construction, and management of projects. I think it's a reassessment of traditional processes to align and take advantage of new tools or working methods. And for us, digital delivery is made up from the five components that you see on the screen.
Digital delivery is a very broad scope, but basically it comes down to, how can we get a very high quality product to our client as efficiently as possible? And that efficiency may be doing something better, which adds value, doing it quicker, or doing it cheaper. And often, the speed and cost of producing designs are very closely linked.
For design firms, we generally charge by man hours. And so if we can automate processes and make the right information available on demand, then that cuts time taken to complete a task and allows some of that time to be reinvested into improving or refining our designs.
The old adage is that you can have a choice of quality, speed, and cost, and you can choose two of the three, but not all of them. But what happens if we can use digital integration to try and get all three?
SHRUTI HARVE: In our project, we put a lot of effort to communicate very precise definitions of what digital delivery and BIM are. Why are precise definitions important, you might wonder. The answer lies in the potential pitfalls of misinterpretation, which can lead to misplaced expectations and inefficiencies. When expectations are not clearly defined, meeting them becomes a formidable challenge.
Consider this scenario. Imagine asking one of your project team members to define BIM. One might respond by saying, well, that involves complete elimination of all 2D drawings, all 2D PDFs, and so they must be abandoned from the project.
Another person might come by and say, wait, is that the definition of BIM? I still use 2D PDFs, there is a place for it in the project, and how can we get rid of it? This lack of consensus can lead to resistance, confusion, and misaligned efforts.
We as BIM and digital delivery leaders might very well understand the definition of BIM and digital delivery, but have we communicated that clearly to all our project team members? This is a question for us all to reflect upon.
And just like a building's foundation must be strong, a successful BIM program must have the basics solid and sorted out. So the takeaway here is to ensure that we define BIM precisely for our project, for our project team members, and communicate that really well so that we're all on the same page.
PETER STARNES: I have a slide here for the project information model. And I think this is relevant to what we're going to be talking about. And it just tries to describe that overall combined coordinated set of information that accurately describes your asset at whichever stage of the project you're in.
So we have the graphical data, which is your BIM models, your GIS, your drawings, that show things in their physical form or their physical location. And then we have nongraphical data. This is information that might be independent of an object, but still coordinated or associated to elements so that we're able to interrogate it for further analysis.
And then lastly, documentation. Your traditionally structured information that's in typical standard types of documents such as calculations, report schedules, specifications. All of these data types together allow us to build a whole collection of information about an asset. But recognizing that that information comes in different forms and may be stored on different platforms, but still needs to be linked together.
And also just want to introduce information management. I think information management is the key group for allowing data to transfer relatively seamlessly between different software products, between different teams, and between different stakeholders.
Our information management is its own discipline. In other organizations, it may be known under different terminology, may not be in use at all, or may just not be recognized as a distinct function.
The information management teams often include a mix of people with different backgrounds. Some with engineering experience, others with big data experience, or programmers. And we see information management teams working at organization levels for project controls, but not necessarily specifically for engineering delivery teams.
So having defined what we think digital delivery and BIM information management, let's go and have a look at the teams and see how we set those teams up to help us deliver. A traditional team structure probably looks something a little like, this where BIM and CAD have links into the design team. Visualization and 4D will have links into BIM, but probably BIM doesn't directly have links to document controls and project controls for cost and schedule.
We recognized that we needed to reorganize the team structure if we really wanted to be able to make a difference in how projects are delivered. So we took the groups we think should be talking to each other the most, in terms of providing solutions, and then grouped them under this digital delivery umbrella, which has its own management team.
And then sitting under that, you've got BIM and CAD, visualization, 4D, but we've also brought in the document control team. So that allows us to really control file naming, version control, file metadata, record documents, all of these items that become part of our project information model.
You'll also see that we have information management firmly within that digital delivery group. Again, I think this team is really important for managing our data flows. By creating this digital delivery group and it's having its own management team, this provides leadership and oversight to delivery activities and allows us to identify opportunities or bottlenecks that can then be acted on.
It provides us with the authority to make changes, and a single voice reporting to management. I can't overemphasize just how important that is to affecting change.
We often find that we have maybe individual groups that are trying to overcome a challenge, but don't have the resource, budget, specialist knowledge, to be able to find a solution effectively. And then often, that challenge is dropped and we just move back to our traditional methods.
A digital delivery team allows us to control budget, bring in subject matter experts where required, and have people from each of those teams talking to each other on a very regular basis because they're all just part of a larger delivery team.
SHRUTI HARVE: We've taken a similar approach to how we structure our BIM team. Initially, it was organized as a separate entity following the traditional model, as you could see. However, over time, BIM has become the cornerstone and framework for all our operations, resulting in a seamless integration across the board.
So we've been able to break the walls that separated us from the rest of the discipline. What are the benefits of this approach? There are many, but the single most benefit that we've realized out of this approach is adoption.
There is not a single design coordination meeting that happens on our project without the use of 3D models. And I'm not exaggerating. If you come to our office and walk around the project office, you'll see so many monitors-- of course, you'll see a lot of monitors-- but everywhere that you'll see Autodesk Construction Cloud, you'll see the 3D model up there, everybody investigating the model, reviewing the model, people talking to each other using the model as their tool to make important decisions, to solve coordination problems, to communicate with each other.
And this is extremely heartening to see as BIM leaders and digital delivery leaders. And this wouldn't have happened had we not moved to a more integrated team structure where our BIM coordinators are so well integrated into the team that they are not viewed as a separate entity. They're are part of the team. And so this is a really important thing to do, is to organize the BIM staffing to ensure you're not separate, but you're very well integrated, the substratum upon which all the rest of the operations happen.
PETER STARNES: Let's talk about some of the data issues and how we've approached them. Earlier on, we identified some of the problems that we have with data, where we're not able to physically connect bits of information together, whether that's because of the platform or the file type limitations, and we couldn't get data to integrate because that data formatting was wrong. So the individual values or properties of a value didn't match up.
For our project, we spent a decent amount of time at the start looking at different pieces of information that were likely to be created, the different end uses, and from that, we built up the system architecture to ensure that we had native files in one location only, but making renditions of the whole file, or subsets of the data within a file, available and transferable to other platforms and software.
The processes were roughed out initially enough to allow us the right information to build a robust architecture. And those processes were documented and refined as the project is developed. But you don't need to have a fully blown step-by-step process at the start to be able to create that initial information ecosystem.
Common coding is just as important as this system architecture. For our projects, we base coding either on an ISO 19650 standard for file names or on the work breakdown structure for a lot of our field metadata. And then finally, we had a unique coding system for asset elements.
This common coding not only ensures consistency across the project, but it also allows us to link discrete pieces of information that have been generated by different teams in different software for different purposes to then be consolidated for further use.
For instance, the design units identified within the scope are replicated in the model packaging strategy of the BIM models. Also, in the fields used within the file naming structure for all document types, not just models and drawings, but also calcs, specs, reports.
And then that same coding structure is applied within the BIM model itself, where identification coding for levels, rooms, asset tagging, and also uses that same naming system. And this makes it much easier to link up the separate discrete pieces of information.
The coding does not necessarily need to be exactly the same formatting, as long as there is a clear mapping between them. However, the use of the same exact codes makes life far simpler, easier, and quicker to both provide solutions, and for the end user to quickly understand the information that they're looking at.
Next, let's look at the data that we're creating. BIM alone creates a huge amount of information. Just by creating a column in Revit, you've got a shape, you've got a size, you've got a location, you probably already have some default materials, possibly some schema attached, whether that's uniformat or something else.
And it's easy to start in adding in construction sequencing, other metadata, into any of the fields available. I doubt that there's anybody who really understands all of the information available inside of a inside of a BIM model.
Recently we've been pulling out model data using Autodesk Platform Services, or Forge, using the available APIs. And we had a massive dump of data, millions and millions of lines for the project files that we have. And it was a really overwhelming task to try and sort this information out into something that was both manageable and useful.
So how did we approach this problem? Well, the first way is we have a general idea of what we're trying to achieve. And then we've gone in and we just pulled out a huge mass of information and started to try and filter and sort that info to get something that we think is useful.
We then throw that out to the team, putting it into Power BI dashboards, or into Insights, or somewhere else. And then effectively waiting for that feedback, or prompting for that feedback, to find out which of that information is really useful and fits into existing workflows, or which just looks interesting to them, and perhaps they weren't aware that information was available. And then we can really start to refine and build something really useful.
The alternative way is to clearly define the requirements. And there are certain specific tasks where we're able to do that, where we're already looking at existing workflows, identifying that perhaps information is being extracted from BIM models in less than optimal ways. And we're able to start to automate that task.
We still have the issue of trying to find the core information, and how do we extract it, but if we know where-- if we know where it is and how it's named, we can normally create a process that is quick and efficient because it's only looking at smaller amounts of data.
So we've looked at how we set up our system, architecture, our naming conventions, how we can leverage document control to enforce consistency across the projects. And we've pulled information from BIM models or elsewhere. But how do we then visualize that data to make it really accessible to the project team?
We have a variety of tools available to us. ACC is an excellent data viewer. In ACC, we can see file properties and custom file metadata. We're able to see the files themselves in 3D. We can interrogate properties of elements that we select. And we can very quickly see changes between models. The drawback is that we're only looking at one piece of information at a time, whether it's that particular file, that particular piece of metadata, file contents, or the elements themselves.
So we can use other Autodesk or other third-party tools to display project information. Assemble is an Autodesk tool that we use fairly extensively, in particular, to transfer quantity information from our BIM models to our cost estimators.
Assemble's great in that it will automatically extract quantity information and provide methods of visualizing the data and the model element at the same time, whilst conditioning the model is using the available metadata properties. So coloring different parts of the model to make it easier to identify.
And then Power BI is a common tool that organizations are using to display project-- to control information, but it's equally powerful for engineering content. And the nice thing about Power BI is that we can embed that information into SharePoint pages and make it available to a wide range of people. And it's great for just consolidating lots of different information into one single source.
I'm just going to show you some quick examples of where we've applied some of these processes. So first up, we've identified a problem where we were struggling to track files across multiple folders, especially if the files get renamed. The search function in ACC is not bad, but can be difficult to get it to show you all the information that you want across a whole project or site.
So we've used APS an Autodesk APIs to extract file information from ACC, saving it into a cloud database, AWS in this instance, and most importantly, keeping the historical information as the versions change. So this has allowed us to not only build in Power BI, an effective viewer of our model and drawing files that allows advanced slicing and filtering, but also allows us to track files using their unique ID.
And now we're able to search for files using a previous name to find out what it's currently called or to search for previous iterations of a current file. And this functionality is proved to be really useful, save significant amounts of time when it's been needed, and has replaced a manual spreadsheet method of tracking file name changes.
Second up, it's about people management. We collect quite a bit of information about our staff on the project. And most of that information is collected during the onboarding process, where we're using Microsoft Forms, Power Automate, and SharePoint List to record user records.
We also have ACC user accounts where separate information is stored about who has access, what their roles are, what level of permissions they have. And the ACC members list is not great for searching and filtering. It doesn't always show you the information that you need or will do so only for one member at a time.
By extracting this information, again, using APS and Autodesk APIs, we've been able to link that information up with our mobilization data to create a holistic view of all the ACC users within the Power BI interface. And this gives us a really useful tool to quickly identify team members, access permissions, training records, reporting lines, and contact information all in one place.
My last example here is a unified dashboard. We're all generally bombarded with huge amounts of information every day, whether it's from emails, Teams, or Zoom messages, and we wanted to build a solution that would allow us to bring as much information together into one place as possible so that we weren't searching across SharePoint, ACC, Aconex, ProjectWise, wherever your data is being held.
And to that end, we consolidate all of our different dashboards and information into a single Power BI app interface. And this way, team members can look at that information that they're interested in on a daily basis. And it's presented to them on a web page that can be set as default page in their web browser. And then every morning, as you start work with your cup of coffee, you can get a quick update of what's going on with the project.
On the screen, there's a quick example, you can see under the Autodesk Construction Cloud, we've got general table of contents for our work in progress area. We can quickly see what's recently been published. We can see select a file, and then see all of the previous versions and when they were published.
We have metrics in there. The previous file names that we've just talked about there, file path limits, anything that's exceeding the 255 character, again, we quickly identify those. So a huge wealth of information, and that's just one small subpart of the unified dashboard. Right. Over to Shruti to talk about complexity.
SHRUTI HARVE: Complexity, that's not what our project team members want to hear. They want everything at the push of a button. They want everything simple. It's not possible to achieve that, but on our project, the underlying principle for designing all of our systems has been, keep it simple.
If we cannot communicate something simply to our team members, that means we pause, we reflect upon the process, and we redesign it so that we can look at it and see how best we can communicate it to them.
What has this done in our project? This is promoted adoption. It has required fewer resources to implement and to maintain. It has been quite efficient. And we've been able to do more with less. And we have been able to direct our resources to do more intelligent things rather than maintain-- put them at maintaining things that are quite mundane, doing the same things over and over again.
Also, our project, like all other projects, are always constantly changing in requirements, project direction. And with this simple framework, we have been able to quickly adapt to those changes. We've been able to modify our system and be able to scale up or down based on the changes in the project direction.
So next, what going to talk about is some examples how we've implemented this design principle. Now we're all familiar with model coordination. We're all familiar with model federation.
And the traditional method would involve a BIM manager collecting all the models, first of all, bugging people to upload their models then collecting them. Then having a coordination meeting where the BIM manager would have gone through and found out there are certain clashes, bring them to the meeting, talk about it, only to find out that things have already moved ahead.
And people have moved on. They've solved the clashes and they're on to some different issues. There is a time lag. And there's processes to keep repeating over and over again. But with implementing model coordination in Autodesk Construction Cloud, and with how we have set up our folder structure, we have set this process to be on an autopilot.
And by autopilot, we mean that we're not having that BIM manager-- waiting for that BIM manager to do things. That BIM manager who used to be a roadblock, in a sense, to keep things moving. That's gone away. And people on the project, from project executive all the way to the project engineer, to the CAD drafter, to the project manager, everybody feels empowered and feels confident to use these models.
How is that possible? That is possible if A, we keep it simple. Of course, we train them, but we've heard this all the time. I trained people on my project. This is a common complaint. I have said this so many times and nobody listens. I've said this in every meeting and nobody follows the process.
And that happens on our project, too, but when that happens, we usually pause and say, OK, maybe we have not communicated this properly or, yes, people are not paying attention, but that could also reflect on whether our process is too complicated, right?
And so we take note of that. We take that very seriously. And we quickly redesign it. But because our underlying framework is simple, we are able to be flexible and adapt to the changing requirements of the project.
And this is another example where our folder structure again is very simple. It caters to the automated model coordination in ACC. We everybody on the project is empowered to create federated model views. And everybody does that. And it's so gratifying to see.
If a project manager has a question about, what is the conflict between the MEP model, or a pipe and electrical conduits, instead of calling the BIM coordinator, we've set up the system in a way that they go into model coordination module and create these views by themselves.
And then if they have a question, they can call the BIM coordinator if they're stuck. But for the most part, people are using this as a self service, which is a great win for us on our project.
So next, we'll talk about some of the insights we've gained from working on this project for three to four years, from where we've started to where we're at now, and our journey from resistance to adoption to being integral part of the team to no one even questioning why we're doing them. Everyone's convinced and they're practicing it.
So one of the biggest insights is setting the right expectations. This is so, so important. And this ties back to what Peter started with, which was having precise definitions. If you can define this for the project well, if you can get everyone on the same page, then we can also set the right expectations.
So we want clearly defined expectations [AUDIO OUT] digital, doesn't mean you can just get everything done by the press of a button. It doesn't happen that way. So then what happens? So that expectation, setting those expectations, is so important.
And how can we set these expectations? We can have trainings, we can have workshops, we can have meetings. But to formally do this properly, we've utilized four important documents to which we've done this.
One is the BIM execution plan that we are all familiar with. One of the insights from the BIM execution plan is to keep it concise, keep it ready to the point, avoid lengthy information in there.
Then we've got the document control plan. We've got the quality management plan. These are important documents that should not be bypassed. And then there is also the information management plan that ties in with the digital delivery team and how information flows from one team to another, from one phase of the project to another. Peter, you're on mute.
PETER STARNES: So there's no tool out there that's commercially available that's going to do everything that we want it to do. While some software claims to be a one-stop shop, in reality, we need to use a multitude of specific tools to achieve what we need. However, even then, there are still gaps in the information that we need to fill ourselves.
Autodesk, for instance, recognizes that it doesn't have the capability to meet everybody's specific needs. However, it provides the tools to be able to dig into the data, whether that's APS, APIs, direct exports. And we should be leveraging our information management teams to help us dig that data out and make it as available as often. And often it's the small things that really make a difference to our working lives.
When creating solutions, I think we need to build some flexibility into them. Projects change, some of them quite a lot, as I've found out. And we need to be flexible enough to change quickly with them.
Digital teams are expected to be innovative and agile. And don't let that development go to waste. We do a lot of innovative work, especially on perhaps our larger projects, and we should always, in the back of our minds, be thinking, how can I take this solution and reuse it elsewhere on other projects so that we can really get the most benefit out of our investment?
For my last slide, I just wanted to show you these images. I expect everybody has seen these graphics before. It comes some James Clear who wrote the Atomic Habit book. And just demonstrates how a really small change, but on a frequent basis, can result in really big changes.
So that 1% improvement every day makes you 38 times better over the course of a year. Maybe a little bit challenging to do that. But if you were just to do it to get 1% improvement efficiency a week, or a month, that's still a huge amount, a massive amount of progression over the year. So the point is, lots of small incremental changes can be just as effective as a large single effort. So look for those gaps and see how we can fill them.
SHRUTI HARVE: Finally, we'll summarize some of the takeaways from this presentation and what we've learned implementing BIM on this project. By combining digital delivery and BIM effectively, our design and construction projects can benefit from improved communication, reduced errors and rework, and have better cost control, enhanced facility management throughout the life cycle of the building.
Very important to build a team with the right skills. And not only that, but also integrating them with the rest of the team, making sure that they don't work in a vacuum and this notion of separateness is dissolved. Then setting up the system architecture with data transfer in mind.
So a great tool comes out, oh my gosh, this is fantastic. This does most of what I want to do. But wait, it doesn't do this. Well, if it doesn't do that, can data from there transfer into the rest of the system architecture? Keeping that in mind has been so important for us on our project.
Looking for opportunities to connect and reuse data, super important. And then finally, keep it simple, keeping our system simple, and your system simple, will make sure that you're very efficient with your resources, with your time, that can be utilized more intelligently and also will improve adoption.
Thank you very much for attending this presentation. We hope you found it useful. Thank you.
Downloads
Tags
Product | |
Industries | |
Topics |