Developing and Implementing an Owner-Specific BIM Project Delivery Standard

JOE POROSTOSKY: All right, good afternoon. Welcome after lunch. So we're going to get started. We have an excessive amount of content we're going to try to get through in the next hour. So we're going to hold all the questions to the very end and see if we have a couple extra minutes. We're going to be talking about developing and implementing an owner specific BIM project delivery standard. And this is around what we've been doing at Ohio State regarding BIM and what actually expect out of our projects. So, I'm not going to read all this. You guys are already here. So--

BRIAN SKRIPAC: Do you want introduce ourselves, Joe?

JOE POROSTOSKY: Oh yeah, I do want to introduce ourselves. So, I'm Joe Porostosky. I'm the director of facilities information and technology services at the Ohio State University.

BRIAN SKRIPAC: I'm Brian Skripac. I'm a vice president and the director of virtual design and construction at CannonDesign.

JOE POROSTOSKY: Such in a hurry, just want to get going.

BRIAN SKRIPAC: So much content.

JOE POROSTOSKY: Yes, too much content. All right, so I want to talk about the Buckeye BIM Initiative. And for us, the Buckeye BIM Initiative includes two distinct parts. First is the BIM for existing buildings. This has been a process over the last six to seven years to transition all of our AutoCAD based floor plans into Revit based models. We're not going to talk about that too much right now, this afternoon, but just to give a little context to where we came from.

And then we have the BIM for design and construction which is what we'll spend a lot more time today talking about, and kind of around what we're doing as far as requiring BIM during our projects, and really then moving into what we're doing with handover and then into operations with BIM. So we have to think about this in three different stages, which is build, maintain, and integrate.

Building is all the building of our existing models. Maintaining is the process we go through of maintaining those models throughout their lifecycle. And then integrating is how we actually integrate models that come out of the design and construction process and then we actually moved them into our environment and so everything can kind of work together.

So our project objective for all of the Buckeye BIM Initiative from the very beginning was to enhance planning and communication, resulting in improved quality and speed of decision making. So it comes down to us and really trying to help our organization make better decisions more quickly. And so every time we think of, how do we want to utilize BIM more effectively in the organization, we really want to throw it through the filter of, how is this going to help us make better decisions more quickly for one of our customers across the university.

And so from a timeline perspective, we've been doing this for a long time. And I think it's just important to understand that there are no real overnight successes when it comes to implementing BIM for an owner. This takes a long time. There's a lot of knowledge that has to be gained. And so we started talking specifically about Revit in 2008 and 2009. Started talking to Brian, actually, kind of informally in 2009. Starting to understand, what is this BIM stuff. What could it mean for us as an owner. What kind of lessons can you share with us that you've learned using it from an architect's perspective that might impact what we do as an owner.

So we're getting really serious about BIM for existing buildings, then, in 2010 and 2009, and actually completed the Med Center transition into Revit by the end of 2012. And then in 2012, we started talking about what are we going to do now from a design construction perspective. And then we'll kind of walk through that process we went through, starting in 2012, which resulted in 2015 putting out our first BIM project delivery standard.

So BIM for existing buildings, just as I mentioned very quickly to give you a little bit of a background of what we've been doing, we obviously had a lot of 2D AutoCAD available of our buildings. It's great. It's a whole lot better than hand drawings, obviously. But at the end of the day, it's just electronic lines on a piece of paper. And we wanted to move to more of a model-based approach to our buildings, for all the reasons that anybody would understand in this room, to be able to understand adjacencies more effectively, and exterior year conditions, and volume, to be able to do renderings that make sense and that our customers can understand. And we've had a lot of success with those outcomes over the years.

The only outcome-- I'm sorry, I'm jumping ahead. From a principles and process perspective, though we learned one really, really important thing while we're working through the BIM for existing buildings, and that was this idea of an owner's model. And this idea was, look, what is it, as an owner, that we care about when it comes to managing and maintaining this model, this model that we're going to say we want to build. It's not an as built model. It's not a design intent model. It's really this idea of an as maintained model. This is the thing that we're going to choose to maintain over the life of the building.

And we really had to ask ourselves the questions, what do we need and what do we not need. If you ask enough people, especially when we're putting together our plan for how we're going to develop these models internally, if you ask enough people throughout the university what they want in that model, you're basically going to construct a real life model that has every single asset that ever existed in that building. So you can't do that because then we'd still be working on the first couple of buildings six years later.

