2023 BIM Manager's Handbook, Volume 1: A 10 Million-Square-Foot Giga-Project

ANDREA ALLAS: Thank you, everyone, for coming to my presentation, the 2023 BIM Manager's Handbook, Volume 1, 10 Million Square Foot Giga Project.

My name is Andrea Allas, and I am an associate digital design specialist at Buro Happold, where I lead BIM and digital design strategy for US building systems. I've also previously presented at AU in 2020 on the work we did during the early days of the pandemic to fully convert all our active projects to BIM 360.

I have been using BIM and Revit technology since my years studying architectural design at Pratt Institute. And once I entered into the industry, it became apparent that my Revit skills were highly sought after. And it became my area of expertise and eventually my career.

Over the last several years, I have been fortunate enough to work on some of the largest and most prestigious projects in the industry at Buro Happold. And it is the work that I do on these complex projects that motivates me to push the boundaries of BIM and technology and stay involved with the latest emerging industry trends.

Buro Happold is a global consultancy based out of the UK, with offices in Asia, the Middle East, Europe, and North America. Relatively small in comparison to other global consultants, we distinguish ourselves through industry thought leadership and core values of diversity, sustainability, and responsibility.

Now we can move on to the project. A little over a year ago, I was called into a project meeting that began that began with, so there's this project. As the project is currently still under active design and under an NDA, I will be referring to it in broad terms.

The consultants at kick off were the design architect, landscape architect, civil engineer. And Buro Happold was lucky enough to be awarded contract for structural engineering, MEPFP, AV IT security, vertical transportation, and acoustics on the project. We had 12 weeks to complete concept design and an additional 20 weeks to work on schematic design, at which point the client would review the schematic design package and we would be discussing DD and CD timelines after.

The project's scope is 10 million square feet of built space sitting on a 600 million square foot site, with multiple buildings in the luxury realm, ranging from transportation, recreational, commercial, to name a few.

Imagine this is the project site. In plan, it looks something like this. And in perspective, it looks a little more like this, with most of the buildings spread throughout the project site and no more than one to three stories each. But as you can notice, there is one portion on the top left that's different from the rest, which I will refer to as the towers.

The towers alone account for half of the total project square foot of around 5 million, with the other 5 million square feet being a sum total value of the rest of the buildings combined. The towers are the most complex and largest portion of the project and also the first to begin design, with all rest of the buildings following after in a staggered timeline.

To be able to manage all of the scope, Buro Happold decided to split the project between the US and UK, with the US taking on management of the towers and the UK managing all the rest of the buildings. And that was how I found out that I was part of the largest project at Buro Happold and what would become the most complicated project that I have managed to date, with only one thought running through my mind-- how are we going to do this?

So managing a project of this size is going to be challenging and have its obstacles. But ultimately, it's no different than any other project if you have a good process in place. So let me start off with asking, what is a BIM manager?

So everyone here understands the approach that Buro Happold takes to BIM management is one of leadership. Myself and my team are responsible for leading the designers and engineers down the best path towards success, using the various tools and technology at our disposal. We achieve this primarily through a lot of front-end planning and upskilling of the team as and where necessary throughout design.

If I've done my job right, I'll spend little to no time in the models because the team has been empowered to successfully troubleshoot their own problems, and the models are easily maintained. This frees me up to be able to do more fun things, such as running VR sessions with the client or developing new tools.

Shown here is a process that I have developed through working closely with the project managers at BH. This workflow is based on the understanding that proper BIM management is an essential component to any project's success. Throughout this presentation, I'll be showing you step by step how I was able to apply this process to my giga project so that you can also learn how to apply it to your own projects, no matter the size.

We'll begin, as I did, with step one, reviewing the contract and BIM requirements. Included as part of the contract package was a document titled BIM Employer Information Requirements. This was a 45-page document with corresponding appendices that outlined in detail the exact role the client expected BIM to play in the project. Some of these expectations were easy, like LOD, LOI, or an outline of the BIM execution plan.

Other requirements added an additional level of complexity, like the Master Information Delivery Plan, or MIDP for short. This was a spreadsheet that tracked all files in the project and was formatted for use with Aconex, Oracle's project management platform. This platform is billed as a common data environment built on trust, meaning no file, once uploaded, can be edited or deleted.

