Description
Key Learnings
- Understand the common duties and responsibilities of a BIM coordinator
- Recognize the importance of consistent coordination methods throughout the lifecycle of a BIM project
- Discover best practices for multidiscipline/multifirm coordination
- Determine the most-effective methods for interacting with project partners who are utilizing different software packages
Speaker
BRETT GATTI: OK, door closed. The sign is here. It's time to go. Like I mentioned, I'm going to probably walk around the floor a little because I'm afraid, because the way I talk with my hands and with walking around, I'm afraid I'm going to fall off the stage, and I don't anybody to have to clean the blood off of me afterwards. First of all, I'd like to say thanks to everybody again for coming today.
Hopefully the intro wasn't too bad. I had a little bit of music. We had a slide show. I didn't want you to walk into an empty quiet room. Since this is the last session of the day, I wanted to make sure there is something happening in here when you walked in. I didn't want anybody to walk in, sit down, and take a nap in their chair. So I'm glad everybody's here, your eyes are open. We're ready to go. The room's nice and cold. That's going to keep you awake. So that's perfect.
I'd like to welcome you to You Are Now a BIM/VDC Coordinator, Talk About The Journey and What Happens Next. My name is Brett Gatti. I'm a BIM manager for the IBI group in the Southfield, Michigan office here at AU presenting on something that I think-- this side right here, I'm not going to talk to the whole thing. It talks about the genesis of the session, where this idea came from.
I realized not that long ago that the role of BIM/VDC coordinator's still kind of undefined in the industry. It's different every company you go to. Everybody has a little bit different explanation as to what the role is, what the responsibilities are. Actually, I talked with somebody in session earlier today who'd mentioned that he had just hired in as a VDC coordinator at a company-- actually, a BIM coordinator.
And his role there was different in his role was that his other company, because it was a little bit different explanations of what they expected from him. So what we're going to try and talk about here is a little bit of what to expect, things that may have gotten you to where you are today, and just kind of walk through the journey that we've probably all taken, in some way or another.
And I'm hoping that, by the time I get done with this session, everybody in here sees themselves in one of the slides that I'm going to be talking about. That's kind of the goal is to make you understand that, whatever you're going through, whatever you've done to get where you're at, you're not the only one who's been through that journey. Others have taken the same journey, and they're working with you, as well. They're going through the same steps that you did.
But a little bit about me. I've been in the CAD side of things for over 25 years. Yes, this is really gray in my hair. Been around for a while. Been using AutoCAD since 1992. Actually, sorry, since 1990. I've been using different CAD packages since. Then I started off in the automotive engineering field, moved to the AE field about 11 and 1/2 years ago. I've enjoyed every minute that I've been there. I've been with the IBI group since 2016. And the IBI is-- we're a global organization with over 60 offices around the world.
A design technology leader has been one of my titles. I've been a CAD manager. I've been an IT/IS manager. I've also been a draft person. I actually started on the board drawing with a pencil. So I remember those days. So I started off kind of into the transition in the automotive side of things, when they moved into the CAD side. And I had an aptitude for the software, so that led me on the journey that I've taken to get where I am today.
And I think that, as I talk about that a little bit later, we'll all see ourselves a little bit in there. I'm a multi-year speaker here at AU. This is actually my 10th session I've done here. And I've also presented at the Revit Technology Conference, which is now the Built Conference. I've presented at Midwest University, in the BIMForum, some local conferences. And I've been doing this for a bit of time.
I'm also Revit Architecture and AutoCAD certified, and I'm also AGC CM-BIM and CANBIM BP3 certified, as well. So I've got my fingers around a little bit, so I think I understand what most of us go through in our roles as a BIM coordinator, BIM manager, VDC manager, VDC coordinator. Think I've got that pinned down a little bit, at least so far as you can. As I said, the role is different at every company, so the definitions you're going to see may or may not match what you've gone through in your career.
Class summary-- this was posted on the website. I already said part of that during the Genesis of the Session portion, where I was just talking. I just thought it would make sense to have a session where people who might be new to the role of a BIM/VDC coordinator have a chance to sit with their peers and hear a couple stories are a couple anecdotes as to how they got where they are. I'm always interested to see how people-- bless you-- how people got where they are, and take the whole focus to that. Because where you've came from helps to define where we're going to go with the journey that we're taking as BIM/VDC coordinators.
In this session, I'm not going to read all of the different learning objectives, because they were all posted online. I'll just kind of skim them. But you're going to understand some of the common roles and responsibilities. We're going to talk about just generic information that you might do in your role. It might be different in your company. It might be different upon the different projects that you're working on, as well. But I think there's a lot of commonality between the different roles and the different ways that things are done in different organizations.
We're also going to talk about recognizing how consistent coordination is important. You're going to hear the word consistent me probably 20 or 30 times, as I talk today, because consistency, to me, is the key to the whole process-- making sure that what you say you're going to do is what you do, and the you repeat it every time that you do it. Every delivery you have on your project, everything that you do on your project is a consistent process that you're working with. Especially if you're working with team members who have not been on projects with you before, that type of consistency-- I think that's like eight now-- is very important in making sure that you move forward in a nice smooth method with the project.
How about some best practices. For me, a best practice, good rollout for a project is a BIM kickoff document that you share with the project team, that the whole team has a voice in creating-- something that you're not dictating to them. Everybody's actually joining in and they're dictating, or they're coming up with the way the process is going to work for that particular project. This can be something that can be worked on-- or added into or worked into the BIM coordination-- or sorry, the BIM execution plan, project execution plan, whatever your organization happens to call it. There's different names and different companies, different names and different industries.
We'll also talk about different methods for interacting with project partners that are not using the same software as the rest of the team. [INAUDIBLE] everybody says, well, this project can be 100% Revit. There's going to be AutoCAD in there somewhere. You're going to have Civil 3D, because they don't have Revit. You're going to have some different file formats that you have to work with. We'll talk about some best practices that you might be able to put out there, or just some suggestions on ways that you can interact with those folks who are working with different software packages.
There's other things that are going to talk about today. We're going to talk about the paths that you may have taken. I mentioned that earlier. Because we've all probably taken slightly different journeys, but there's probably similarities between the way we've all done and gotten to where we are with our different roles. There's different project types you might be working on.
And different projects with different partners might require to do different things, as a BIM project-- BIM or VDC coordinator, whether it's an internal project with just your organization working on it, whether you've got project partners and you are doing the BIM coordination on it, or you've got project partners and somebody else is doing the BIM coordination on the project. Your role could be slightly different the way that the project gets approached by you and your organization.
We're talking about exporting and delivering data to everybody else on the project team. That's one of those things that you-- I talked about consistency before. You have to be consistent in the methods that you use and the processes that you use to get the data of the other people on the project team. Whether it's CAD exports, sharing your Revit data, Navisworks exports, you have to make sure that, if you do it a certain way the first time that you send data out, you do it the same way the next time. It's repeatable. It's consistent. It's one of those things you have to make sure is accurate, as you're doing your projects.
Talking about using Navisworks to help streamline the process for coordination. We'll also talk a little bit about using Navisworks SwitchBack, for those who may not have seen it or don't know what it does. And then we'll also talk about archiving, because there's different times on a project you want to archive your data set. We'll talk about some methods you might be able to use to do that, as a BIM coordinator or VDC coordinator, because it's something that's going to fall upon you to do. There's different ways you can do it. I'll give you some recommendations, ways that I like to do it.
Mentioned before, there's different names for this position and different organizations. I did some searching online while putting together the information for this class. I actually looked up job listings just to find out what people were calling it. Came across all these titles plus more. I didn't want to fill up a site with too many words because it became a little bit too wordy.
Granted, this by itself is long, but it's one of those things that, depending on where you're working, what kind of project you're working with, you might see one of these titles. You might be dealing with somebody with this title. You may have this title. Any of these titles-- it's not just a BIM/VDC coordinator, it could be an IPD modeler. Any of the items that you see up there could be what you're working with, so don't be surprised if you see different titles than you're expecting, when you're working with different organizations.
And I threw it out into the Wordle just to see what it would come out as, when I got that list together. And you can see, the two biggest items that are BIM, and manager, and VDC, which I kind of count them as two, because it's BIM manager, VDC manager. Those are the two biggest ones, and coordinator's right behind there. Those are the items-- the main things that people put out there for their job postings, so you might see these titles.
You might even see more than what I have up here. You'll see something out there that matches the duties and responsibilities that you're used to seeing, but it might be something totally foreign to, as far as what that organization calls it. And a couple of questions for the group-- this is one of those things I like to find out, and I'm curious on the answer for this first question here.
When will you started off your career, did you-- anybody in here have the goal to be a BIM or VDC coordinator? Was that what you set out for? Anybody in the room? One person, two people, three. OK, that's actually more-- I did a similar question in a session a couple of years ago. I got one person in the room to raise their hand. That was it. It's always amazing to me, because it's such a prevalent role right now. Almost every organization has that role filled, yet there's still not an education track for that.
From what I've heard, there's a few universities that offer BIM-related classes, but they're few and far between. It's not a widespread curriculum yet. Another question-- did anybody start off with it as their area of study? Has anybody here actually taken the curriculum at a university or college where BIM coordination or BIM management was your course of study? Two people. That's double what I had the last time I ask that question.
That's fantastic. Great that you've found places that actually offer that. In the past, when I did this a few years ago, I'd never even heard of it. And the person in the class said he'd just found it in his curriculum that semester, and just took a class. So it's great that it's getting out there, and hopefully it's something that's relevant to the industry itself. So that's fantastic.
And on the path to becoming a boom coordinator, people in the room here, couple of questions-- who started off as an architect? Who here's an architect by trade-- or by training, I should say? OK, good number. How about an engineer, any discipline? OK. IT support person? Anybody start off in an IT role, and kind of morph into the whole BIM side of things? Or do you wear double hats, where you're IT and BIM or CAD coordination, or CAD management? Somebody's nodding their head here.
Anybody start off just as a draft person at their organization? And you people are the heart and soul of the company, because you get to drive the bid process forward because you understand how it works from the bottom up. You saw people feeding you information that might be wrong, so you got to see what you could help-- do to help streamline the processes in your organization, identify things that might need to be modified or changed.
And then how about anybody who is just a modeler-- not necessarily a drafts person, but a modeler-- that was your position? That's surprising. I thought there'd be a couple of modelers in the room, because that is slightly different in a drafts person. You're not just doing 2D drawings, you're doing 3D models of the item. How about something that's completely unrelated to CAD, BIM, VDC? OK, a couple people in the room.
But as you can see, by looking around with the hands it went up, you all have similar roles in your organizations, but you all started off in different places. You walked through the process in your organization, and we'll talk about that in a few minutes. You kind of took on a different role, as you worked your way up through your organization. You might have started off as a drafts person. You might have started off as an engineer or an architect.
But either you saw something in you or somebody else saw something in you that made you a good fit for the coordinator role. So that's what helped move you all forward. And like I said, everybody in this room has probably a similar story with what they did. You might have started off as the go-to person in your office. People came to you with problems, and you kind identified as that role. That type of thing helps to move this whole process forward.
And then how did you end up that way? This is one of the questions is always interesting, because I've talked to a number of people about it, and the items that I'm going to talk about are things that I've heard back from people who were in the roles of coordinators, or BIM managers, or VDC managers. Your organization found you, like I just said a minute ago. You did something that they saw in you that you were the right fit for that role. You were the right person for that position. You were the person who was going to take the company forward in the BIM coordination role-- just one of the things that you were identified by someone in the organization.
You are great at problem solving, you understand the process, and you were the logical choice when it came time to come up with that role. The organization decided that they wanted a VDC or BIM coordinator, they pointed to you immediately. They just knew you were the right fit for that role. And I've seen that as the way it usually works for most people. As I mentioned before, you were kind of the go-to person in your office. People came to you with problems.
It works in your favor that you are the person who has the knowledge to help everyone. It really is a good thing to do. You are volunteered by others. Your co-worker said, Bill isn't busy this week. Bill can be the BIM coordinator on that project. Or I think Mary knows how to use Navisworks. Mary can be that person. It can be something that simple, and it turns into entire position for you.
But I heard a couple people chuckle when I said that, because it probably happened in their organizations. Somebody volunteered somebody else-- or voluntold I think is the new term for that. You knew Navisworks. At one time, that was the key to becoming a coordinator was you knew Navisworks. You can actually do a fly through without making somebody vomit because you're swinging around the model so badly. You actually understood the way it worked. You can move the mouse and get through the model into a coordination meeting in a nice, clean fashion. I'm guilty of being the guy who makes people seasick sometimes, where my mouse kind of loses control. So I know what that's like.
You're a software guru. You're the person in the office who you have a familiarity with every single software package that you use, at least for that particular process. You know AutoCAD. You know Revit. You know Navisworks. You know Civil 3D. You may not be an expert in any of them, but you know them all. You can help people out. You understand what's needed in the software to get the information out that you need for the coordination side of the projects.
You never say no to anything. I'm stupid that way. A company I used to work for, my co-worker used to always say that Brett is having another dumbass attack. What he meant by that is I volunteered for everything. The reason why is because I knew I could fix things. I knew I was the guy in that office who is best suited to solve a problem. I was the person in the office best suited to take something from start to finish, and I wasn't going to let somebody else take it and have to fix it for them later, if I could get up front and take control at the beginning.
But like I said, he liked to use that phrase on me whenever I'd volunteer for something because-- and I explained to him that I knew I could do it better than anybody else. And I'm sure everybody in here feels that way about different aspects of their role. You know that in your organization, you are the one person who can do it right.
There may be others who can do it almost as well as you, but I'm sure that most of you feel that you are the best person in your organization for most of the tasks that you are responsible for. And that is a great thing. You should feel that way. You've got talents that most people in your office do not have. You have an understanding of the processes that you're using they're just deeper than most people in your organization.
You are one of those people who-- once again, I'm this person-- that something happens on a project-- that there's a deadline coming up on Thursday afternoon end of business you have to have an issue out to the owner. The model blows up at 2:30. You're there till 9:00 at night fixing it because you can, because you know how. You're that person. You're the person who sticks around.
They don't have to ask you-- you just do. Or once or twice, as has happened to me, I've had people walk in the office the next morning and say, are you wearing the same close you were wearing last night? Yes, I am. The model's fixed. We can move forward. It's just one of the things. Once again, you know you're the person who can do it, so you make sure that you stick around and do it.
You can hand it off to somebody else, but you know it's not going to end up the same way that you would do it. It's just one of those responsibilities that you're willing to take upon yourself. You are one of the people who can talk to everybody. You can walk into a room like this and just strike up a conversation with anybody. And that translates on into a project where you can talk to all the different project team members, and talk to them in an intelligent manner, and be nice and clean with them, and not be confrontational in a project meeting.
You can walk in and put out fires. You're that person. You can talk to everybody. You get along with people. And I'm sure in this room, there's a lot of people here who are-- they don't consider themselves extroverts, but if you get into a position where you have knowledge that somebody doesn't, you own the room. And I'm sure that's most of the people in here. You just have that knack about you that people recognize it in you.
You heard your organization was going to do a BIM or VDC coordinator role. You thought, you know what, I'm not even going to let this get posted. I'm going to be the person who does that job. You go to management, you explain to them that you are the right person for that job. Whether you are not, prove it. And you have the skills to do it. That's the important part of that. You can actually back up what you're going to say.
You know you're a good fit for it. You've got the right skill set. You can go to management and explain to them that you can do it. If you don't know one of the software packages-- let's say you didn't know Navisworks, or you used it once and you got sick, because you were flying around in circles in the model. You might have taken a class. You might go home and teach yourself at night how the software works.
You're going to actually bring on the extra skill set that you don't already have to make sure that, when the organization fills that role, you're the person they look to. It's one of those things you're willing to do. You always go above and beyond everything. So you're willing to take it on yourself and learn it on your own time probably, because a company usually doesn't have that kind of open budget for people to teach software during work hours.
You have BIM knowledge. You know the process. You know how BIM execution plans work. You know how the entire workflow goes, from start a project, to end a project. You can apply those skills to a project. You know you're a good fit, and people recognize that. Once again, I mentioned before about teaching yourself software, you go out and you learn whatever you need to learn for that role. You go out and you teach yourself, or you start reading newsletters. You start reading information online.
Google is a fantastic thing. You can teach yourself anything on Google. Between Google and YouTube, I think I could be a brain surgeon. I wouldn't want anybody to actually be my patient, but I think I could. Just one of those things. It's all out there. And you can be, I guess, the voice of reason. I think I mentioned this a few minutes ago. In project meetings, you're disciplined or trade agnostic. You're not going to point fingers in a meeting.
You're going to be the one who comes in-- instead of telling somebody, it's your problem, you're going to say, you know what, we have a problem. This is what we can do to fix it. Or we can move this system, that will fix it. You're not going to be the person who points fingers. You're going to be the person who comes through and just makes the whole project run a little bit better. That goes back to the you get along with everybody and you can communicate with everybody part that I mentioned a few minutes ago. You have that ability. You can soothe people who sometimes can be confrontational, and just helps the whole project move forward.
A couple of things-- some of the common duties that you might have as a BIM coordinator-- and by all means, this list is not going to be all of them. I've got a lot more listed in the handout than what I have here. The handout has a lot more information that we're going to be talking about, just because of time constraints. But the handout is probably twice as long as what I'm talking about right now, with the information that it has.
But you might be involved in putting together, or at least helping with, the BIM execution plans or project execution plans. You're familiar with the way your organization does the projects. You can put input on the appropriate sections. Leave the sections alone that don't apply to you. Don't try and fill in things that are other people's responsibilities. But you're the person who understands the way that those two processes work-- or that process, depending on how your company calls it.
You might be involved in that. You might not be the sole author. You're going to be a partial author of it, but you will get asked some questions on that. What should we put here? What should we commit to here? What level of development should we commit to? That type of information might come up to you as a BIM coordinator, VDC coordinator.
You might have to work with scanned data. A lot of projects now, we're getting a lot of scanned data in. It's never exactly the way we need it when we get it. We don't usually use raw data. You might have to go through and split out the scans into different files so that you can load it in and it'd be a little bit less heavy in Revit and Navisworks. It will be easier to work with. You might be the one in your organization who has to setup files for others.
I know that, when you work on a project, you want to make sure that, from day one, the project is set up right. You might be the only organization who understands that process and that workflow. You might be the only one who understands how to link models together properly to make sure that everything works. So you might be involved in that on every single project.
You might have to work with the coordinate systems on projects, because we get files from Civil 3D, or site data, or the client wants to use a certain monument on the site as the basis of the coordinate system. You need to identify what that is and publish it out to the project team. That information is something you might be responsible for on a project. You might also be working with creating and naming your views in your Revit files so that they're exported out consistently later on during the project.
You have to work with the visibility. You have to get them set up the way they need to be. Create view templates, if necessary, if you don't already have them. Just make sure the data looks the way it needs to look for the project team. Just because you think something needs looks a certain way doesn't mean that's the way that the people you're handing it off to want to see it. You need to communicate with them, as to the way things need to be on the project.
You might be exporting information from your package, whatever it is-- whether it's Revit, AutoCAD, Civil 3D-- so that people can use it in other packages. A lot of times, you need to break things out into more neutral formats for people. A lot of times people might be using older software because it works better with some of their process equipment. They might have a cutter that works with AutoCAD 14-- not 2014, but AutoCAD 14, the one it was out in early 2000s. They might still be using that. We run into that from time to time, people who are working downstream, who are using really old versions of software.
You might be called upon to actually generate content for the Revit models. You might be the person who-- some organizations have dedicated content people, some do not. If you're a smaller organization, you might be called upon to actually create families for your Revit content. Or if you're an AutoCAD shop, you might be called upon to make blocks. Civil 3D, you might be called upon to work within that software, as well. So you have to have a little bit of knowledge of the software packages that you're working with so that you can actually support the project team in a little bit deeper role than you might be used to.
Other things is you might be actually create export sets from your Revit model. Let's say you've got Navisworks exports that you're doing. You might have to set up a view for that. You might have to set up a view for your AutoCAD exports. If somebody's using DGN, you might want to set up a view for them for theirs. If there's a special requirement for the interiors people, you might have to do a special export set for them, because they only need to see certain walls, they don't need to see the full floor plate. You might have to do certain things for different organizations, and it's just a matter of setting it up right in the model so that everybody can utilize it.
And I already mentioned exporting to Navisworks, and I can't stress this enough. I talked before about consistency. Make sure any exports that you do, they're done the same every time you do it. Make sure that your saved views-- you use the same saved views every time that you do it. You don't want to have different exports come out every time you do it. And make sure that, when the project team knows that you're going to be doing it, they know what the names of those views are.
So if you aren't there if someday-- or as I like to say, the whole I got hit by a bus on my way home theory-- if you're not there one day, somebody else needs to export the data, they know views to go to, they know what to export. You don't have random information showing up in a file that you get back from another person, you're working with on the project. That doesn't go over real well with most people.
You might be putting together the Navisworks, the NFW files. Depending on the state of the project and the stage of it, it could be a design model. It could be a construction model. Depends on where you are at and the stage. If you're in AE, you're probably into work with a design model. If you're with a GC, you're probably going to work with a federated construction model. So you might be the person who has to put that together for the entire project team.
You might be called upon to actually run the Navisworks clashes reports. That's typically a big part of the role of a BIM coordinator or VDC coordinator, is you're going to actually be generating the clashes, you're going to be generating the reports, you're going to be compiling the information to share with the rest of the team. Once again, this is another thing that needs to be consistent. If you're generating reports, the reports need to be consistent. The format needs to be the same every time you send it out, so that people actually recognize it and can follow what they're getting in that report.
You might be exporting backgrounds for other people. I already mentioned that a few minutes ago, but you might be exporting out DWG files as backgrounds for people who are using AutoCAD. Make sure that everybody understands what is needed. Make sure that the information is tested and vetted prior to any deadlines coming up on the project. You don't want to have somebody call you the day before you're issuing something saying, you know all the experts you sent me? I never checked them yet. I all the sudden got them-- they don't show anything that I need. So you need to sort that out early in the process.
And you want to make sure that you save the expert views. Make sure that they're saved in the Revit file, and the expert settings are saved, as well. Once again, if you aren't there on a certain day, somebody needs to export your data set, they need to know where that information is and what it's called. That way, they can do the exact same exports as you. You don't have to be there to do the same exports as you did before.
You're also the bridge between the different people on the project. I mentioned before, you're the person who calms waters that. You're the peacekeeper in the project, and you help to explain things in a way that people understand. Nobody's angry, everybody understands their role, and you help to solidify that people-- their responsibilities extend to the items that we've all agree that they have to do. And we'll talk about that again in a little bit.
So if you're working on internal only projects-- let's say you're in AE with everybody in-house-- your role could be different than it is on different project types. And these are things that I've already talked about before. You might be exporting your Navisworks NWC files, if it's needed for the project, if you're not linking them in live into Navisworks. You also might be doing the clash detection internally for your organization.
You'll also host the meetings for your organization. You'll lead the coordination effort. You will sit down with a different project team members after the meeting, if there's any questions to explain what they saw in the clash reports, what you showed them during the walkthroughs. You're the one in your organization who understands it the best, so you're the logical person to actually make sure everybody understands that.
The important thing is, when you're in a coordination meeting, is that the right people are in the coordination meeting. It should be the same people. It should be the right person. You shouldn't have different people from a department come every time there's a meeting. You also shouldn't have everybody on the project at every single meeting. It's not always necessary. A lot of times, it's a waste of time for people to be there.
And you're also going to be publishing the information for your project team. What I mean by that is you're gon to be saving the clash report out to a network folder. The project team needs to know where that is. Send them an email letting them know that you posted it. Don't send the file itself in an email. Let them know where it is on the network so everybody's looking at the same data set. They know where the most current version is. They're not going back to a three-week-old email looking at a clash report that has been superseded two or three times already.
You might be exporting things out. I mentioned that before. You're the one who's going to be making sure that the other people outside their organization get what they need from you. And once again, processing point cloud data-- you might be getting the scan data from whoever did the scan out in the field. You might be either just linking it into Navisworks and Revit. You might be splitting it up into separate models so you can cover different phases of the project. You might be generating model data off of it. It all depends upon what you need for the project and what's been agreed upon for that particular project.
If you're working on a multi-party project where your organization is doing the BIM coordination on it, depending on how things are done contractually on that project, once again, you might be exporting your Navisworks format. You might be the person who's doing that. Like I said, a lot of these things are repeats, because it's the same steps, but there's some that are taken out, some that are added in. You'll be performing the clash detection. You'll be actually hosting the meetings. You'll be identifying the issues to the project team. You'll be leading the effort to make sure that the clashes get lower and lower every time you have a meeting.
And like I've heard in a number of sessions, and what I believe in firmly, is when you're doing a clash detection meeting, you don't look at every single clash in the model. You look at areas of clashes. You look at systems of clashes. You do not identify and look at every single clash. You'll be there for a week. It's just one of the things it isn't practical, because there's a lot of false positives in our files, a lot of that information that doesn't have to be looked at more than one time by you.
And you'll publish it for the entire project team. This should be in a shared location. I don't know if you use Dropbox, if you use box.net, you use a project information system like Newforma, Procore, SharePoint-- any of those systems. You need to post it somewhere where the entire project team can get to it. Everyone needs to have access to the most current version of the data that you have available. Once again, I would not send this through an email. I would post it and tell everybody to go out there and get it. That way, you know they're getting the most current information, and they're not looking in an old email and trying to review old data.
I've gotten those calls in the past where somebody calls me and says, well, I just looked through the model, and I don't see any of the clashes that you assigned to me in that last meeting. Turned out, they were looking at a report from about three meetings ago, and they had already addressed those items. And my fault for sending it via email. That's when I decided I'd never want to send those the email ever again was getting that phone call.
Once again, you might be working with the point cloud data. It's one of those things that comes up on most projects nowadays. Especially if you're doing an addition or a renovation, there's usually a point cloud somewhere. And sometimes you get a point cloud at the end of a project as well, just to check the as-built conditions compared to the design model. You might be responsible for that, as well. So that's the type of information you've got to keep in mind, as you're looking at your projects.
And then there's also another type of project which is a multi-firm project, that somebody else is doing the coordination on it. It could be the GC. The owner could have brought in a coordination specialist to actually work on the project that they trust, that they've worked with in the past. Somebody besides you is doing the coordination. Once again, you've got the same type of responsibilities. You're going to review the coordination findings with your project team.
You might be the only representative from your company sitting in on the overall coordination meeting with the team. It could work out that way. And if that's the case, you need to come back to your organization and talk to the different people on the project team as to what they need to do to help clear up some of the clashes that have come up. Bless you. But do it with the right people.
You need to talk to the folks who are if we're able to evoke change on the project. Need to talk to whether it's a group leader, whether it's the project manager. However breaks down in your organization-- I'm not sure-- different titles, different organizations, just like with anything else-- you have to make sure that you have the right person in the room or right people in the room, when you're explaining what needs to happen out of the clash meeting.
You might be exporting data to Navisworks again. Once again, that's one of those things that will happen. If they're not live link the Revit models, you'd be exporting the data out. You'll be doing all formats, not just Revit format. You'd be doing DWT, DGN, whatever else they need for the project, how do they need to move forward, whatever the different project team members need.
Bless you. And that can be used for coordination meetings. That can be used as backgrounds. It's whatever the uses that they need for that particular data set. One thing to point out is, when you are posting data, when you've got a schedule defined by the project team, do it the same way every time. If there's a folder set up for you, post it in your folder. File names should not changed during the course of a project.
If you're posting CAD backgrounds, never change your file names. Don't put a date on it. Dates are meant for files that are being archived or put aside as a point in time snapshot of something. Do not put a date on a file, do not change the file name, because you'll send it off to somebody and they won't even know that it's meant for them. They'll look at the file. They won't recognize a name. Even if it's the same thing you sent them last week, they won't know that it's supposed to replace the one that you sent them-- or that you sent them the last time. So just be consistent with the naming methods when you do that.
And I have it in red on there-- make sure you post per the schedule that's been defined. You don't want to be the person on the project team that everybody's always angry at because you hold up the coordination process. You don't want to be that person. And there's a step-by-step in the handout, exporting data from Revit, creating your export views. I've got a couple different suggestions in there on how you can set it up and have it as a repeatable process.
So if you look at the pages 10 through 17 of the handout-- it's posted actually on the AU site, as is this PowerPoint. But the PowerPoint's going to get updated, because I made some changes to it this morning. Consistency, I talked about this, and I said I would say that word many, many times today. Because to me, consistency's important in the process, when you're working on it. You need to create an environment of consistency so that everybody knows what to expect on the project.
Communicate with the team-- talk to people, phone calls, emails. If you send an email and you don't get when you're expecting one, pick up the phone and call somebody. Don't assume that they know that the data is there. Don't assume that they know that you asked a question. I know people who get thousands of emails a week, who they-- for whatever reason, they don't read every single one of them. They skim them.
Sometimes there needs to be reinforcement there that you're communicating with them, you sent them something that actually needs their attention. Sometimes it can get missed in the email pile. Especially if it's a long weekend, somebody comes back from vacation, things like that get buried. Follow up with a phone call, if something comes up and you need to really get clarification on an item.
Project kickoff meeting should happen. There should always be a project kickoff meeting, and it should include everybody who's known on the project at that time-- whether it's in your office, their office, a virtual meeting. I personally like to recommend an in-person meeting whenever possible for the first meeting so people meet. They can put a face to the name and a face to the voice. It's nice to have everybody in the same room so that you can actually talk about the information that you're going to be working with. And we'll talk with a little bit more in the next section of this.
You should do a roster of the project team, at least the key contacts on it. You should have the project manager for the other organizations. You should have the hands-on BIM or CAD people on that organization, as well. Both people should be listed. That way, when you call with a question, you can ask for the person by name. If you call and you get the switchboard, and they ask you who want to speak to-- I want to speak to your BIM guy.
They might not even know who the BIM guy or even what BIM is, so make sure you ask for a name. Make sure you have that person's name available. If it changes, change the file. Make sure it is up-to-date-- it's an up-to-date roster. It should be posted where it can be available for the team, and that'll be something else I'll talk about in just a couple of minutes.
Document the process that you're going to use on your project. Whether it's the project coordinates, whether it's the file names, whether it's the file types that are going to be used. Make sure you document it. Share it with the team. We'll talk about that in just a couple of minutes. Data consistency, I've already talked about this a couple times. If a file is named ABC the first time you send it, it should be named ABC the 40th time you send it. It should not be 9192018-ABC. It should be called ABC every time you send it so people know that it's supposed to replace the other files, so the data set always is intact.
You also need to make sure that you don't change versions on people. Make sure that, if they need AutoCAD 2014 or AutoCAD 14, you send it back to that format for them. And make sure that you save your expert settings in Revit it to match what they need, what the requirements are. And origins and orientations of your models or your AutoCAD files shouldn't change after the team has decided where it's going to be.
Let's say you've got AutoCAD file and you rotate it 90 degrees, it's 90 degrees in everybody's file now. Or if, in your Revit file, you move your project origin, you move your survey point, your project base point, the next time it's loaded or reloaded into somebody's model, it shifts on them. They're not going to be able to use your data. You need to make sure that is consistent every time you send it to them.
And you should, within Revit, save the settings. And that's something I mentioned in that last section, that there's actually a description in the handout as to how you can do that, and a couple easy processes for doing that. Consistent coordination-- also, you need to set the schedule and stick to it. When you're going to post date it, you say you're going to post it on Friday, you posted on Friday. You posted on Saturday or Sunday-- you post it on Friday.
And if you've got a weekly schedule, make sure it's every week. Make sure that whatever you say you're going to do, that you follow through on. You don't want to let the team down. And like I said, you don't want to be the person who's responsible every week for the coordination meeting having to get postponed to rescheduled, or your information being skipped, which could happen.
You might be working with Navisworks with the coordination model. Don't change the model every time you have a meeting. Use the same NWF file throughout the entire project. I've talked to people in the past who've actually made a new file. They rebuild it every week for their meeting. It makes no sense to me because your history is in that file. You've got your clashes. You've got your save view points. You've got the information that you've talked about in prior meetings is saved in there-- your markups.
And I don't understand why anybody would ever want to do that, but I've had one person tell me that, and so I wanted to make sure I put it in here just in case anybody else wanted to do that. Avoid that at all costs. When you publish the NWD files, this is the exception to me saying not putting a date on anything. Add the date to the end of it or the beginning of it so people know what meeting it was from. Always publish publishing NWD after every coordination meeting, so it captures everything that you talked about and every markup you may have done in the file.
And if it says it saves your project history, you don't want to do it. Never upgrade a software package on your team. If you're using Revit 2018, live with 2018 until the team decides to move forward or until the project is done. Do not move to Revit 2019. You'll have a very angry team on your hands. That goes for Civil 3D. That goes for almost every package that has 3D elements in it. You do not want to move your data set forward without talking to the team. Don't surprise anybody.
Has anybody in here ever had a project in which they all of a sudden got an upload from somebody that contained a newer version Revit model? OK, I see heads nodding and hands going up. It's not a pretty sight when that happens, because somebody either has to redo work or the whole team has to scramble and move forward with a new version that they may not be ready for. So you have to make sure this discussed with the team. Never surprise anybody with a new version. Any upgrades must be discussed with the entire team because it's important to the entire team to make sure that you're all in the same version at all times.
I talked about coordination best practices. For me, the core of that is having a solid document that the team can refer to, as the project goes along. And we do that as part of our project kickoff in our office. We have a document that we fill out that captures a lot of information about the project, that's very specific to that project. This is not the BIM execution plan. This is typically done before the BIM execution plan is done.
And this can be rolled into the BIM execution plan, because the data in here is relevant within that file, as well, or it can be done as an addendum to it-- either way. I've seen it done both ways at different organizations. But some of things you might want to put in there-- contacts for the organization. As I mentioned before, always have that there. Always have it be something that is updated, if somebody changes on the project team.
If there's questions on which software versions you're using, make sure you capture it in there. What version of Revit are we using? Who's using it? Which service pack are we using, or web update-- whatever they're calling them this month. Autodesk tends to change the way they label things from time to time. But whatever you've got, make sure that everybody's on the same version. That way, there's no surprises, there's no compatibility issues with the files.
What other software packages are you going to use? AutoCAD, Civil 3D-- list them. List what versions you're using, list what service packs people are using, so that when you need to know later on if somebody else comes on the project, you can refer them to this document and they know what they're exporting. They know what kind of data they're going to be delivering, what kind of data they're going to be getting.
Does the project require Navisworks? Who's doing clashing? By that I don't mean the company. I mean the individual. I want know the person. If the GC is doing the clashing, I don't want to know just the GC's doing it-- I want to know the individual there who's doing it. I want their contact information. I'm going to have to contact that person at least once or twice during the project.
As I said before, I don't want to call and say, hey, who's your BIM guy? Who's your coordination guy? I want to be able to call and say, hey, can I speak to Joe Smith? Can I speak to Mary Jones? You want to be able to have a name. And it makes it easier to communicate, if you have that person's contact information. What version of Navisworks are you're going to use? Just like with every other software, there's a checkbox on our form for what version you're using.
And the coordination checklist, it can be specific to a project. Can be specific to an organization. I would recommend letting the project team decide what needs to be on it. Start with your generic form and ask if there's anything else they need on there-- any special requirements they need, anything that they want. It should fit the need of the project. But it can start off as your generic form, whatever that happens to be, but make it fit the project. Make sure the team has a voice in it, because the response is much better when the team has a chance to actually get input, as to what's on that form.
And a couple other things about the BIM coordination checklist is how are we going to transfer data? Where's it hosted? Are we using SharePoint? We using-- I don't know, there's 500 different things we could have out that you can use. What are we using? What is the path to it? Can somebody send me a link to it? Do we need special credentials to get onto that site? You need all that information right up front. You need to know who's hosting it, and how to ask for credentials, if credentials are actually needed for the site.
When you were going to share it. How often are we going to share this data? It's going to be every Friday, every Tuesday. How often are we going to do this? What time of day do we need to post by? Is it end of business, start of business? When do you need to have the information from the different people on the project? How we're doing it? What type of system's being used? Are we using BIM 360, we're using Newforma, Dropbox, Box? Like I said, there's 500 different things. I get ones every week, things I never heard of before that people are using as their data storage devices out there.
What else do we need to have exported? Do we need DWGs? Do we need DGMs. Do we need PDFs, at some point? Just capture that information so the team knows what might be expected at some point on the project. What versions are they going to need? Like I said, there's going to be special requirements from somebody on the project at some point who needs to roll back to a super old version of some software format. And it happens more often than you would think because, a lot of times, the older versions talk better to their machinery that they have in their shops. Especially when it comes to cutting sheet metal and things like that, they need specific formats.
And you can have overall generic information about the project-- the official project name. What should actually go on our borders sheets? What should it say? Internally, we typically have nicknames for projects. That is not what the owner wants to see in the border sheet. They want to see their official name for the project. List it here. List the address. List the owner's rep's name. Have all that information available for people on the projects so they have it available.
Couple of recommendations when working with Navisworks, because Navisworks is what we all probably use-- at least most of us use as our coordination tool. You've got to decide early in the project, are we going to link in the Revit models using append, or are we going to use NWC files and link those into our Navisworks models? It depends on what fits best for the project. One thing I want to mention is Navisworks SwitchBack is a great tool that can take you from Navisworks to Revit. It's not real friendly with linking in the live Revit model.
The reason for that is it sees the central model is the home of the data. When you go to jump from your Navisworks file back to Revit, it wants to open the central file, and it will open the central file. It won't warn you that it's opening the central file. You're all of the sudden in the central file. If you already had a version of that model open, you now have two versions that file open. One is the central model, one is your local.
It doesn't discern between what you're working with, and it can be problematic. And SwitchBack has also been a little bit moody the last four or five releases. It doesn't always select the items that it's supposed to select in the Revit model. You usually end up having to fall back to the element selection method anyways, but it's just one of those things to consider when you're deciding which method to use.
Make your clash test. Save them out. Generate clash tests. Save them in your Navisworks template, or you can actually save them out into a file that you can import into every Navisworks file that you have. This is your different clash tests that you do-- architecture versus electrical, things like that. You'd save those out. You determine what you need for that particular project. You tweak it based upon your standard.
If you need something special, you need to test certain systems against others. You do that here. You actually set up your export sets-- I'm sorry, your clash sets. You save them out. And that way, if your file crashes-- I've had a couple of Navisworks files go corrupt on me in the past, and we had to start from scratch. It's good to have this information available. And if you make changes to it, export it out again.
Like I said, it can live in your Navisworks file or you can export it out to XML format and save it in a directory on your project to bring it back in, if needed. Increased search sets to help with going through the model and finding the items that you need to clash against. And I recommend using search sets, as opposed to selection sets, because search sets automatically update every time that you redo the file, whereas selection sets, they're a firm-- those are the items that were selected at that time. It will never select anything else. Search sets can expand the way that the files are selected in the file.
Appearance Profiler's another tool that not many people-- not a lot of people are aware of within Navisworks. It's a great visualization tool. You can make different systems different colors, you can make different disciplines different colors, and once again, you can use your search sets to help feed that. Because you said what color you want different systems to be, your search sets will go back and find those items and change the colors.
Unfortunately, Navisworks doesn't save colors very well. Every time you reload a file, you have to re-establish and redo your Appearance Profiler. Just one of those quirks that's been in there since day one, when the software was created. Make sure, if you do assign certain colors to different systems, that the project team knows what they are. That usually comes out in the first coordination meeting as you say, the electrical, you're yellow, mechanical, you're blue, structural, you're pink. Whatever it happens to be, make sure the team knows what is was so they can identify what belongs to them in the model really easily.
Clash reports, make sure that you use-- you're very consistent with that. Make sure that your clash reports-- like I said, the format needs to be the same every time you do it so people know where to look when they're looking at it. You don't want to juggle your columns around every time you do that file, because people will not be happy with you the third or fourth time that it happens. And SwitchBack, as I mentioned before, it can be a benefit. It can also frustrate the heck out of you, because it's one of those things that, when it works, it works fantastic. When it doesn't work, it just doesn't work.
I don't know how to explain any better than that. It's a feature-- I think they brought it in 2011 or 2012-- and it's kind of degraded over the years, instead of gotten better. And one thing that frustrates me-- and I think I point this out in the handout-- is that you'll use SwitchBack, and it'll come out, and it'll actually not pick the item that you have selected. It'll actually just go to a view-- just a plan view, nothing selected.
And what it's supposed to do-- it's opposed to actually zero in on the item it's selected in the 3D view. It's suppose to isolate that item. But like I said, I typically end up going back to just using the element IDs at that point, just to select items. And there's a complete walkthrough of this in the handout, and it's a full explanation of how to use that. When people are using other software packages-- we'll call them the others for this-- verify what they're using.
This is something that came up on the BIM kickoff meeting. Make sure that you know what versions they're using, what formats they're using. Make sure that you're consistent with sending it out to them. It should be captured in the BIM coordination document or the kickoff document. If you need object enablers, go out and get them. If you're working with people with Civil 3D or CAD-- sorry, they changed the name again on this-- FABmep.
If you're working with anybody using those software packages, Autodesk has enablers on their website you can download for free. And you can load them on your computer, and they will make it so you can see the elements in their files. It's a little bit easier to work with, when you can actually see the elements that they have. Navisworks will work much better and be much more friendly, if you have the object enablers available.
Make sure, if you need exporters, there's a Navisworks exporter available. For people who don't actually own a license in Navisworks, they can download an exporter from the Autodesk website, and they can actually generate their own NWC files. They don't have to make the commitment to go out and acquire the software, if all they're going to be doing is exporting files for you. They can actually go out and get an exporter.
Established a project coordinate system, and make sure you publish it to the team. If you're getting it from the Site file, make sure you identify something in the model or something in your files as the origin point or the basis point that everybody can use to verify that their data has the right origin, and that you're all using the same coordinate systems. And Navisworks cares about the internal or shared coordinate system. It will really mess you up, if you have a project as using shared coordinates and then you have a project using internal, and you open Navisworks and they start moving things around on you. Keep a list, if you have things that don't use the same coordinate system, so you know which projects need to have which setting.
And publish the coordinate system information to the team so everybody knows what you're using as your origin, if there's a monument on the site, there's a survey spike something they should be using. Make sure everybody knows what it is and what the numbers, the values need to be for that. And verify that everything links together properly at some point before there's a deadline. Export, import-- makes sure things fall together. That's very important on that aspect of it.
And if you need to make adjustments to anything, document it. I had to move the CAD file 3 feet because it didn't come in right, because the folks who work in the CAD file, they moved their file. Make sure you document it and let the team know that you had to do it. Another thing-- if the exports are necessary, make sure that you establish how you're going to export it, what versions are happening, what they need to see in the views. Revit is great for letting you save what you need, and you can actually save views that-- save the settings, this is for company ABC.
Also, is there special requirements? Do they need AutoCAD 2000, AutoCAD 14? Do they need something different than what you've done for them in the past? Make sure you get that documented. Make you test it. As I said a couple times, don't wait for a deadline to make sure everything works together. Test it up ahead of time. And if you're going to have a schedule, make sure everybody sticks to it, you and them. Don't just rely upon them. You have to be proactive on that, as well. You need to send data when you say you're going to send data. Very important to the project team.
And I mentioned this four or five times-- never change the name of file as the project goes along. Nothing frustrates me more than getting a file that has somebody's name in it or a date, because I don't know what that is. You're a great person, but I don't know what your file is that you're sending to me. Bill's file doesn't mean anything to me. Jane's file doesn't mean anything to me. The file that has a name that matches what we determined early in the project is what matters to me. I'll actually load that into my project.
If you may have to make a change to a name for some reason, make sure nobody knows about it. It's very important to make sure that you communicate that. And my opinion, unless there's specific requirements-- jurisdictional or otherwise-- everybody should be using the same border sheet. We're working on a project together. We're a team. It should look the same on all of our sheets. All logos can be in there for all participants, but I think we should have something that looks the same when we send it out, so it doesn't look like 14 different people worked on it-- even though they technically did.
But that's just my thought on it. And there could be contractual issues why you can't, but this is one of my thoughts all along has always been that it's one project, one border sheet, and that's just my thing. And one organization should own it and share it with the rest of the team, but the whole team has input as to what it should look like and where logos go, all that information.
Another thing you might have to do on your projects is archiving, and there's many different ways you can archive data. Some of these you might look at and scoff, and say, nobody would ever archive that way. They have. Well, first one I have up here is the owners decided they want to go a different direction, so you might have to archive. That's just one of the things, you know something is going to change. They're moving a wall, they're moving a room-- you're going to have to change that information. You might want to archive your file for that.
In case billing reasons-- or billing issues later, or just something you need to communicate back to them, or you need to roll back, they change their mind. There's been a change in the scope. The footprint changed. It got bigger. It got smaller. We added floors. We took away floors. We took away a lower level. We added the lower level. Things like that. You want to archive it, so you have a record copy, in case you ever have to roll back.
If you're moving between phases-- you've got phase 2, phase 3 coming up-- save it before you change to the next phase. Just make sure you have a copy in case, for some reason later on, decide that you want to stop at phase 2, instead of moving on to phase 3. Make sure you have a copy of the file. Make sure it's available. And then design options-- if you're using design options in Revit, as we all know, you can have eight design options in a file. If you decide you're going to settle on design option 3, the other seven design options disappear from your file forever. You can't get them back. Archive before selecting a design option every time. Do not let it escape you, because you will feel the pain for it, if you don't have a good robust backup system available.
And sometimes you just get a feeling that you need to create a backup. You just decide, today I'm going to make a backup, because I'm going to be doing some changes that might backfire on me. So I get to create a backup of this today so that tomorrow I can roll back to it, if it completely blows up on me. Because that type of thing can happen. It's those kind of scenarios that you might see.
But some of the ways that you might archive a project-- some people think printing the PDF is sufficient for an archive. And I've been told that, we always used to keep just rolls of drawings, why can't we just keep PDFs? Technically you can, but it's not a model. It doesn't get you back the information you had. Same thing with DWFs and DWFxs. You can use it. It's perfectly suitable, if all you care about is being able to produce a drawing at some point to print something out. But if you actually need to work with a model, those are not going to do you a whole lot of good.
DWG files, it gives you a manipulable drawing file, but it's not necessarily what you need. It's not a model. It's not what you need. Some people say, well, I'll just copy my whole folder structure over, and that's my archive. Sounds great in theory-- it's not. You have to repath everything. Your newly created models are now local files for the old central files, and it's just a mess.
The way I always recommend is, well, if you're in a BIM360 team, you can publish the file out to a zip file. My recommendation's always using eTransmit for Revit. If you don't have it, it's a subscription tool or a maintenance tool-- whatever Autodesk is calling that program this week-- but it's an item that you can download from the Autodesk website, if you're current in your contract, that allows you to actually bundle up your project in one step. Pulls up a dialogue, and there's actually a full description in the handout of how to use this.
But it gives you an opportunity to bundle everything up into one folder set. It actually creates new centrals of all the files for you. You can purge the files. You can delete sheets out of there, if you want. You can delete views out, if you want. Gives you a lot of flexibility, as to how you're delivering the data. I've seen people use eTransmit when they're sending files off for their weekly reviews, as well because you can bundle everything up into one spot. It's just a real simple method of doing it, and it's really clean.
And like I said, there's a step-by-step in the file-- in the handout to explain how that all works. Part of it is an Autodesk-- little clip from them, as to what it's supposed to do. And I give step-by-step of how I like to use it. You might use it differently, but it's just my recommendation on how you can use it. And today we'll just kind of run through what we covered. We talked about paths that most of us probably took to get where we are today. Talked about some of the duties and responsibilities, the generic ones that you might have as a BIM/VDC coordinator.
We talked about the importance of being consistent in our coordination methods. Like I said, I used the word consistent and probably at least 20 to 30 times in this, because I feel that's very important with this whole process to make sure that the data stays intact throughout the entire project lifecycle. Some best practices-- for me, that was that BIM coordination document. That's how I like to put best practices to the team. It's not necessarily best practices for the whole project, but it's for the team that's working on it to understand the ground rules and how we're working together.
And interacting with partners using different software packages, we talked about that a little bit-- exporting data out, importing data, that type of information-- exporting it out. Internal and external clients that you have, and then utilizing Navisworks to help streamline the coordination process, and then methods for archiving your project to key milestones. So the four items in dark and italicized are the four points from the very beginning, when we talked about the learning objectives. Just wanted to put them back out there that we did cover those items, just to let you know that it's information that we did go through in this and identify it here. And then I guess we've got a few minutes left. We can open it to questions, if anybody has any questions about anything I had up there today.
AUDIENCE: [INAUDIBLE]
BRETT GATTI: The question was, do I see BIM managers doing production work, as well as the BIM management side of things? Depends on the way the organization is set up. I've seen some that are 100% non-billable. They're 100% overhead. I've seen organizations where they want 50% billable. It depends on the organization and the way that the position is structured in that firm, but I've seen it both ways.
AUDIENCE: [INAUDIBLE]
BRETT GATTI: Yes. The comment was it a lot of it depends on the size of the organization. That is correct. All right. Well, thanks, everybody for your time today. Appreciate you coming out to the last session today.
[APPLAUSE]