So we had to really make some decisions about what really had the biggest value, though, for us when we were building these models. And really asking the question, initially, what supports our planning efforts. We weren't really asking the operations question yet. So what supports our planning efforts in building those models from scratch. Now we're really asking ourselves, especially as we got into design and construction, what supports our operations? What helps us to operate our facilities more effectively? But also what can be reasonably maintained.

It's great to collect all that data. It's great to ask for all that data. But if we can't maintain it, then it's only valuable for a short period of time before the data is out of date. No one trusts the models. They don't trust the data. And it's not very useful. So just from a progress perspective, we are about 73% of the way completing the conversion of our campus. We have about 25 million square feet in Revit right now, almost what, 229 buildings in Revit. We have about three more years to go. And when we're done, we'll have about 36-- 37 million square feet in Revit for our existing facilities.

So just a quick, from an outcome perspective, there's a lot more I can talk about from this perspective. But this is an existing building that we have on campus. Obviously, not exactly a shining star of attractiveness. But because we have now a lot of Revit knowledge, and also a lot of Revit content for our campus, we're able then to internally, keep in mind this is internally, provide these types of renderings where we put a new road in this area. And then we looked at changing the exterior and interior of this building. And being able to use this for decision making and also potentially for fundraising or donor-type activities.

So for us, we've really been able to save our organization a lot more money just from the perspective that we can help visualize ideas without having, necessarily, to go out and pay an architect to do that. Along the way, we gained a lot of competency in BIM and also in very technical Revit skills, which really helped us that when we came to the point of talking about designing construction, we knew we wanted and we had some really good idea of what we were asking for. And we also knew that if we were going to ask for Revit models at the end of a project, you could be assured that we knew what we were going to do with them.

I think one of the challenges sometimes, maybe for those who might be architects in the room, and engineers, is that you have an owner that says, I want the Revit model, but you know full well that they don't even have a copy of Revit. And if they do, they will have no idea how to open it. So we didn't really want to do that. And we spent a lot of time helping the industry and our project partners understand that we really are going to use what we're asking you for. We know how to use it. We have skills in that area.

And we have a plan in place, which we'll talk about a little bit later to actually utilize this information. And along the way, we started seeing where the industry was going, how the industry was maturing its use of BIM for designing construction, and started learning those lessons and started saying, well, what does this now mean for us at Ohio State, which led to this idea of developing a BIM feasibility study. And Brian is going to about this in a little bit. But one of the things I'll say as an owner is that while things may seem completely logical to me in my little middle management world and saying, yes, we should definitely have BIM standard, oftentimes we have to commission a study and go hire somebody to come into our organization and say the exact same thing. But that's what Brian's going to talk about.

BRIAN SKRIPAC: Well, I was not the one who commissioned the study or did the study. We'll give you a quick overview of what it actually entailed. And one of the things was I happened to be a participant in one of the projects. Across the top, you'll see three different projects that were currently in design or construction that the university went out and interviewed the project participants. And they took some of the standard numbers and potential cost avoidance that were available in the National Institute of Standards and Technology reports, one of those was for inadequate interoperability in the industry, and the other one was the turnover guide.

And being able to take benchmarks about what potential cost savings opportunities do we see in design for coordination? And what's the saving opportunity if that information translates into construction? And what's the cost saving opportunity if we turn that information for owners, and being able to track space, and really starting to organize and structure that data? And over the course of these three projects, the feasibility study generated a savings which you can start to see down here in the lower right, which was an average 7.1%. And that was based on the total construction cost of a project.

So for the executives at Ohio State to say 7.1%, we have about a $225 million annual construction budget. Hey, there's $16 million sitting out on the table. And it's an opportunity for cost avoidance. It does not say cost savings up there. And this study was important to present it in that way. So nobody promised an annual cost savings. And everybody goes, hey, there's an opportunity here. $16 million a year to start chipping away at that and recuperating some of the costs that would be all above and beyond the investment of the initial project work to go ahead.

So that was really a quick win for the university, that partnered up with the information that Joe had already seen in the value that different departments on campus were seeing from the BIM from existing buildings project. So that led to an RFQ that went out. We want to create a BIM standard. There were teams that got shortlisted. There was interview process. We were fortunate enough to receive that. And the goal for this project was ultimately to define two things, how will projects be executed and how will deliverables be formatted? And those were the two guiding principles for everything that we did on a project.