In relation to BIM, this means that all naming conventions, including sheets and models, need to adhere to the strict naming conventions for successful upload. And the naming convention could have up to 10 track values referencing different naming tables depending on the type of document being submitted, which isn't the easiest type of sheet numbering strategy that I've ever come across.

In addition to the MIDP, there was also an extensive QA/QC checklist, which was also a submission requirement. This spreadsheet was broken out per discipline and could have up to 70 lines of checks. Once again, some of these were easy, like removing unnecessary links or ensuring that metric system units were being used. Others would really test the team's capability, such as ensuring that all model disconnects were cleared and working to clear all clashes in the model and deliver a clash-free model at the end of design.

There was also a line saying that no individual model could be larger than 350 megabites in size. And the entire design team agreed that this was too small, and we got that revised to 800 megabites.

So once you're able to understand the expectations of the client, the next step is to understand the team that you'll be working with. It's important to understand the external team because the external team can have just as big of an impact on your project as the team that you're working with internally.

One of the most important questions that you should ask when thinking about BIM management and model setup is what kind of software is everyone using? On this project, at kickoff, the architect was doing the majority of their work using AutoCAD and Rhino, while the civils and landscapes teams were working in Civil 3D. And then, internally, Buro Happold was working primarily in Revit. Having to coordinate all of these different types of files and data has a huge impact on early project setup and how I manage workflow amongst all the consultants. Luckily, we were all working on Autodesk Construction Cloud, which helped immensely with ensuring file management and information exchange happened swiftly.

So after looking at the external team, you need to move on to looking at the internal team and how you, as the BIM manager, can best support them. So at BH, most projects typically get assigned a single BIM manager that works with the team from project kickoff through to CA.

On this project, knowing the complexity and size, I relied on a robust BIM team structure that included members of the design team to help share in certain BIM management roles. Starting from the top, we have the BIM manager and the BIM team. So we would handle all project modeling standards, organization, and auditing. We would also be the main conduit for all internal and external BIM coordination.

Other tasks such as upscaling, scripting, tool development, deployment, and model population would be shared with members of the design team to support the BIM management team. For example, the discipline BIM lead was a chosen member within the design team who was a known BIM expert and who could help train their colleagues in specific areas like electrical circuiting or storm drainage calcs. With this approach, I was able to build a BIM team that was small but able to manage a project of this size.

Even with a structure like the one that I just outlined, I knew that the project would need more resourcing than what we typically allow for a project. And so here you can see the spreadsheet that I came up with to itemize all of the tasks that the BIM team was expected to perform. And I subdivided it into three main buckets of work for project setup, ongoing support during design, and the work that we would need to do around a deadline.

So I allocated hourly values to this so that the project manager could understand, in a resourcing and monetary aspect, the amount of time that it would take for BIM to support the project. And if you notice the hours needed per week, this is how I was able to sit down and discuss with my project manager and prove to him essentially that we would need more than one BIM manager to support the project.

So ultimately the BIM team that would help lead the towers work within the US looked like this at kickoff, where there was the overall BIM manager in charge of the entire project, and then there was myself leading building systems for the towers, with another individual directly working below me, and then with the support of the discipline BIM leads like I illustrated previously. And then there was a similar structure for the building fabrics groups.

So then, using a team strategy like the one that I outlined, the hope is that delivery of a BIM project looks less like this and a little more like this, where we can get from point A to point B in a straightforward manner.

So once you understand the team and you have a full understanding of the project BIM requirements, then you can begin to understand how to actually set up the project. Personally, whenever I set up a project, I like to think about what it will look like during CDs and work back. Strategic early planning at the start is the best way to avoid project headaches later on.

And since I'm part of the US team, I'm in charge of the towers for the building systems groups, which is technically eight different disciplines. Even at 5 million square feet, according to the project brief, this is considered to be a single building, although when you're trying to tackle management of this, the best way that we found was to tackle it according to the subprograms, like you can see here.

So the towers are split according to five major programmatic areas, where you have three tower groupings which are all connected at the base by a podium with amenity areas interconnected throughout. The percentage values show the percentage of square feet roughly that each of these towers accounts for of that 5 million. And each one of these individually can be their own entire project in their own right. And with this understanding, I took that into account when I was considering how best to set up the models.

