As I mentioned in the introduction, some of you may be viewing this video, starting out your journey in the construction career environment, and perhaps have the opportunity to get engaged in a project right away with adopting 5D estimating software. Or you're viewing the video, having been in the industry for a while and are contemplating the adoption of technology such as these within your own organization. As I thought what might be helpful is to review a little bit of the considerations, the implications, and some of the lessons learned from an implementation perspective. So you can take that with on your journey. The first thing I would say in considering this effort, would be to build your team. It is crucial that you have individuals that have the full breadth of experience of what's required for your specific piece of work within the construction environment. For us, that meant having a software expert. Somebody that really knew the details of the BIM modeling software, inside and out. As we thought about things from an estimating, or an operational perspective, having somebody on the team, whether it's in-house or a third-party support to really know how to execute that work within the software that you're using is key and crucial. Since we're talking about 5D estimating. Having someone on the team who really deeply understands the estimating process. Aside from the tools you use, aside from even the fundamental items that get put together, but what it takes to put together a full and complete estimate. What parts need to come together to make the whole and how the overall picture should be painted for complete cost estimate. Then finally, having someone on the team who's from operations, and really knows the overall flow of the work, has been a customer of the design BIM, planning process as well, as a customer internally of the estimating process. And knows ultimately the overall flow of what it's going to take to put these things together in the field, from there it's about implementing the software. Now you have the opportunity to tie together pieces of the organization that would have previously been in completely different silos, so while that team is thinking about the overall implementation they're considering things from a value-based perspective for the overall stream. Because it makes sense for planning, or because it makes sense for engineering, or estimating, but not fabrication. Somebody needs to be thinking through the overall value stream, not creating micro-efficiencies for a part but thinking about the overall whole. All the while, remembering that it's ultimately the project, the customer, in the end, that needs to see the value, overall. So, the team, if you have a good diverse collective team from the experience of what it takes to put the work together in the field. Design it, cost-estimate it, etc., we could think about where that value is delivered in this case have a picture of a welder, that is where our work occurs in the field. For yourself it might be a designer, it might be the end-user, or nurse, or a teacher, the end-user of the space overall. But unless we keep this concept tied to, what it's value and how is it going to be delivered to the overall project. We might create efficiencies for one part of the process that really serve the overall. So having the right people on your team is crucial. The second implementation consideration I would post anyone is whether or not you're starting from a completely clean slate, or you're going to use some legacy software issue that you'd been using for awhile. There are plenty of product offerings that will help you get a clean start. Cisco from a Revit perspective an overall CAD perspective, Vigo software etc., will help you get a fresh start from a database perspective. Ourselves having used 3D modelling from a planning perspective for 10, 12 years prior to contemplating the estimating side, had a significant amount of work that was put into the items that we used. The connection to our fabrication and equipment, and their facilities, and just an overall effort around database that was many years old. So we were faced with the decision that I'm sure many of you will be faced with, start with a clean slate or let's try and work with what we've got. We chose, let's work with what we've got. So next couple slides, we'll tell you about some of the pros and cons of that. When you're dealing with a legacy database issue that's grown over 10 to 12 years, it might be multiple locations, that now you're trying to get to a single database. All of what I showed you before, which created streamline workflow, really is driven by everybody working off a common sheet of music. If you have 10, 12 different databases around your company, because each person likes their little way of doing it here versus there, you might takeaway that opportunity for streamlining overall. It depends on how it's set up. I use a bowl of spaghetti. When we dug into our database, that's essentially what we found a bowl of spaghetti. After ten years of people bringing in different pieces of parts. It was a bit of a mess. Normally in life people tell you don't sweat the small stuff, but when it comes to BIM estimating software I would say it's all about sweating the small stuff. There are conditions that you didn't even know existed in your database when you start to look at it from an implementation perspective. In this case a phoenix valve, that shows up within the software ten times for ten different offices might be the same valve overall. You might be able to choose just one and use that as the defined, basis of estimating from here on out, but you gotta examine each one. So now you've got some work ahead of you to decide which was the right one to begin with and what are we going to use in the software now. Furthermore, they might be some naming convention considerations. You can see in the left-hand side of the screen, the utilization of a space between hub and spigot, to not a space between hub and spigot. Mechanical joint with a space and without. No-Hub with a hyphen and without a hyphen. These are just the simple English language considerations that take place in a database that grows over time. You need to spend time, effort and energy normalizing your database if you want to make sense of report and not have to account for every potential way somebody could have described a category, a condition within the database. So it requires some effort and work. Another unique situation that you might encounter. It's the case where individual 3D objects in one current state, because they were similar in geometric size, and overall properties from a dimensional perspective to another piece of material. We're just made a copy of in the software and just called something different. In this case, we have a stainless steel elbow, that was created. You can see from the material specification it's stainless steel. But with a little digging, you can get into very minute particular detail about what this code is this happens to be a Harrison publishing code. It's referring to a copper elbow and fitting. So, when a company is using software to essentially BIM modeling software to coordinate with and not really worry about the cost and estimating point of it, the geometric properties are all that really matters. I could change the name of something to represent. I can change colors to make it look pretty in the screen, but it's ultimately the same item. From a cost and material perspective though, they're very different items. And in this case, when it comes down to what really matters, the cost of materials, this particular item thinks it's a piece of copper elbow, and not stainless steel, which are fundamentally different. So you have to clean that up. We found extremely useful, having worked with database normalization throughout all of the different projects I've implemented, we particularly found useful this refined software, it used to be Google Refine. But really, it ultimately takes what the conditions that were fundamentally different within a large 100,000 million items database and normalize very quickly, per what you want to look at, so very helpful. The next piece of advice I'd give you which is around sweating the small stuff and looking into the details is whatever labor estimating system is utilized to shore up the back-end of your database to give those thousands of items that are labor costs. There's some fundamental assumptions that exist behind that laboring system. Whether it's RSMeans for our case MCA, smack down on the sheet metal side, whatever it might be, there's some fundamental basis for providing the labor for the items that you include in your model. Even on a square foot basis, there's some assumptions that are made, how the items labored, is it by the joint? Are hangers included, not included? What are some of the fundamental productivity assumptions that are made about the conditions in the field? How far is the stockpile from the point of installation and work? All of those things are fundamental components to labor estimating systems. And so, whatever it is you're using in your particular 5D estimating software, you need to connect that with that basic set of assumptions. Ultimately, what that means is just giving yourself a better granular understanding of how things are coming together in the software, and what that means from an actual field cost perspective. As well as provides you the opportunity from a report writing perspective to really account for those conditions that maybe the modeling software doesn't necessarily account for. For instance, modeling software will provide labor for a coupling, a sweat joint, the actual stick and pipe, all of those things that go with this particular trade, whereas the estimating system might just labor the one joint. The coupling itself is just the other joint on another adjoining piece of pipe. You've gotta know the details specifically about how those costs come together, and whether you need to adjust for them outside of the estimating software that you're using. Next step, implementing 5D estimating software any essential change around really 3D modeling from an estimating perspective is a change management program. Most companies, ours has been around for 115 years, there are practices and processes in place and embedded that are just ingrained within the overall culture and the way that people do things. So you need to take time and plan for those considerations when making the change. You see in this picture an individual using a digitizer board. I remember when those first came out and it was very, a great deal of efficiency added to the estimating process. Well now we're talking about estimating with a mouse, and really flying around a 3D model and navigating a model, something that maybe traditional estimator hasn't had a lot of experience with yet to date within the industry. So we have to take that into consideration and make that part of the process. We've been a part of the burn the boats approach which is really about taking those old pieces of technology and software and getting rid of them, so we have no choice, but to move. As well as helping to try and foster an understanding of what it is about the individual's work that makes that old version so comfortable. And can we replicate some version of that in the new? For us, it was about taking away the digitizers, and not providing that enabling crutch to keep drifting back to, biting the bullet and moving forward. It was also about the other individuals that interact with the estimate. It's not just the people who have to perform and take off not just your engineers or planning department that are very comfortable with modeling. It's the overall business. It's the project manager, the expediters, the people who can make strong use of the value created by having the data in their hands. But flying through a model is not necessarily second nature to them. So you can bring it in and you saw before, I gave the example of bringing it into an Excel spreadsheet. That might be a little bit more comfortable for the individuals interacting with the overall software. In our case, we mimicked some very old carbon copy tear-off sheets of paper that had long been established in the organization for a method of estimating and bringing the estimating together. We used technology to our advantage to export that information out of the software, courier it, make sense of the data and put it into the format that allow of the individuals within the organization were going to be comfortable with from adjusting and estimating standpoint. Third and final piece of information, I give you after multiple times of having learn this the wrong way, pilot first. Don't try to eat the elephant whole, take a small portion of your organization. Implement, adopt, learn along the way, iterate in real time. There's an inevitable amount of minor details that need to be adjusted. Figure it out along the way, start with a small pilot. Learn what the bugs are, or at least some of the bugs are, and cycle through that iteration with that local team to figure out the right way to implement. Once you've got that understood, then go bigger. It seems obvious when it comes to pieces of technology like this, the allure might be, it's cool, let's move into it, it makes sense. But where it requires a lot of effort, start small, regenerate that understanding and move on. Another implementation and piece of advice we would give to anyone going on this journey. You've probably already been experiencing this from a design in BIM modeling perspective. They grow, they have just simply been getting bigger, and bigger, and bigger, based on the level of detail that we're able to include within the models, and that requires a significant amount of RAM from a computer perspective. These refers to an A3 week conducted internally around issues we were having with machines crashing repeatedly and understanding the problem deep to the root causes of the problem. And finding that if we had just replaced the overall computers with something with a little bit more RAM, prevented individuals from crashing it would save us from a significant amount of effort. This was an effort performed on the CAD planning side since we were about to launch on implementing the 5D estimating software we knew, we were going to create scale for that problem. So we better dig in and understand it and try to resolve it. Today, with the LightR 3D scanning and point clouds that have billions of points in them. The models just get even larger, and if you're going to work with them it's about coming up with strategies both in terms of the hardware they are using to process it as well, as your specific processes. Are you going to break up a large building in order to create a full and complete estimate?