And as Joe said, there's a lot of wants and there's a lot of needs. It was about being focused on the needs and how do those needs fit into these two specific areas. When we worked on how projects would be executed and how the deliverables would be formatted, it was really important for us to be descriptive about defining a design, construct, operate process, not being prescriptive about it. We didn't tell people what exact software you will use. We didn't tell people how to model things. We didn't tell people, you are responsible for the floor, not the structural engineer, the architect is.

We said this is the process that we want you to follow and we want you to use this set of documents to tell us our BIM execution plan for the university, to tell us how you're going to execute on the project and how you're going to turn over the deliverables that we're asking for. And those are really the two big things, those two ideas really became fundamental to the evolution of everything and how this project has moved forward. So from the start, when we developed the project-- excuse me-- we went through the interview process. And these two initial bubbles, really the discover and generate phase, were ones that allowed us and our team from CannonDesign and also from Messer Construction, who are partners, to really go in and talk to the university and interview people, and understand what they needed.

We had a really good opportunity to have a diverse group of people from Student Life, people from academics, athletics, all the different departments on campus be able to provide their feedback. Those people were all jumbled up in meetings and start to understand who is using what information? How are they using that information? Where were they depositing that information? How are they accessing it? What were they getting from teams? What wasn't occurring on a project? And there were a lot of opportunities that we heard that even at many times had nothing to do with BIM. They were really about project delivery challenges and how teams were collaborating or not collaborating in many cases.

So we went through that process. We did a lot of focus group sessions. We interviewed people one on one. We worked with teams, departments. We ultimately produced the standards. We created that document. They were first published, as Joe will talk about a little bit more, in January of 2015. They were released and then we went through a process of implementing that on campus, implementing that to the AEC community in Central Ohio and in a much wider audience.

And we track projects. We paralleled the pilots. We worked with them. We reviewed information. We made refinements. And there's still a level of continuous improvement that's going on today that we'll talk about. One of the first things that we did was this larger idea of track the data. When information comes into the university, who gets it? Where does it go? What tool does it go to? What's the exchange methodology? Who else has a copied version of it somewhere else on campus that they think is the source of truth for that information?

You know, so being able to find the certain levels of redundancy, you know, where there might be gaps, who's not sharing information, what tools are being used, are they being used in different ways, we found a lot of different outlets. So keep this graphic in mind. Later on we'll show a much more organized graphic of how projects come in and how it's a much more streamlined turnover and implementation process for that work. At the end of it, we had a lot of key outcomes. These were the 10 big ideas that came from all the different constituents on campus, the different departments, the universities, remote campuses, everybody that we were talking with, we started to see these.

But really, three things stuck out. How can this idea of a BIM project delivery standard help to reduce the total cost of ownership in operations on campus? How can we leverage a more structured data process at turnover and still use that information with our existing technologies? That was another big thing that we'll talk about. And the last part was, ultimately, to redefine our contractual obligations. That was a big issue that the university was seeing as well. And this was an opportunity to move past that and make sure that people were delivering not only the geometry but the data in the appropriate format. Again, going back to those ideas of how are projects executed and how are deliverables structured.

So right from the get go, this is what you see when you open the project delivery standard. This is sort of the mission state, the introduction, the purpose. It's a reference manual for design and construction team members to understand the geometry and data that they need to provide to the university over the course of a project. And it's really centered around the different BIM use cases that we'll talk about that get documented, who the project participants are, what are the deliverables, how those deliverables will be developmented, and all the descriptions, of course, all the acronyms in the AEC industry come about to make sure we're on the same page.

When we talk about being descriptive and not prescriptive, this is the overall kind of design process map that was implemented and shared. And there's a certain level of genericness to it. It really talks about design and it really talks about construction. It doesn't get into the weeds of who does what, but regardless of the delivery model, if this was a design BIM build project, if it was a design build project, if it was multi prime, single prime, design assist, IPD, whatever it might be, there are multiple delivery models that occur, we needed to have a process that could be utilized in a consistent way across all of these different scenarios. That's why this came out very simplistic to where we start to see what some of the initial opportunities were for the university to set the stage and turn things over. And at these different orange milestones, what actually occurs, how does the model progress?