So once again, when I think about how I can set up a project, I think about what the project will look like at the end of the CD phase because that is when a model will be fully populated with all the elements, and the team is most likely to be using LOD 300 families, possibly even LOD 350 families. And then I also need to consider the kind of data and analysis tools that the team is expected to use on the project because some of these tools don't work as well with models that are too complex or too large. My goal is always to have a model at setup that performs just as well at the end of CD as it did during SD, and that I will not have to go back in and make any major modifications to the setup after I've held the kickoff.

So there was also the size limitation that I mentioned when I was thinking about how best to set up these models. I took a very safe and proactive approach and decided at the start to fully split the building systems instead of holding it off for later. This way, I wouldn't have to worry about needing to break apart different building systems, which could cause corruption issues. And I was also comfortable knowing that no matter how much information was populated in these individually smaller models, that we would always be well within that 800 megabyte size limitation.

And then also one of the things taken into account was the program that I mentioned, so the five different programmatic splits, as that was the main organizational strategy that the design teams were using to form their teams. So the best way was that the BIM models would also follow suit with that organizational structure.

And then lastly, one of the major factors that I was thinking about when setting up the models was the number of users. Typically, I also like to take a very conservative approach when thinking about how many people are active in a model. And I usually like to have no more than six individual users in a model at any given time. And this is primarily to avoid issues like ownership or long sync queues which, once again, can become very problematic when you're closer to a milestone or when you're working during CDs and the team is at its largest.

So taking these factors and several others into account, I ultimately made the decision that we would have five different discipline models split six different ways. And I ultimately ended up with 30 individual models to manage for the towers. And this followed suit just like the architect did, so they had five models, whereas the structural team was able to combine the tower models into a single one, and they had three models.

And then, once I understood how the actual Revit models themselves were going to be set up, I also needed to think about the sheet setup. So once again I took a very proactive approach when thinking about sheet setup, both because of the volume of sheets that would be needed for the project and also because of the Aconex naming standard which I mentioned previously.

So as you can imagine, 10 different values for a sheet number can become very confusing and very difficult to understand. And so, because of that, the design team collectively agreed that we should have a smaller, more easily tracked value, which we called the design team drawing number. And so these two values were what would be used on the project and assigned to every individual sheet.

And so, because of that, I set up an entire spreadsheet that fully populated all of the types of sheets that would be needed for every discipline, so all of the sheet series. And I was able to fully populate all of the sheets that the project team would need through to CDs.

And this was primarily because of the use of Aconex because, like I mentioned previously, not only is the naming convention complex, but also, once you submit a sheet, you're no longer able to edit it or modify it. So if I needed to swap out a sheet and change the sheet number, I would not be able to do that. If I wanted to remove a sheet and no longer be able to submit it, I wouldn't be able to do that either. So to reduce the amount of sheet reordering and changing that usually happens on a project, we decided instead to populate every sheet that the team would need so that we would better be able to manage this complexity throughout the entire design.

And then, of course, we made use of Autodesk Construction Cloud. And this honestly was probably one of the easier decisions that was made amongst the team. So we use this to host all of our shared design models amongst all consultants and as our main platform for BIM management.

Folder structure and permissions was key when organizing this with all of the external consultants to ensure people were seeing the information that they were intended to see. And also, use of design collaboration saved incredible amounts of time when transferring information amongst the team. We've also begun to make use of the markup functionality on the cloud for users who aren't in the models as frequently but still would like to be able to review the design and track its progress. And so we've been able to make full use of ACC throughout the project.

And then the last step that I perform as part of my project management process is to hold a BIM kickoff meeting with the entire internal design team. We cover important aspects such as the model setup and ensuring that everyone understands how to navigate not only throughout the BIM model, but also navigate throughout the cloud because this is still somewhat new to some users.

And then there's also important scheduling information that needs to be discussed, such as how frequently are models being exchanged amongst the consultants, as well as letting people know well in advance whether there's going to be any days that the model will be unavailable or when frozen backgrounds are scheduled to take place.

And then, of course, with so many team members, everyone needs to have the key resources available, things like knowing who is the best contact, both externally and internally, as well as any helpful resources or how-to guides for those who are still learning. Also worth mentioning is best practices for the entire team because it is everyone's responsibility to play a role in model integrity throughout the entire project.