Even at the beginning, we start to see deliverables at the one university review which becomes around a design development, early design development type submission, which gets the final approval for a project to move forward. But ultimately, we need to see how that information progresses, how the design and construct teams start to collaborate, how they fill out their final deliverables, and then realizing all the while this has a full life cycle that goes back to the beginning. So once that next project starts, that information will then, build, maintain, integrate, that gets cycled back into that existing BIM workflow, and then gets utilized for the next project when it moves forward.

These are the quick overview of the deliverables that every project would go through. Right now, when we say every project, we should probably clarify that. Any project on campus that's over $4 million in construction cost is subject to adherence to the BIM project delivery standard. In the future, that will probably change and get lower as everybody comes more accustomed to that. But right now, that's the benchmark for when this gets implemented. If it's a smaller project, teams have an opportunity to say, yes, we still want you to follow it, but it's not a default requirement on campus.

But these are the components they'll be expected to provide as part of that deliverable. So the BIM execution plan is nothing Earth-shattering. But the value of that is for Ohio State as an owner to have a consistent document that gets turned back over to them at the beginning of the design process, a consistent document that gets updated in construction. It shows how people are going to deliver that information. It looks the same. It uses the same vocabulary. And it's very easy on a repetitious turnover of construction that they see the same information and know where there might be some hurdles. They can quickly pick things out and point it back to the project team. So that consistency became really important for them moving forward.

One of the big things that we updated, which we'll talk a little bit more, is having an LOD Matrix of deliverables, and again, not being prescriptive. We don't tell, during the process, we're not saying that the architect or the engineer is responsible for modeling this element at this level of development at this stage. But what we do say is at the end of the CD phase, or the production of construction documents, there is an expectation that certain things have evolved to a certain level so that the next team participant can realize the benefits of those and the project runs smoothly.

And then at the end of the project, what does need submitted? What needs to be turned over? And then the last two columns were a recent update in version two to really cite, as Joe said and will talk about later, is a consolidation of multiple things. What needs to have asset information next to it? And when does that come into play? So that's when you start to see, does it have information? And which value does it need associated to it? And this was a really big focus of later versions of the documents to make sure that we had data mapped correctly throughout the project.

Once that project's over, the design team is responsible for turning over what's called a conformed design intent model. So any issuances, RFIs, bulletins, ASIs, change orders that the design team member, whether the architecture or engineer was responsible for, there is an expectation that they've updated their model to be included in their submission. This will basically equate out to what an architect or engineer is accustomed to with record documents.

On the construction side, the build team will supply their construction models. This is the information that's either evolved to an LOD 350 or 400 depending on who is doing what. Some of it may still be at 300, depending on what the different disciplines are. But that information will get turned over as well. That would be equivalent to what we would typically see as an as built condition for the university to maintain. The construction models really become an archive for what is actually there. And the conformed design intent model goes through that cycle of build, maintain integrate. That will fill back into the existing building stock and be repurposed on the next project moving forward.

That handles all the geometry and in many cases serves as a foundation for data. But the rest of that data will come from the COBie worksheet, which we'll talk a little bit more. So those are the real three key deliverables outside of the execution plan and LOD matrix that the university will receive moving forward. Once we built all these documents, we got them approved. We presented them. Took feedback from people. We actually had a strategy, then, to implement it.

And I think the big thing that we saw was, technology was really the low threshold for this process. So it was really about the people and the process that we were implementing, because none of the tools were really changing on campus, which we talked about. The CMMS applications that were used, the GIS tools, the CAFM tools, those all stayed the same. It was about how they were receiving information and feeding it to those systems that was different, and doing it more efficiently, ultimately, at the end of the day was the big win. So we really wanted to focus on training people, educating people, and changing the culture on campus for how this information was captured and consumed.

We had some initial BIM basics training. We went through page turning sessions with the execution plans, showed people what to watch out for, what were some red flags if they started to see that the designers or builders were submitting, knowing what to look for when they were interviewing people, making sure that we had the appropriate language in RFPs and RFQs. And again, we had interview questions, how do you read out if somebody is making it up on the fly or if they really knew what they're talking about? So what can we start to point out? What was a cheat sheet for that?