And then we also make sure to dedicate time during the BIM kickoff to discuss computational tools on the project. So this is the opportunity for everyone for anyone and everyone to discuss whether or not there are tools that they would like to use on a project that perhaps they themselves haven't used before, so they would like to be upskilled in that. Or possibly, if people have ideas for new tools that they would like to develop, they can also bring that up during the group so that we can understand how to incorporate testing for it and if there's any additional resourcing required to develop these new tools.

This kickoff meeting is essential to establish a good precedent with the design team. It's so that the team understands what they're getting into in terms of BIM, but also the role that the team is expected to play as the BIM users in the model, and also how they can best work with my team as the BIM management team that supports them.

Once the BIM kick off is held, then we release the models for everyone to begin work. And we enter into regular design. Once into regular design, project management enters into more of a support role. And support means communication. And on this project, it means a lot of communication.

So here you can see this is an example of the regular weekly meeting schedule that we had that was only focused on BIM items for the project. So you can see we have specific individual meetings with the disciplines where we can discuss with those discipline BIM managers that I brought up earlier in terms of the BIM structure. So that's where we can understand is there anything specific to those teams that needs to be done? Is there anyone who needs very specific training sessions? Is there anything that they require in terms of support from BIM? So that's what those individual meetings are for.

And then, of course, we have the various management meetings amongst the BIM team, both internally and externally. So we had a regular external BIM meeting with all the consultants as well as internal BIM meetings amongst all the different BIM managers on the project.

And then what you'll also notice is that we have regularly scheduled clash coordination meetings because the BIM team was also involved in ensuring that we were meeting that project requirement for clash, for delivering a clash-free model at the end of design because we like to take, once again, a very proactive approach-- that the best way to resolve a clash is to not have a clash to begin with. So this is just an idea of the amount of communication that was going on and one of the ways that we strove to achieve it.

And then, in addition to this, we made sure to open up channels of communication so it's not just through meetings that people are able to get in contact with the team. We had a very active thread where different users could post information and also where my team could post information that is easily accessible to the team. So that's one method of communication that we were able to keep very active throughout the project.

And then also was the BIM task tracker. So this also became a key component of BIM support and BIM management throughout the project because as and when different people on the project would need to alert my team to something that they would need help with, this was how they were able to put that onto my team's radar. So you can see we had our regular meeting on this schedule as well as different tasks assigned to different specific members of my group.

And this way we were able to stay on top of the various tasks that were needed by the team. And the team could also see who was actioning that task and when they could expect it to be delivered by, which greatly helped with ensuring that we were able to keep up with the pace of the project and all of the various needs of the models throughout.

So beyond the communication, I also talked about upskilling happening during design. So upskilling happens at every level of the project because there's various different skills levels of different individuals. And my team's responsibility is to ensure that everyone on the team is able to fulfill modeling requirements according to their role. So we can upskill in just fundamental Revit usage. Or if there are specific Dynamo scripts that users have seen and they would like to deploy but perhaps need help making modifications to it for the project, we help with that as well.

If there's any specific plug-in tools that they would like to use, this is also an area where the discipline BIM lead comes into play because plug-ins, of course, can be specific to the different tools that they're geared towards. So if it's an analysis plug-in, for example, that's something that we can pull the discipline BIM lead in to help train their colleagues in. And then, of course, there's also new tools. We're always looking for new ways to use tools or develop new tools for use on projects.

So the workflow for that would look a little bit something like this, where an individual would bring a new tool to the attention of the BIM team or the BIM manager. We would then assess different uses for the tool on the project and whether or not there are any additional prerequisites that are required for use of the tool, such as specific software that needs to be installed or if there's very specific types of data that are required to be populated in the model that the tool will be looking to pull.

So once we identify the users that want to be upskilled in this and also ensure that they meet all the prerequisites, then we take the time to actually live work usually on the project in the project model using these tools. So then we test it and retest it multiple times to ensure that everyone knows how to use the tool and also that it's functioning the way that we expect it to function, if it's something in development, because fixing bugs is also something that we get involved with when it comes to new tool development.

So then when you're working through this process and you're working very closely with the engineers and you've finally gotten the tool to a place where it's relatively stable and functional, then, of course, the idea is that that individual user can then deploy that tool on their other projects. And then they can also be that discipline-specific BIM lead who can upskill their colleagues on their other projects. And of course, we continue to develop and refine the tool going forward.