But really being able to dissect those conversations and understand what to look for when people were pursuing projects on campus. Those were all outlets for internal education. We also had an outlet for external education. We hosted a pretty large AEC town hall. It was a lunch session. And we had--

JOE POROSTOSKY: About 140 people.

BRIAN SKRIPAC: About 140 people come out to see-- everybody knew what the university was doing but this was really kind of the larger unveiling like, hey, this is here. This is what we're doing. This is why we're doing it. This is the value. This is how we see all of you being engaged in the process with us and really sharing that knowledge that people were going to start to see as they were awarded projects on campus. The last part of the people evolution was really expanding the team internally. Joe had done a great job building a team out in his department. We educated the PMs on the design and construction side of house, but there was really a missing component, and that was this idea of a close out coordinator.

So on any project that the university has, the university PM has a critical role of managing the entire project. That individual isn't going to have the opportunity to get down the weeds and the specifics of the BIM delivery model that's in place, but it's somebody who is also there to assist in overall project leadership and then the design and construction leadership. And this is a role that we helped Joe define with what some of the expectations of that should be. And they've recently filled. And that individual who is now at Ohio State-- and she's been there for about six months, six, eight months-- so she's really picking up and bridging that turnover process and how information is submitted to the university, which is pretty exciting.

JOE POROSTOSKY: So along with that, we were talking about not just people but also the process side. And as we started with our BIM project delivery standard, initially put it out, the first goal projects we had, we really spent a lot more time looking at them, watching how they functioned, what was working, what was not working, treating them like pilot projects. And that led to our second version of the project delivery standards came out two years later in the beginning of this year. And so I'll talk a little bit more about the kinds of changes that we made during that here in a moment.

And then over the last year, especially with having the university [INAUDIBLE] coordinator coming on board, she came with a lot of knowledge around BIM processes, came from the industry, has really allowed us to spend a lot more time really looking very closely at some very specific processes. So we're going have a whole other set of changes to the [INAUDIBLE] that's going to coming out here probably, hopefully in January or February of this next year. Along the way, we've also spent a lot more time, which we'll talk about in detail here, around how to get COBie out of a project.

So one of the challenges we've had is we say we want COBie for asset data. Every project team is like, OK, that's great. Either I don't even know what the word COBie means or I've never done it before. And so that's been a challenge for us. And so we're working at building a whole suite of tools around that, which we're going to talk about here in a moment. And then lastly in this area is just, how do we actually take all this great data we have and get it into our Esri-based GIS environment so that we don't lose some of that great three dimensional data.

So the version two, when version two came out, we made a number of changes. One is that there was all these charts all over the place, whether they're in the delivery standard, there was in the execution plan, and they're all in words. So it was just really hard to actually manage and use. So we moved all of the charts that we could into that [INAUDIBLE] Matrix of BIM deliverables that you saw, along with a bunch of notes, and just made it much easier for everyone to fill out. In addition, we heard a lot of feedback saying, hey, you're only going down to uniform at level three. And that's way too high level for deciding what should be modeled to what level.

So we took that down to level four. And even then, it's kind of not detailed enough in some cases. So there's some additional notes that are included in the LOD matrix to be more clear about what needs to be modeled to what level. And then we also added some additional clarifications and simplifications throughout the standard. The biggest one was removing LOD 500, which for those who are aware, it just kind of says it's a field verified something. You don't even really know where it really came from, what LOD you're actually basing that on. So it just added a lot of confusion.

And so for the most part, for that actual conformed design intent model submission, which is really the most important submission for us, that set of Revit models, and they do have to be in Revit, are the models that we end up, then, utilizing throughout the life of that building. And generally speaking, it's only between 200 and 300 level of development. And then from a technology perspective, looking at the model, we've done a lot with model checking internally for our BIM for existing buildings and using things like Solibri and Revit Model Checker to improve or, I'd say, quality check our models, especially since we have a lot of students that helped develop those models.

And we've also recently developed a rule set for the Revit model tracker that is going to be published probably in January with version three that will allow our project partners also to be able to run the Model Checker. And it checks a number of things that are in our standard to make it a little easier to ensure that you're meeting the expectations of our project, of our standard, I should say. We're making some changes to our archives that can handle larger files and handle more diverse set of files. And then we're also looking at the idea of a BIM middleware, which we'll talk about in a moment.

And then we've been using some VR internally, especially for early design and conceptual design, and some donor work that we've been doing, and looking at where AR might take us when we get into operations at some point in the future.

BRIAN SKRIPAC: Another aspect of we had to do in implementing was really overhauling contracts. And there were a lot of different facets to how work was contracted and procured on campus. One of the big things that was even ahead of the work that Ohio State's done was the state of had done a BIM protocol that they had initiated early. And one of the things that they did was adjusted a fee schedule. So they had a traditional delivery model and a BIM delivery model fee schedule. And that was one of the big things that the university looked to incorporate was that overall payment structure. We talked a little bit before about RFPs and RFQs, how does that language roll into that so people understand what their expectations are?

What should they be submitting in a proposal back to the university to really validate the qualifications and show their capability to adhere to the standards as they would relate to that project, specifically? There was additional language that had to be filtered through the university's building design standards, [INAUDIBLE] turn over documents, how are they structured. So it was a broad scope approach to driving consistency to all of those documents.

One of the things that was also found is, which was really a lesson learned for us and something that we didn't capture right from the get go, is what does the specification say about BIM and the project delivery standard? If you had a traditional design BIM build delivery project, it's that set of contract documents and drawings and specifications that outline the expectations for the projects, not a traditional RFP or RFQ where it was very clearly stated what was in there. So what do we put in the front end of those documents to talk about what turnover information will be accessible to the contractor, what they're expected to provide, how they're being expected to coordinate and deliver the project further downstream?

So that was something that we're in process of updating now. And you know, to share with this group, make sure you think about that as a consideration if you are documenting those processes and really go through with a fine tooth comb all of the different scenarios that you need to cover on your campus or your facility.

JOE POROSTOSKY: So from an outcomes perspective, what are we really hoping is the end result of all the work we've been doing around BIM as a whole? And this is not just, what are we doing with the project delivery standard and from construction, but more holistically. And the first thing is that we really want BIM to be a connective tissue across the university. And that anybody who is interacting with facilities information in any way is really, hopefully, operating or moving towards a method of operating within a BIM environment. We see this in a lot of different ways, from just a purely data perspective, obviously, we want more data to be in more people's hands.

But also that we're finding more and more customers as we have been doing this for as long as we have, are starting to actually maintain their own data within a Revit environment. So this brought a lot of challenges to us and how we actually work in that type of environment. But we have departments that are managing their own furniture models, equipment models, and even some that are actually managing MEP models that they're developing on their own from scratch or from laser scanning. So we're seeing this as, really, finally getting there after the number of years we've been working on this and really kind of expanding the use of them across the university.

In addition, as I mentioned, we really want to capture a lot of this great, three dimensional data that we have in Revit and get this into our GIS in a 2D format, a traditional 2D GIS format, but also in a more three dimensional format. This has been very challenging for us. we've developed a lot of scripting around this to try to make this process a little smoother. But we don't yet have a good platform to drop all this data into right now. There just isn't really any technology that can handle a true three dimensional campus at the level of detail that we'd like to see it at.

We also, as Brian already mentioned, we already have a CAFM system or a space information system. But some of the things that we've required in the BIM project delivery standard makes it easier for us to bring those models into our systems. We do still have a process that we go through of taking the model when we receive it and doing some standardization on it so that it looks exactly like all the other models we have in our environment. And it allows us to get it into our various systems a little easier.

And then also, and really kind of the biggest piece for us, especially from a workflow and also a financial benefit and efficiency benefit, is how do we get all this data that we're asking for into our CMMS-- our CMMSes as effectively and as quickly as possible? This has always been a challenge. I'm sure a lot of owners have the same problem as the building opens and it's still a year or two before [? load data ?] in there. Where you spent a ton of money to actually hire a service to come in and load all the data so that you have PMs running on day one and have all that warranty information.

Same challenge as we've had for years and we've resolved it in different ways. But we really want this process to result in that the day of occupancy, all that data exists through our CMMSes and we're not having to redo work or rebuild those databases later.

BRIAN SKRIPAC: And regardless of what information we were actually achieving, whether it was spatial information or asset information, we wanted to make sure that we're using COBie as the conduit to get information and data from the model, out to all the information, or all of the applications that Joe had just mentioned. So one of the aspects of that was us to use the COBie extension, one of the Autodesk tool kits. And it was actually just last month we sat down with the team at the university, the team from Cannon and Messer, and also team from CAD Microsystems who actually wrote this application for Autodesk.