And then let's not forget the ongoing model maintenance tasks that are required for any project. And what's most important when it comes to model management is to establish the rules for the team. So once again, with the support of the BIM management structure-- and also this is what's discussed during the BIM kickoff-- we establish what the team is expected to do and what they shouldn't do.

So things that they should do are things like make use of the work sets in the project. Or when opening a project, they can close any work sets that aren't necessary so that the model can open up faster and perform faster on their machines. They're also encouraged all the time to ask questions.

Once again, going back to my slides previously, communication is key on a project of this size. We don't want anyone to feel like they're not getting the support they need or that they don't know how to use tools. So ask questions. Make use of smart schedules. We don't want anyone manually editing text or drawing lines in a project. We want to be using the full smart capabilities of BIM on the project.

Other things like using multiple views when modeling-- that plays into that clash prevention I talked about previously. You always want to have multiple views open when you're modeling to ensure that you have the full spatial awareness of the elements that you're placing. Make use of the view templates that we have established so that the graphics that are required on the project whenever you go to print are in place.

One of my personally biggest things is ensuring that the users synchronize frequently. What I never want is for someone to tell me that they lost work because their computer crashed or their battery died and they forgot to sync. And then, of course, also once again making use of the smart capabilities, like smart tags.

So these are some of the things. They may seem relatively fundamental or basic for some of you, but I have found that it never hurts to reiterate these basic rules of engagement because sometimes people forget. And it's always good to reinforce the best standards on the project.

And then, in line with this, we also have what not to do on a project. One of my biggest things is, I always tell users to never leave a model open overnight. They should always synchronize and close their models at the end of the day.

Also big on this project is to not download any external families. We have a very large, very comprehensive database of internal families and the project requirements. And that QA/QC checklist I brought up earlier has very strict requirements about the types of information that are placed in the families. So that was also a big rule on this project, to not download any external families unless absolutely necessary, at which point they would get the BIM team involved in that to ensure that the family that they would bring in meets the project requirements.

And then, of course, there's also that big one to not modify sheet numbers, because then it would have a huge, cascading effect on the project submittal. So that was also a big rule on this project as well as, of course, this project was being done in metric standard units. So no families that were developed for use with imperial projects could be used.

And of course this is a standard one, but also be sure to not accidentally upgrade a model. And also don't do things like element hide. There's various different ways that you can control graphics using Revit, element hide probably being the least useful method. And also big was that no user who wasn't part of the BIM team should look to purge the model because they could accidentally purge information that is required.

So these are just some of the standard rules of engagement that I laid out for the team and that you should always look to have established on any of the projects that you're managing so that, once again, everyone understands the playing field and everyone understands any particulars on the project that may be different from other projects that they're working on.

So also going back to all the previous work that I did in the preparation of the project, that's when all this comes into play. Because, like I mentioned, if I'm doing my job right, the models should not need to have extensive support from management. If I'm properly supporting the project, if I'm properly enabling the team, then the models should be able to operate smoothly, and the engineers themselves, and designers, should be able to troubleshoot the majority of their own problems.

So that's when everything kind of comes into play to really reduce the time spent for people going in and fixing problems that could have been prevented in the first place. The other bucket of time, if you remember, that I allocate for my BIM process is an increased amount of BIM support when it comes to project deadlines or milestones because the BIM team at Buro Happold typically also takes a very involved approach for ensuring a project gets submitted smoothly.

First, whenever a deadline comes around, is to, of course, keep calm. This is standard approach. But on any project, especially one that you're trying to navigate a design team around 5 million square feet, things happen. But first and foremost is to just keep calm. And you can keep calm by planning ahead.

So once again going back to the early project planning that I did, there was that bucket of time that I dedicated for deadlines in terms of BIM support. So this is what I planned for way back when I was setting up the model for the work that I foresaw myself doing months later around the deadline. So as you can see here, I let the project manager know that for all of these individual tasks to be performed around when the project would be submitted, I would need 180 hours worth of resourcing to be able to pull this off, which is not a small number at all. And also ensuring once again communication that the project team understands the schedule of all of this.