We knew all the parameters, all the values that the university was looking for, but it was kind of a day long workshop and opportunity to go back and actually map them accurately to the different parameters and organization in COBie. What tab was it in, what column are we filling in? How is that information going to get there? And how could we, ultimately at the end of the day, set up this Ohio State centric XML file that can be posted on the internet with the delivery standards that say, when you start working on a project, one of the things that you want to download is this application implemented in, that way all the values show up in your model.

And there's a couple of extra steps that ultimately need to occur on the back of saying, well you know, in this tab, here is all of the different things you need to set. There's a little how to guide that goes along with it, so at the end of the day you can actually hit Export up in the upper right and get that information out and be able to have it ready to be turned over. So for as much as we talk about COBie and the mass amount of information that can be there, these are all the parameters that the university is looking from the design and construction team. It's a really streamlined, short list, but critical amounts of information that need to be captured for the operations of those facilities. There's both spatial information at the top, asset information at the bottom.

We organized them based on the sheet, the field, and the actual parameter that needs to be implemented moving forward. So now with those values in place, the design team can implement that, fill out that information, export the worksheet. There's actually a custom macro that is written by the university to normalize that information and just pull out what's needed to continue forward so that the builders have that information. And then it can be implemented into the multiple systems. Because right now on campus, the university does have CMS as well as AMS that works for different departments and what they actually use for CMS.

But once the information is in a spreadsheet, it can be consumed by either one of those applications. And we didn't have to reinvent the wheel spend, money to buy new software, and train people on how to use it. It can be consumed with what they were comfortable with and be ready to move forward. And if you go back to that idea of the spaghetti map where we talked about tracking the data, where something started here, it was copied here, somebody else thinks they own it and they share it with somebody over here, and it's in three different formats. This is what we're actually seeing as the standard.

So the bars up in blue, you know, we start to see the conformed design intent BIM, the operations information, the construction BIMs, all that information comes down to the university architect and what's now known as the close out manager. The geometry resides over here and feeds into these systems. The COBie data feeds into these systems. The model gets archived. And then again, just like everything else, it round trips back up for the next project. The future of this is to start to identify the potential for a middleware technology that may start to stitch all of these together.

But again, everything here that's in the red, these applications are all existing technologies that the university used. So I was able to take that information and feed it into those existing processes.

JOE POROSTOSKY: So on that BIM middleware piece is really what we're trying to figure out right now, is how do we actually take all this geometry and data that we have about our facilities and actually use it in operations. And for some of you who may have gone to a couple of presentations with using BIM 360 Glue, there's definitely a couple of other owners who are trying this out, having some measure of success with it also. So we've started to pilot this internally and try to figure out how we might utilize this. And so we looked at 360 Glue for one of our new buildings, is one method of doing this.

We kind of took some data out of our CMS and shoved it into the model, just to be able to look at it and see how it might operate. We obviously have the field piece that goes along with that. We're looking at other methods of doing this, too, other solutions that are in that BIM middleware piece. But really the long term plan here is not just to have this data available in a three dimensional format for our operations staff, but also that any data that we might have about a facility tying in things like work order history, automation data, utilities data and usage data, and any other kind of sensor information we have, and really creating a-- using the model but [INAUDIBLE] a GIS for that one building.

The ability to bring all these data sets and have a one stop shop for operations staff to use as they're managing the facilities. So I want to just kind of wrap up here with a number of lessons learned that we've learned at Ohio State, really specific to this idea of a single owner of a lot of buildings, a very large number of buildings. And we're going to manage those buildings for a very long period of time. And these really cover not just the BIM for design and construction, but also what we've learned as we've gone through the BIM for existing buildings. So really it starts with having proper planning and focus. And what I don't mean by this is planning for 10 years to do something, and then deciding at some point that you finally figured it out.

You're never going to get to that point. We didn't and we continue to iterate as we go. But what needs to be modeled, whether it be for existing facilities or design and construction, don't ask your design teams to give you everything. Just give me a BIM and everything should be at level like 350 or 400, and you're going to use all that, because you're not. Because you can't. What do you really need for planning and operations? What kinds of assets do you need? What kinds of attributes about those assets do you actually need? What are the most valuable?