So one of the big items for this particular project, once again, was the QA/QC comments. And so the QA/QC comments was agreed amongst the entire design team was that the design team could not be making any changes to the sheets once the QA/QC review had taken place. So that impacted the project schedule. And the team had to understand when the pencilled down print would occur, which was weeks before the actual submission date of the project. So therefore, the QA/QC process and the model auditing process had a very large impact for the project schedule and how much time the team had to work.

Once again, once you plan for this, once you get the proper resourcing in place for this, that's when you tell the project manager, hey, I'm going to need 180 hours worth of resourcing. Obviously I can't do that myself. And that's nearly a month's worth of time. So how do you do that?

The QA/QC process-- once again, we need to ensure that all the reviewers who are responsible for the QA/QC are notified on when this occurs. So for us, the BIM team, we need to know that we need to allocate time to perform this. And the team needs to understand when the print needs to be completed by so that the reviewers can begin the review on time.

And then actually performing the review. So we check things usually. So this is a BIM review, so we're auditing the model. We need to ensure that QA/QC checklist that the client is requesting, all of those 70 lines of checks, we need to ensure that that's being performed and that if there are any comments, that we collate them in a reasonable manner for the team to be able to understand.

And then, once all the comments are put in, then we can delegate tasks. If we need to get input from the design team, we need to ensure that they have the proper resourcing and the proper time to get these tasks completed by. And then also, there's always a final check before the project gets submitted, so a very last check that occurs to ensure that all the comments from the QA/QC are picked up.

And then, of course, the very last step is to package and submit the model and on a project like this, a lot of celebrations for a big achievement for everyone involved. And then the final step for all projects is lessons learned, which I will get into in a moment.

Everything that I covered was what I was able to achieve to get the project through to completion during schematic design. And now we are actually in the midst of design development and can speak a little bit more about what has changed since then and what has developed.

So one of the big things is that, like I said, the towers group was the first group to kick off design. And now we have the involvement of the UK offices, who are handling the other half of the project. And not only is the UK involved, but we've also managed to get some of our other global offices involved, like Mumbai and Hong Kong. So this is truly getting to be a global project for Buro Happold. We're tapping into the resources for all of our global offices.

And like I said, lessons learned. Here is a quick idea about where we're going or where the project is going for design development. So obviously, of course, one of the big things is that there's less project setup because I was able to front load all that work. So I don't need to be doing any of that. I don't need to be splitting models. I don't need to be setting up any sheets. All of that was completed last year when I initially kicked off the project.

But what's happening now is that during project support is increasing because now is really when we're getting into very heavy clash coordination meetings. We're starting to take on some VR work for the project as well, so we're doing a lot of VR integration. So there's a lot of additional items that need to be taken into account, as well as the fact that now that the UK offices are involved with the project, we need to ensure that they are fully informed on the practices and workflows and standards that were put in place by the towers team.

And just to give you an idea of that cost completion plan, about how realistic or not so realistic it was for me, according to my original cost to completion plan, I had 147 hours allocated for setup. And I was incredibly off base with that one. It took closer to 235 hours to fully complete. But what you'll see is that my weekly support that I actually planned for on the project was actually less than what I allocated for, which is a good thing because that meant that the models were performing well, like I hoped, and that there was less maintenance required and there was less upskilling required of the team than what I originally planned for during schematic design.

So those are both just two metrics to give you an idea of whether or not this kind of optimization for BIM tasks is useful on the project. And I have already begun to apply those lessons to my project during design development.

So going back to the idea of lessons learned, not only on this project, but any project, always have multiple plans in place because things can and will go wrong. So you need to ensure that you have plan A through D-- hopefully not through Z, but maybe.

And the idea is to be flexible. So while you can have a plan like this where you can break out every individual item for every individual user and have a strict timeline in place, the reality of working in this industry is that things change. The milestone can change during SD.

So I was originally informed that schematic design would have a 20-week timeline. That actually got modified halfway through, and we found out that the milestone date got pushed out by a month, which is great for the design team. They have more time to work. But it does throw a wrench into project planning because now we have to reallocate resourcing. We have to reallocate model freezes with the architect. So a lot of different things can happen. And so you always need to understand that it's always best to be flexible with your approach to project management.

And with that, that brings me to the end of my presentation. I hope you have learned something. And I hope to see everyone again soon. Thank you.