AU Class
AU Class
class - AU

Navigating the Stratosphere: Pushing the Cloud to the Limits—Salt Lake City International Airport

Compartir esta clase
Busque palabras clave en vídeos, diapositivas de presentación y materiales:

Descripción

Following a 12-year planning period, HOK was commissioned with the design of the Salt Lake City International Airport in Utah, considered one of the largest aviation projects under construction in the United States. In 2017, the airport launched a new 740,000-square-foot concourse expansion to the ongoing project, bringing the total area to 2.3 million square feet, with a total construction cost to $2.8 billion. This provided HOK with the opportunity to realign its BIM Execution Plan with a brand-new set of design technologies supporting big data, including A360 Collaboration for Revit cloud service, FormIt 360 software, Dynamo Studio software, Revizto, and Enscape. Learn how HOK re-evaluated, strategized, and adopted new technologies to enhance the collaborative design process; and hear what hurdles and opportunities appear when the cloud is pushed to the limits by projects of colossal dimensions.

Aprendizajes clave

  • Learn how to properly budget, plan, and deploy BIM workflows in the cloud for airports
  • Learn how to overcome challenges when managing big data on cloud services
  • Learn how to visualize, share, and review huge models in the cloud
  • Learn how to identify and resolve issues using Collaboration for Revit in large projects

Oradores

  • Erik Jones
    Erik Jones is a senior design professional for HOK San Francisco. For the last 10 years, Jones has provided platform technical expertise to large aviation and transportation projects, including the Phoenix Sky Harbor International Airport, the Anaheim Regional Transportation Intermodal Center, and most recently to the Salt Lake City International Airport, where he played an instrumental role in the Building Information Modeling (BIM) integration, coordination, and execution. Jones has a Bachelor of Architecture degree from California Polytechnic State University, San Luis Obispo. He is LEED Green Associate. Presenting with him will be Shaun Peppers, firm-wide design-technology specialist at HOK; Chris Gardini, design professional at HOK; and Patrick Riddle, design professional at HOK.
  • Cesar Escalante
    Cesar Escalante serves as Digital Design Technology Manager at HOK providing training, BIM implementation, and computation design support to the San Francisco and Seattle offices. He is a licensed Architect with 15 years of experience leveraging architecture and design tools as a practitioner, consultant and educator. Prior to HOK, Cesar worked for Flad Architects managing BIM workflows for large, technically complex, multimillion dollar manufacturing projects, and worked as an Senior Application Specialist for Ideate. He is passionate about computational design, digital prototyping, and a visual programming. César is a licensed architect, LEED accredited professional. He holds a dual Master degree in of Architecture and Urban Planning from the University of Texas at Austin and a Bachelor of Architecture from the Universidad Centroamericana José Simeón Cañas of El Salvador. He is the founder and coordinator of the San Francisco Dynamo User Group.
Video Player is loading.
Current Time 0:00
Duration 0:00
Loaded: 0%
Stream Type LIVE
Remaining Time 0:00
 
1x
  • Chapters
  • descriptions off, selected
  • subtitles off, selected
      Transcript

      ERIK JONES: We're going to present the Salt Lake City International Airport Collaboration 4 Revit. The title is Navigating the Stratosphere: Pushing the Cloud to the Limits.

      The class summary is this project has been in the planning for 12 years under HOK. We presented this project last year, but we were given another opportunity to present the project this year under the guise of C4R and a new scope. The client asked us to look at a new concourse, which is about 820,000 square feet, which brings the total construction square feet up 2.3 million and the total budget $3 billion plus.

      It's part of this new effort we've invested ourself to explore a new set of design technologies, specifically C4R, Revizto, and some VR tools. I'd like to present the panel. I'm joined by Cesar Escalante and Ryan Koccourek. Cesar?

      CESAR ESCALANTE: My name is Cesar Escalante. I am Design Technology Manager for HOK and I am in charge of supporting the West Coast in our offices. And Ryan?

      RYAN KOCCOUREK: Ryan Koccourek with Modulus Consulting, Project Manager, and I came on board to explore and assist with the big data issues that have come about.

      ERIK JONES: And again, my name is Erik Jones. I've been on the project since the very beginning. I straddle both the BIMS side as well as the design and construction documentation side, and I'm often the intermediate between folks like Cesar and Ryan and PAs and PMs on the project.

      So the class objectives, we have four major pillars that we would like to share with you today. The first one is understanding the challenges, which involves the scope, shareholders, and deliverables. This project has over 150 Revit models, nearly 100 Revit users, 12,000 construction documents, 2.3 million square feet of scope, and we will be involved in this project for over 10 years.

      The second pillar is solutions, which is setting goals, understanding infrastructure, and knowledge-sharing. The idea is to understand the critical path for the project, leverage both software and hardware as they evolve over time given the length of the project, as well as tool building. And as well as getting the culture of the project and the team members to buy into evolving our workflow.

      The third pillar is results, which means auditing, exposing the I in BIM, net metrics building, understanding not only the tool, but how it behaves over time, and charting the strategy.

      And the last pillar is implementation-- adapt, management, and have a good execution plan. Documenting the strategy, managing the effort, adapting when things fail. Nothing is ever perfect, but one has to be flexible in understanding in the length of the size of a project like this that things will not always be as they should be. And as well as accommodating new challenge.

      One of the strengths of our workflow is even though we have four pillars, its actually a circular workflow. We've been through a number of different talknologies over the years, and every time we invest and explore new technologies and apply them to our process, we go through the same four pillars.

      So a little bit about HOK. HOK is a large firm. We've been in a number of publications number one or number two ranking, especially in A/E the Top 500 Firms of 2015.

      We're a global company. We have over 20 offices across Europe, Asia, and US. And one of the strengths of our company is that were able to divide and conquer our efforts. A project like this is not going to be done in a single office. It will need to be divided, scope handed out to others, and then leverage strategies and talent from other offices.

      We provide a lot of different services-- architecture, consulting, engineering, interior design, lighting, and among other things like urban planning. We have a lot of different projects from aviation, commercial, government, retail, justice, so our portfolio is quite expansive,

      So a little bit about the project itself. Salt Lake City is a very old airport. It is one of the oldest in the nation. One of the characteristics is that it evolves over time, so you see components of the projects that are existing infrastructure that's 50 to 30 to 20 years old. Also note the design of the airport. It's a very organic in layout. It's as if over time, they just added onto it. And it created a very inefficient planning for an airport project.

      So why build? Obviously, aging infrastructure. The current per year passenger load for the airport is 23 million, which is over double the original design. And one of the unique things about Salt Lake City, even in the last four years, passenger increase was basically a seasonal thing. In the wintertime people would show up to ski and that's when they would get their major influx of passengers. But even in the last four years, there's been a lot of emerging economies within Salt Lake City, where the airport has understood that the passenger peaks occur all year now.

      So this is the layout of the project. The lower part, which we refer as a TRP is what we presented last year. And note how it is overlaying with the existing airport. And then this year we were able to work on the north concourse, which is what we introduced C4R as a workflow [INAUDIBLE].

      So Phase 1 was 25 gates. The whole thing with airport planning is it's all about gates, it's all about revenues. So as we take out existing infrastructure we need to make sure that we would have a gate to gate correlation between what's demoed and what is implemented.

      So last year the rationale was that Phase 2 would be a combination of utilizing existing infrastructure, existing concourses, and a phasing effort. There's probably roughly 70 civil phasing drawings, but each phase of a civil drawing has an MEP structure and architecture component, so it just multiplies on the number of phasing and drawings that one needs to coordinate the dismantling of existing infrastructure and implementation of new infrastructure.

      So note in this rendering that what's called the south concourse east, is still interacting with existing infrastructure. So there is a need to have new connectors to tie into old construction, moving walks, vertical circulation.

      So the client thought about this and what's the rationale of trying to utilize aging and old infrastructure in a new design. And they reached out to us last year about this time to explore perhaps doing a north concourse, which was projected to be built in 10 to 15 years.

      And then a Phase 3 component would then annex and take over the existing terminal and concourses, but the idea is that we would not be using those as existing infrastructure, they would just be completely demoed.

      So once we had this, we have this. So the project is, like I said, roughly $2.3 million. The new project that we've been working on this year is about 820,000 square feet and it adds 31 gates to the project. In tangent, it removes 31 gates from the existing airport.

      So we're currently in construction. We hit CA about a year ago. So in 2002 to 2016, we were doing CDs for Phase 1. It's roughly 10,000 sheets, 1.6 million square feet of construction, and it had about 100 Revit models.

      This year it rolled into CA. At the same time, we rolled into Phase 2, which added another 2,000 sheets to the project, 870 square feet of construction, and an additional 50 Revit models. What's interesting now as far as a BIM execution workflow, we have parts of the team that are in CA as well as parts of the teams that is in design. So there's two different mindsets, two different hats that one has to juggle when managing a project of this size on a BIM execution plan.

      And then we'll reach CA. The IFC for this project is going out Friday. So why we're all here having fun, the rest of the team is struggling to make the deadline and of course our emails are blowing up, but we're ignoring those at the moment.

      And in Phase 3 we'll also start as soon as this project-- the Phase 2 goes out the door on Friday, and so we'll have multiple CA projects as well as a design and construction coordination. The project will continue to be in CA through 2024. So again, this is a 10 plus year of design and CDs, but we've been in the planning for eight years before that. So this project will roughly be in the office for about 20 years.

      So some images of the current construction. And one of the interesting things about this slide is that our CA team utilizes the contractors cameras on site to track, you know, what drawings, what shop drawings, one should focus. You get inundated with a bunch of shots, but then you can use these cameras to say, oh, well, they haven't poured the slab for level one yet. Maybe I can look at shops for something else.

      And just to give a scale of the project. It's a roughly 37 feet long, 3,700 feet long. But its spans between the Venetian, which is where we're at now, all the way to the city center. And in the new scope that we started working on this year is about 2,300 square feet or feet long.

      So I'll hand it off to Cesar to talk about the Design Technology group.

      CESAR ESCALANTE: All right, so as Erik mentioned, this is a big project, a big challenge. And it is nothing new. We talked about these challenges last year, but as things evolve over time, there are new challenges that are added on top of this problem. There's new technology that is available. And I'm going to talk about how HOK Design Technology Group enabled designers and address problems of this magnitude.

      I'm part of the Design Technology Group, Regional Manager for the West coast. Our Design Technology Group has self-labeled as buildingSMART. And the main goal of our group is to provide the tools to the people and enable processes to address complex problems. And it not only supports the traditional design phases, but it also expands to facility management and planning and strategy in a continuous loop.

      We foster a lot of innovation within our company and a lot of this is due to the ability to create a climate of change. It's important for us to support the vision of the project with technology and this is only enabled when we form coalitions between the different groups within our organization. In addition, we try to engage everyone in the technology. And once the technology is deployed, we usually support it, stick it, and support more change.

      The typical process of implementing technology is evaluating that within the Design Technology Group. Then we run a beta testing, design the implementation, look at scheduling and resources, put it to work, and then manage the change, support, train, and empower the users.

      Our support structure is very simple. We have a core group of Design Technology Directors that support the regional managers and in turn we support our local studios and BIM coordinators within our different units. And for us, it's really important to build these coalitions between the work that the designers do, the Design Technology Group, and the infrastructure. And so we have a regular scheduled set of meetings on a weekly, bi-weekly meetings between three different groups. We understand what are the challenges of the designers. IT understands what are we trying to achieve, and we test the products and put it to work.

      So what's new with the new challenges in this year for this project? As Erik mentioned, there is a new scope of work on the north concourse. And with that came a tighter schedule, larger deliverables, a smaller team. And so we were basically asked to do more, better, and less, like they mentioned at the keynotes.

      There was a lot of big stakeholders involved in the process. This is just a partial list of all the groups that were involved on Phase 2. This does not include all the agencies that we needed to deal with and it does not include some of the stakeholders in Phase 1. But there is a lot of people who are going to be involved in the production. This is just the people involved in the production team.

      There is the largest geographical distribution of the stakeholders across the continental US, all the way from San Francisco to Atlanta, New York, Canada, Salt Lake City, L.A. and Seattle. Different time zones and different platforms for different businesses and different type of infrastructure.

      This heat map also illustrates that the teams are also very diverse in the scope of work assigned to them. Each color represents a different discipline. As you can tell, San Francisco obviously gets the largest share of work and our office is multidisciplinary. But also, the stakeholders we work with are also multidisciplinary.

      A big thing that we started to notice. If you notice there's a row here that says SDC. This is our San Luis data center. What is that? This is actually people who connect, people who start producing documentation using VPN or working from home or working remotely. And that's our second largest share of users in our office. So times are changing. Our second largest office is not a physical thing. It's actually a dispersed group of people working from home.

      In addition, there is a big distribution of scope. Each color represents a different office and each square is a different building. So multiple buildings, multiple teams, multiple regions, working from different locations. That's a big challenge.

      And just by the numbers, to support a project like this, we started by engaging at the leadership level, 2 BIM managers. With the length of this project, there has been a sequence of 3, 4 different BIM managers. I'm actually the fourth. Shaun Peppers, who is here, started the process a couple of years ago. And there's probably others no longer at HOK.

      And then we work supporting staff across different areas. 15 BIM coordinators across different offices. We have about 100 active Revit users all working in the 144 Revit files. And yes, AutoCAD is still around, to my dismay, and they will still have to support the work of those stakeholders that have DWGs as a basic production, like civil and planning and landscape.

      Other type of numbers. This project has about five Revit phases. It's probably 32 packages from the beginning. 12,000 sheets, roughly, that need to be produced and presented on a weekly basis. And at this point, more than 50 Bluebeam sessions that we use for quality control insurance.

      We presented this last year and I'm bringing that again. This is the set of toolkits used to address this problem. It goes, you know, from traditional conceptual design tools, like Sketchup Rhino and 3ds Max. Visualization tools, such as the 3ds Max, Lumion, along with performance tools, quality assurance, a lot of Revit extensions. We're very lucky to have that available for us. And obviously our main production platform is Revit-based.

      So what happened between last year and this year? There was new technology, there were new challenges. And so we have this ability to adapt our toolkit with new things and to resolve new problems.

      This was the initial exchange that was set up maybe three years ago. And it's a system of exchanging files using Robocopy type of technology. When we started setting up this, this was the most logical thing at that time. It's a system of folders that is scheduled to run at night and distribute the files every night within different organizations. Each organization needed to set up a dedicated server. And all the organizations need to have the same software and the time needs to be synchronized in different geographical zones so that everybody got the latest and greatest. We thought at that time it was the most reasonable solution.

      But we realized very soon that there were failures in the process. A lot of it was due to different network configuration between offices. A big chunk was just software issues. Software needed to be consistent between different geographical zones. When and if we upgraded, we also needed to upgrade our counterparts. And our counterparts are small offices with the staff that use multiple different hats-- production, BIM manager, and IT-- they couldn't keep up with the rate at which the software needed to be updated. And if the software wasn't updated, then the latest and greatest wasn't at their fingertips.

      And sometimes it was just hardware-- the server is down or broken. And the idea that we weren't going to have a perfect system was a fallacy. Very soon and we were burning still resources, at the last minute sending files via a new format, which was what we wanted to try to avoid.

      So we'll look at what our failures were, what the new challenges are-- more, better, with less risk-- and we look at the Cloud, C4R. Who's been using C4R? Great, more than half, roughly. And it took us a while to jump into it because I was skeptical at the beginning. And then I always hate to jump as an alpha or a beta tester on something that we don't know is going to work.

      But there were a lot of signs in the industry indicating that this was the right time to do this shift. What was scary for us is that there aren't a lot of precedents of doing this type of work at this magnitude.

      And so on top of our toolkit, traditional toolkit for solving the issues from last year, we just moved all our production, heavy production, to the Cloud. And you're familiar with Collaborate for Revit? It's a system that enabled us to synchronize our files across multiple regions using the Cloud. And it works in this concept of a dynamic and a static bucket.

      The dynamic bucket is a list of files that are hosted in an Amazon server. And these are our live production files. And then there's a static component, which are the published versions of the dynamic files, the story in the A360 Team Hub.

      So we need to find a way to secure seats for the entire organization. It was kind of tricky because C4R is a phase service. And we are in a project that is in the middle of multiple phases. Some faces are already completed, some others are in construction, others are starting, there's one that is going to start in the future. And so to come up with a new cost that needed to be-- and we needed to charge our consultants with new seats, was something we debated a lot. Are our consultants going to be willing to pay at this stage?

      We did a cost analysis and realized that with the cost that we were going to save, it was not worth charging our consultants at this time. So we secured 100 licenses as a bulk. And this was the distribution of users based on a survey that we sent to our consultants with the majority of the users on the engineering, architecture, and interior site.

      Then we needed to secure the software. And within HOK, we have a way to distribute software that works pretty easily. Our Implementation Director Package, both the Revit and the add-ons in a single package is accessed by everyone using something we call the Software Center. This is users are able to select the packages they want to add and install it without the need of having IT involvement and it's a safe process and it doesn't require administration privileges.

      But then there was another problem. C4R does not support CAD file. And so we have multiple calls with our auditor asking, what do you guys suggest? We still need to support the AutoCAD workflow because we need to first export to those known Revit users and we need to link things like the site and the GIS information.

      And so we looked at the available options. We were told, well try Dropbox and map it in a consistent matter across all the clients. We did a beta testing and that worked pretty nice. What it basically is, you download Dropbox and you install it and map it in a dedicated folder that is named the same way across all the terminals.

      But then there was another problem with Dropbox. The free version of Dropbox gives you only two gigabytes information. And so we look at Dropbox, Box, Ignite and look at the cost. Look at Google then and Google gives free 15 gigabytes of information, and the size of our CAD files were about 7 gigabytes. That was a perfect solution.

      And so we had then to create a Google account for every user. So every time a user is added to the system, we need to create a Google account and mount the Google Drive to the user profile.

      Then there was the other question, how do we distribute this information both CAD files and Revit through the stakeholders who need them, like in the construction and the field? If you are working with C4R, you probably know that the only way to download the files is from the static bucket and actually zipped up in a compressed zip file. And those files can be really huge in a complex like this when you have 15, 20 links.

      The size of the zips were prohibitive, especially if you are a contractor in a trailer in Salt Lake City trying to download 100 files, each file 10 gigabytes. Forget it. It didn't work.

      But then we find this new app. It is a Forge app that is also available for free, that enabled us to connect this static bucket to a Google drive. And we were using Google Drive already.

      So if you go to this link here, it presents you with this interface and it's very simple. You have the static bucket on the left. You pick the file that you need, press the Arrow key and it will move it to the right.

      About two weeks ago, we had-- I think I realized there is this new thing called the Autodesk Desktop Connector, which also works like Google Drive and Dropbox. And I was very excited when it came out. You can install it when you click your profile. Only to realize that you don't see the actual [INAUDIBLE], you only see viewable version of that, which enable it to be visible and markable in the A360 environment, but it's not good for the contractors yet.

      And so I was dismayed again, but the good thing about it is that I was able to upload files. And so this solution is current and it actually helps us upload things like PDF exports and CAD information in a repository for distribution.

      So in addition to looking at the software and [INAUDIBLE] to this new challenges, we also needed to look at infrastructure upgrades. We knew our files are big and the average file size is about 500 megabytes. And not only the files need to reside in your workstation, but all the links, I mean, 15, 25 links, they also need to live in your workstation, so we need machines that can handle larger files that users are able to open multiple files and that are able to sync faster.

      So we were looking for that recipe, but we needed to also find ways to allocate resources to the right people. So we have in HOK something called the ORBIT, which is Online Resource Business Infrastructure, I think. And it's a key indicator, basically. And it started being used as a financial tool to support the project manager information. I mean, that's HOK keeps track of schedules, cost controls, and allocation of resources. And it was expanded as well to keep track of [INAUDIBLE] events.

      So the type of event that it records is the number of users, number of models that are open at the same time, where are those resources, and it also tracks when a file is open, when a file is synced, when a file is purged. I think it also has the ability-- we have the ability to expand this. We haven't gotten to that point yet.

      The reason I brought this up is because this is data and we are harvesting data from things that are already there. We just needed to find a mechanism to collect it. And we could find things like this. This is the top users that synchronize daily. That's a good behavior. So by looking at this, we started looking at behaviors. John Tye in the structural group, is the person in our organization that syncs the most. Whether that's good or bad, I don't know. He might spend the entire day just clicking Sync, right? But it was a fun fact.

      Now we're not here for fun facts. We were here for finding information that informs how to allocate resources. And so ORBIT enables us to do these type of graphics. This is the number-- how many files different users in different disciplines open at the same time.

      Alex Pang, our electrical engineer, amazing designer, he only works at average one file at a time. So maybe he doesn't need a lot of resource.

      But look at the BIM coordinator, Erik. He's here. Erik works as an architect. He wears many hats. So I don't think I have enough space to describe what he does. But he has an average of 3 and 1/2 files open at the same time. And these are not just simple files, these are huge files. Somebody like Erik really needs a lot of resources.

      And so we started looking at how many resources does people need? And you all work in Revit. You know that the performance of files is not dependent of the amount of core processor. It's actually the result of the UPU speed. And so we started in HOK, we have leases of every three years and on a yearly basis will benchmark machines to renew our leases with better configurations.

      So the best recipe for a high performing machine is one that has a very good GPU speed, has RAM, has a way to cool in, and has a good processor. And so we looked at different machines and we came out with this one, which is the Boxx Apex workstation. It gave us a whooping 4 and 1/2 gigahertz. 32 GB of RAM, Radeon Pro, 512 gigabytes. And when we did our initial test, we were really excited about it, because we can actually feel if it performs better.

      For our mobile users, I mean, those who travel a lot on the management side, there's running production in different places. We looked at the GoBoxx SLM, which gives us a performance of 3.2, and that's actually the machine I'm presenting to you. After running some numbers, we say, OK, these are the two machines that I think are good candidates for supporting this work.

      And the change didn't happen in a single wave. The first quarter of the year, we just have our first box. And when I receive it, I just put it in the hands of Erik and say, Erik, just test this. Let me know how it feels in comparison with what you are using now.

      Three or four weeks later, he is saying, oh, it's great. And the second quarter we purchased five new machines, six new machines, and the laptop. And we assigned them through the top heavy lifters, which happened to be all sitting in the same state. This is our interior works, and that includes Erik and Ryan, who are here. And if you really want to break things, you really need to give them to Erik and Ryan because they're going to play with this until it fails.

      And so that was a good thing because then all these users loved Boxx. And with that kind of feedback, then we went to the next step, which was securing more resources. We secured 20 more laptops. We assigned these for all the heavy lifters in the process and secured an additional seven laptops. And that happened at the end of July and the response has been great.

      And now we are looking to order more [? Boxxs, ?] but this is no longer for the Salt Lake City, but for support of other projects and other units. They are more expensive than traditional laptops, but when we did our benchmarking, it exceeded 130 efficiency increase and that pays off very quickly.

      Another strategy on the hardware side is to set up a dedicated batch processing workstation. So we start thinking, how can we automate the process in a way that takes the redundant tasks away from the designers? A redundant task is printing 12,000 sheets per week, exporting on a weekly basis to our or stakeholders who are in CAD, and exporting NWCs and NWDs for the coordination process at the same time. Who wants to do that job, right?

      And so, we would need two or three people doing that work on a permanent basis in order for this work. So we look at ways to automatize the process by looking at the RTB tools. Have any of you tried RTB tools? RTB tools enable us to automatize this type of activities.

      The other thing we did is people like Erik and Ryan, we give them access to the batch machine using remote desktop and a single login. Now because we're talking about the Cloud, the batch machines needed to have a way to access the Cloud.

      And so we created our robot user called bim.tasks. And bim.tasks really enabled us to empower the work of humans. I mean, we're talking about this merge between robots and humans earlier. This user actually gives us the capacity of automatize things like printing and exporting.

      And here's proof of that. On orange-- this is the number of files a person can print in a day. Erik is a power user. He in orange. And when you automatize the process with RTB tools, production triplicates. So that means that we're getting empowered by this.

      And here's another proof. We look at the number of files bim.tasks opens on a daily basis. The legend doesn't reflect the actual colors. I actually couldn't crop it in a way to fit it all. It has 144 files on the bottom. Because this was opening the files every day and printing them at the same time. And that's all the machine does-- print 24/7.

      Another big part of the improvement was a bandwidth upgrade. We started with a system of 50 megabytes per second, which was ridiculous in San Francisco and I don't know why we had that. And then when I asked IT, hey, we need a better service. How long is it going to take? I don't know. There is a lot of red tape. It's going to take three months to make the change from 50 to 150 because there were requirements by the building, requirements by management, approval by corporate, et cetera. You name it.

      So there was this period of two months where we were actually using C4R with a 50 megabyte bandwidth and we really suffered. If you use C4R, there is a message called Operation Cannot Be Completed. Oh, I hate that. Because the resolution of that it's very unclear even with the documentation that exists in Autodesk.

      When we did the improvement to 150, we were actually in the fast lane. And here's proof of that. We look at the numbers. This is the aggregate sum of synchronizing with central time over a period of six months. And we did the bandwidth improve in September. So we triplicated the bandwidth. And with that we also improved the syncing to Central process.

      Now how do we measure success as well? I mean, performance of every project is the result of a lot of different variables. So it's about size, it's about the number of links that you have imported or Revit, the number of good families or bad families. It's also the result of projects setup and habit. How many files do you have open at the same time? How many users are opening simultaneously? And, you know, how fast does it synchronize?

      It's also the result of organizational tasks, like what project type it is. Is it an interior, hospital? What is the status of the network? Is the network good? Where is our staff trained to do good practices and what is the quality of the content? And ultimately, it is also the all the result of infrastructure, like bandwidth, hardware, graphics, and server.

      So when somebody comes to my desk and says, Cesar, can you do something? Why is my file so slow? I don't have an answer. Its a combination of all of this. And if you combine it that different organizations have different resources, different staff, different ways of working, it's a very difficult question to answer.

      But there are things we can control and so when I was trying to measure performance, I would actually say, OK, how do we measure if C4R was a good investment? So we needed to be able to compare the before and after with between two projects and two files that share a very similar type of unknowns.

      So we'll look at the files' sync times and then we'll look at we have the power of changing infrastructure. We went on a plan to comparing files using this matrix.

      And so we did two tests or two scenarios. We compared two files. The 21 structural and the 41 structural. They approximately have the same size. We look at the period of 5 months. They are usually worked by Shaun Peppers, one user. They didn't have CAD imports and because it's used by the same user, it has the same behavior. So it's easier to say, OK, I can compare apples to apples. It would be different if I compare an interior's file, which is opened by 20 users at different rates with different types of content. And Shaun is a really good user. He's in control of his files and so I can trust what he's doing.

      And on the other side I did another test on the electrical side, which also have various similar parameters. They are in the same discipline, same time frame, CAD imports, files compared. So those were the two files that were compared as far as metrics.

      And here are the results. So the blue line is before C4R and the orange is with C4R. And the sync to central actually improved very well. I was pleasantly surprised. If you add the aggregate sum of people waiting for syncs to central, this is money there.

      We look at the-- the previous was electrical. This is the structural one. Prior to C4R, two minutes average. After C4R or during C4R, 0.7 minutes average. There it is. That is the value.

      So our C4R efficiency for one test is 141% and 137%. There is the money. That's the thing that managers is going to ask us.

      And now that we have this infrastructure in place and it's proven that it works, we need to maintain. And that's what Ryan is going to talk about.

      RYAN KOCCOUREK: OK, so we're in C4R, we've got the users understanding it. We're all good, right? We can go to sleep. We can manage our models. We are running.

      So the first step that we really took was pushing that next level to prove to them that this wasn't just, you know, another piece of software that they had to do another use in login. We really wanted to change the culture and to change that culture we really had to get them excited. And part of getting them excited was a new step in learning, but we wanted to make that learning something that stuck and created a new evolution. And with that, we created our own language. And this is something that intuitively just happened.

      These terms started to get thrown out and everyone started to pick up on them and there was confusion between different parties. Obviously, you've got the designer, you've got your project manager, you've got the executive level, vice president, you've got an executive level IT manager. All of these people are interplaying within our panel. We need to stay in constant communication with them.

      So things things like "cold cache" and "dynamic" and "Cloud" and all of these different terms, where these things fall into place needed to be learned. So we created, basically, essentially, a programming syntax. And with that, we extended our version of the wall and our wall was our dynamic board that lived every part and piece of the project over time as an encyclopedia, as a resource for us.

      So again, these problems, you know, began to evolve over time. They were things we couldn't predict. They were not typical warnings. They were not typical failures that we had seen before on Revit Server or any other type of server type platform. These are new issues.

      So in extending our culture internally within HOK and our consultants, we also had to extend our culture to our partners, such as Autodesk. So as soon as these issues began to evolve, we started a constant dialogue with them to be able to review our support cases, gave them an open book to our data and started to begin this dialogue so that we could put together this new ordering of warnings and troubleshooting issues, so that we could extend our encyclopedia.

      These things alleviated the need for a BIM manager to be behind someone's desk at all times to be able to get things running. They would be able to come to a resource, they understand the problem, and could walk through the steps.

      So from that, you learned about the robotic process that we use. So on a daily basis, I would run the robotic machines. Typically, there's three of them plus an additional laptop, so four machines really handing off information back between each other, processing. But during the night time, most of these machines are running automated processes on their own and offline. So we did always keep a constant process of communication, so that everyone would understand what was actually happening in the automatic robotic processes and that they would be able to use those things as a resource. So basic communication extended to that culture as well.

      And then your standard maintenance of a model is now expanded so much further than you could ever imagine. Because not only now are we everything is real time, everything's Cloud-based, but also, the timed step that requires to sync and link and communicate between each version of the model, to be able to get your documentation set out at the right period of time was critical.

      So one of the new tools we've been looking at, and this is actually highlighted in a course by Conrad [INAUDIBLE] at Autodesk University, it's called Mission Control. And essentially, this was one new step for us to basically keep a daily tracking on what families, what worksets, what links, what views were affecting different parts and features within the automated processes and also within the daily user's workflow.

      So our first pass with the wall, the original wall, was utilizing OneNote, which is basically again, a Cloud-based note platform. This became essentially our encyclopedia, our Cliff Notes. This became the BIM user, the BIM manager when there was no BIM manager present. We could solve hundreds of issues by pointing people in the right direction. Obviously, weekly meeting minutes, workflows, automation, troubleshooting. There were links to other resources that we were using. So this culture is just growing and expanding.

      So we said to ourselves, where is the next step? How do we get to the level that every part of this project is there? How do we really harvest that rich data as Cesar was talking about? So just a glimpse into the OneNote just as an example for coordination purposes as issues started to come about.

      One of the common things that came out with C4R is the GUID. This became a very foreign thing to users and how to restore information. So that became a piece of information that had to become a critical part as a codex for people to use so they could quickly grab that idea and replace that cold cache file when needed.

      And this is actually a much more frequent process than you see. And so we also had the automatic robotic process having to go through the models and automate that clearing of cold cache because it would literally track itself through every part and piece of the model.

      So we're starting to create new tools and these new tools are then expanding our level of interface with the model. One of the new tools that really started to expand ourselves from essentially the Revit platform to a new form of coordination and close the loop with all different users was Revizto. And our workflow was a little bit different.

      We added to the process that we were already utilizing for our prints. As Cesar talked about, we print over 1,000 sheets on minimum every week. So we were we were in a one-week cycle for our prints and we decided to add a one-week cycle for our coordination. We already had a setup for the earlier phases of the project, for Naviswork. There was always a workflow, so MEP guys were very familiar with this setting. It was just walking into the next thing. But how do we expand it to all the other users who aren't familiar with the tool of Navisworks? We wanted to give them something more intuitive.

      So Revizto became that tool, became this live interface. It was connected with Revit, it was connected with Navisworks, it was also connected with our printing process.

      So essentially, we're now able to tap into this information in multiple ways. We're delaminating the very complex field of information that you can see in front of you. And being able to quickly access this information and prove to leadership that there is a need to have an interface with this or there is a design challenge that needs to be looked at. Because the thing to understand is the architect's frame of use for clash detection is much different than what the contractor's is. So the normal use of Navisworks did not just work for us. We couldn't just spit out a list of 10,000 clashes and allow someone to parse through all that information. We literally had to set up and filter those scripts and even filtered the models before they even came into Navis so that that process became very simple and intuitive.

      So this culture became extended so far as to even the users that were not into Navisworks or Revizto, we had an automated process that would be able to extract that information and quickly tap into the information they needed in Revit, you know, the element ID for instance. They could easily tap into this.

      So once we got into this method of going from exporting our models live into these platforms on a weekly basis and everyone was used to that, we expanded that to now go into a daily basis. And so now every day we literally overnight and during the day, we selectively process and export all of these different versions. So we have a very systematic interoperability between all of these platforms, but it's done in a way that doesn't affect the mainstream information. That if one model fails, we know we're only one day behind. We're not so much far behind that everyone is not feeling that their information is not current.

      So not only is this gave us the ability to visualize, as these models became online and more models came online and more complex, we realized that the timing in all of these things was critical. So from this point, we were able to essentially guarantee that coordination is solidified and now we've got our prints in order. So the project manager is able to see the current information as well as the coordination meeting is able to tap in and visually understand the entire pathway that runs through this system.

      One of the very complicated pieces in this airport is the baggage system. That was one of the things that came on very early in our process. And the baggage system is a dynamic system, so it became a process that we had to utilize animations, we had to utilize VR, and we had to utilize these things to really understand how the motions and the overlaps of all these different clearance zones were taking place.

      The other thing is the baggage system came in in an earlier phase. So its level of development as a model, which was much further advanced than some of the other systems. So we had to take information and lessons learned from the past phases to be able to incorporate that into our current workflow.

      So here this is just an example, extracting out basically from a Navisworks animation that is actually simulating a baggage on its baggage pathway. We use this to be able to clash this information and feedback to our clients to verify. And within this, we've basically spliced in some of our live VR. We used VR for client sign offs and we are now working into the process of trying to get our VR to be as live as all of our other platforms.

      And that actually brings us into our closing statements. And so just a quick understanding. Here is just another example of a VR that we used and we used Dynamo in this case. For those lights we use an attractor in correlation with a light cone to be able to place those lights. We also used Dynamo in a few other lightweight manners for occupant calculations. We're looking at it for using it to upgrade the model as well for scaling texts and also auditing processes.

      So we're starting to roll these tools in such a manner that it becomes very natural for most of the users, so that users at all different levels are able to be able to jump in and be able to see the benefits of the tool. They're also able to utilize the information of their coworkers and work in groups to learn. So we give them multiple ways to be able to access the information and from there, we're really creating a new culture of design, a new culture of coordination, a new culture of management.

      And I'll go ahead and pass this over to Erik for the final closing statements.

      ERIK JONES: Thanks, Ryan.

      OK, so some key conclusion remarks. Promote change by building coalitions with your team and also with your external team members. A lot of our efforts was actually convincing management to invest time and energy and resources and taking us from one platform to another, specifically C4R, which is a new way of doing things and there was a lot of risk involved.

      Crop the data. Harvest what you have an measure it. ORBIT provided that. It gave us a proof of concept to provide management of why we did what we did and what the cost savings were and how we could be more efficient with using less for this new phase of the project.

      Don't be afraid to invest in even new software or new hardware. Times are changing. Before this project started, there wasn't things like Dynamo, there wasn't things like VR, there wasn't things like C4R in the office. But over time, we've used the new emergent software to enhance our delivery.

      Also support multiple mechanisms of learning. We have multiple platforms, like OneNote, VR, Revizto. The idea is that not all the users adapt to the same set of tools. So it's understanding to provide different tools that perhaps do the same thing but with two different users.

      And document using the centralized walls. This was something that we brought up last year regarding how much a big project and how much information is involved with a big project. How detached team members can be just because of the nature of such a large project. But the idea is to find walls. So OneNote was a huge thing that we added even on the TRP side. So for, like I mentioned that we're not in the office right now, but we get these emails about calamity happening and we just send a tab saying refer to this tab to the OneNote and then 10 minutes later say, oh, that worked.

      And embrace the unknown. This goes back to the four pillars; that you don't stop at the fourth pillar and you walk away; that it's understanding that you always should restart the process even when it's not failing but to improve efficiencies.

      So with that, I'd like to open the floor to questions. Sure go ahead.

      AUDIENCE: So as you know, in February Amazon had an outage, which, of course, affected C4R. Given that you have all your things in C4R, how did you guys handle it?

      ERIK JONES: So the question is the fact that we're relegated to Amazon, meaning that if Amazon goes down, we're effectively in a blackout condition. It was interesting that we were on a roundtable yesterday and the same question came up about what do you do when things go wrong? And I'll just respond to the roundtable-- clean your desk, stuff like that.

      But in San Francisco we had a power outage a couple months ago that affected 3/4 of the city and the whole office basically couldn't go home because the transportation was not running and stuff like that. We took it as an opportunity to mingle. So would speak with IT when they talk about their performance and their downtime, it's significantly more than Google Drive and Amazon. And that was the metrics that we provided.

      CESAR ESCALANTE: For systems to evolve and perfect themselves, we need to look where they fail. And so we haven't thought about it-- what would we do? When that happens, you know, I remember meeting with Shaun and Erik and what do we do now? We say, oh, the files are still there. The files are still as downloadable cache files. Let's harvest them and how do we harvest them? That's where we learned that we needed to look at the GUID number. Open that GUID number, save it as a different file. And continue working with that deliverable that was critical for that moment in time.

      But then from that experience, we also learn about putting in place safe keeping backups. Now we're, OK, we need to backup this or find a way to back up this. And so on a weekly basis, we download the files from the static bucket and put it on our server just in case. Things are never perfect.

      ERIK JONES: Go ahead.

      AUDIENCE: Did you investigate in [INAUDIBLE]

      ERIK JONES: So the question is, do we need to have more backups before or after C4?

      AUDIENCE: No, more bandwidth.

      ERIK JONES: Oh, more bandwidth. So the question is, did we know we needed more bandwidth and did we find out we needed more bandwidth?

      AUDIENCE: When you didn't need more--

      ERIK JONES: Or we didn't need more bandwidth? I think I'll let Cesar speak to that.

      CESAR ESCALANTE: So one of the things-- we knew we were going to do a big investment. And so we engaged Autodesk very early on. And so their support service was with us from the very beginning in the planning of the deployment. And we give them the input of what we were trying to do and they, based on what their assessment, they really recommended that. And so we followed their recommendations.

      And also, we had done a beta testing, Shaun did actually a beta testing of a portion of the files during the 30-day trial and we realized the need of a bandwidth increase there.

      AUDIENCE: [INAUDIBLE]

      CESAR ESCALANTE: Yes.

      ERIK JONES: Go ahead.

      AUDIENCE: Can you talk a little bit more about how Revizto has become part of your workflows [INAUDIBLE] doing Navisworks. And is Revizto just internal for the design team or are other members of the project using Revizto in the process?

      ERIK JONES: So the question is, the use of Revizto-- is it just with the design team or with the coordination team and what have we used before versus like Navisworks workflow and how do we transition to Revizto? I'll let Ryan answer this.

      RYAN KOCCOUREK: Yeah, so, one of the things we recognized before is that they were using Navisworks. Like I said, we had a process of doing it Navisworks on a weekly basis. But it was more of an independent use of Navisworks. So consultants would be reviewing their own models, they would be doing their own tests, and then that information would be fed back in different ways. So the communication path was a little disconnected.

      So what we chose to do is go Cloud-based with the Revizto and we provided connection to everyone. And so we started to see how it was used to get the culture on board and some people were using it more effectively than others. Some people were using the Navisworks and that information would be fed into Revizto so then that user would see that information in Revizto. So the Revizto would be the final hit point for all information.

      But it didn't say that it wasn't communicating back and forth with the Revit model and also the comments that were being collected in Revizto. So it was a continuous loop of information. And that's what we were really trying to get to, is to be able to say, that when there's a downtime or any other point in a need for information to be immediate, you could get access to it. And that was critical because you had 16 models on average connected and linked to one model and if you loaded all of those worksets and put all that in, you're going to lunch for a couple hours before that comes back into play.

      But with Revizto, you could have that interface up parallel, walking your way through the entire building, all interconnected, and pushing that information back into your live Revit model to be able to feed that coordinated item.

      ERIK JONES: Go ahead.

      AUDIENCE: Again, connected to the C4R question. When we saw the design team that you listed here, it looked pretty much like everybody's sitting in the US, yeah? Question to you, HOK Labs is an international organization. You can answer this in two pieces if you like. So the question is, if that design team would be spread all over the world, would you still have put C4R in place?

      ERIK JONES: So the question is, would we have engaged our non-domestic offices if we were on C4R for a project like this? Is that the--

      AUDIENCE: Yeah, non-domestic. Yeah, they're still the design team.

      ERIK JONES: They're still a design team.

      CESAR ESCALANTE: Yeah, I think--

      ERIK JONES: Cesar, answer the question.

      CESAR ESCALANTE: I think this was, for HOK, one of the first projects in C4R, and so there have been opportunities where I have heavily promoted the technology but there was a project led by our Chinese counterparts. The cost of theirs seemed to be prohibitive and so that was the only thing that prevents us from using it. But I would I would definitely recommend it.

      AUDIENCE: Because it was interesting when you took your survey and half the room said they didn't use it. But if the half of the room that didn't use it are people like myself, who are not in the US, then it's understandable.

      And the other thing aswell is for your bandwidth update. If you're sitting in the Middle East like I am, that's just not an option. You know, you'd need to be a millionaire to be able to pay for that.

      ERIK JONES: Interesting.

      AUDIENCE: And I think-- I'll speak for myself-- I don't think anybody doesn't see C4R as a real goal. Absolutely, I think it is. But I think it's a really, really unfortunate situation that outside the US. We are struggling. We are really struggling to use it.

      CESAR ESCALANTE: Yeah, and the reality is [INAUDIBLE] infrastructure, we cannot avoid it. The bandwidth increase was an option for us, I agree. And we only supported it because of the size of this project, which is humongous in the number of files. For a similar project like this across other geographical regions, we probably would still do the traditional exchange process.

      ERIK JONES: Go ahead.

      AUDIENCE: [INAUDIBLE] working from Sweden to [INAUDIBLE] in India at the same time. Works very, very well.

      CESAR ESCALANTE: Oh, yeah? Good to know.

      ERIK JONES: Go ahead.

      AUDIENCE: I've also used C4R with users in US and China at the same time. [INAUDIBLE]

      CESAR ESCALANTE: How big was the project?

      AUDIENCE: Much bigger than this.

      CESAR ESCALANTE: Oh, really?

      ERIK JONES: OK, cool. Go ahead.

      AUDIENCE: [INAUDIBLE]

      ERIK JONES: OK. But just to recommunicate, we spent three months of growing pains because our own infrastructure wasn't in place. So the chart that Cesar showed a huge dip time in sync time. So once you have that infrastructure in place it's a--

      RYAN KOCCOUREK: I think the lessons is that you have to now be completely integrated in this IT solution and the strategy has to be upfront. It can't be something that you look at later once the models are there. You have to be able to see this and visualize and test these scenarios upfront.

      One example that might work for your scenario is that there might be multiple hubs that are interconnecting to one another to reduce the size and the sync times. But I just think as a role, that workflow has to be thought of, which is something new. Typically we did not do before and it's mandatory to be able to have that information in place now.

      ERIK JONES: Sure, go ahead.

      AUDIENCE: I'm currently working on an airport. It's a smaller project over in Seattle and we're using AR. Have you guys considered using that as well when you were looking at using VR?

      ERIK JONES: So the question is, are we looking into AR versus VR? I'll let Cesar answer that.

      CESAR ESCALANTE: As a company, the Design Technology Group is looking into AR technologies and we are selectively choosing, beta testing. I don't think when our incursions in AR had this really high expectation just to realize, you know, that I don't think the technology has matured enough to be friendly at the end user. You really need to hire or develop the tool yourself. And so we have not-- we are getting there. We have a research group that is doing that as we speak. But for this project we didn't do.

      AUDIENCE: Yeah, we have a similar issue with like the baggage area, getting that verified--

      ERIK JONES: Yeah.

      AUDIENCE: --kind of the cable trade within that area, across those zones and make it through. Because the way these buildings are completely spaced out, they're so open in the center--

      ERIK JONES: Yeah.

      AUDIENCE: -- it becomes difficult [INAUDIBLE]. I would have a second [INAUDIBLE]. I saw that you guys were monitoring all of the families for all of the models to look for problems. What was the problems you were looking for with those? Was it a corrupt file? Or was it someone being [INAUDIBLE] ?

      CESAR ESCALANTE: So there were different--

      ERIK JONES: No, go ahead.

      CESAR ESCALANTE: --yeah, there were different metrics that we were looking and we were looking at the usage of worksets, the number of views, the size of the families, and the model growth.

      ERIK JONES: And we had issues on the TRP with level of development, families having nested, and I know that Cesar spent a couple of weeks focused on cleaning those out in a vacuum, not understanding, but with the new software it audits for us. It strategically helps us locate the problem child.

      RYAN KOCCOUREK: Yeah, one of our issues is the project is so long, there's not a lot of legacy families. And those legacy families, they almost have to exist because they are being updated with parameters that are automatically being updated, like, for instance, we use a plug-in called autoLink Revolution Design and that updates the views.

      So those sorts of things require a lot of maintenance and you can't then eliminate that legacy, you have to find a way to adapt it to it. So those are some of the bigger problems with add-ins that connect to those family parameters.

      ERIK JONES: Go ahead.

      CESAR ESCALANTE: And check the class by Conrad [INAUDIBLE] because he's going to explain later on Thursday how he did it. He's our programmer in New York and his class is web-based management.

      ERIK JONES: Yeah, go ahead.

      AUDIENCE: The dashboard that you were using to analyze the families and all of that, is that a readily available plug-in or is that something HOK has?

      CESAR ESCALANTE: So the data is collected in a Cloud-based SQL. We downloaded it exported as Excel and plug it in Tableau.

      AUDIENCE: But I was looking [INAUDIBLE]. I can't remember what it was called but it looked like it was--

      RYAN KOCCOUREK: Mission Control. It was the Mission Control.

      CESAR ESCALANTE: Oh, the Mission Control?

      RYAN KOCCOUREK: Yeah, that was the database.

      CESAR ESCALANTE: Yeah, that is the-- it's a Cloud-based-- it is a website that is used only to report the data collected by the SQL database.

      RYAN KOCCOUREK: But yeah, really there are a lot of ways to create those dashboards nowadays. One of them is like Kibana, or connecting to Power BI, or Tableau, those sorts of things. But it's really connecting to that server data first, getting that flow of information, and then the dashboard is really a very simple atmosphere that you can create. It's kind of a plug and play system.

      But this is one that we developed obviously particularly for our needs, but you can really manipulate that dashboard however you want now.

      ERIK JONES: Any other questions? Go ahead.

      AUDIENCE: Which protocol do you have in place for our data security? Would you use any Cloud services? I think Amazon Web Services is relatively safe, but you mentioned Google Docs and Dropbox [INAUDIBLE]

      ERIK JONES: OK, so the question is, is how do we secure our data when we're using sort of public spaces like G Drive and Dropbox? So it's Cesar.

      CESAR ESCALANTE: Well, we know the limitations of Google Drive. The kind of information that we place there are the CAD exports, which are the civil files. We talk with the client and the consultants about those risks. We don't think the information contained in those files exposes the client to major breakouts. There's nothing interior that is there.

      But I agree. I mean, we didn't want to incur an additional-- we fought the bottle of securing the procurement of C4R. I didn't want to fight another battle to get for a way to securing these files using another platform. It was an additional cost.

      AUDIENCE: So you're not encrypting anything. It's just standard, out of the box?

      CESAR ESCALANTE: Like standard-- maybe we'll look-- I heard that Autodesk is working with a plug-in called Autodesk Drive, which has the same encryption properties of C4R. It's now available for Revit 2018 and it's in beta I still believe. It's in beta. And we couldn't use it because our projects is in Revit 2016. But we are talking about upgrading our files for next year. That's probably the top of our next class.

      ERIK JONES: And some of us know or all of us know that jumping from 2016 to '17 poses a huge challenge. So it goes back to going from one platform to another, so investing in C4R. So the next conversation with management and other shareholders is getting us from '16 to '17 and then we'll go directly into '18.

      RYAN KOCCOUREK: Just to be clear, we don't house our live Revit models on Google Drive. It's really the CAD files that are being received from outside consultants. We do receive one Revit model from our baggage consultant, a data model. But we try to minimize that. That is on that resource too.

      ERIK JONES: Go ahead.

      AUDIENCE: With a large project like this, when you make the jump from '16 to the new version, do you go to the current version or do you just go [INAUDIBLE]?

      ERIK JONES: So the question is, would we just jump from '16 to '17 or would we go to '16, '17, '18? I'll let Ryan answer that.

      RYAN KOCCOUREK: Yeah, we did look at both scenarios. But the biggest leap in upgrade is to 2017 and then once you go 2017, it's very simplified to get to 2018. So for us, we would go as far as we could. Especially because of the client's needs. In this case, this is a very long term project. They're going to want to have the most current information as the next phase comes on board. So we did consider those things. So we will jump to all the way to the 2018.

      CESAR ESCALANTE: Our concern is the changes on the text that may compromises the information that's already out in the field in CA. And Shaun actually developed a Dynamo script that helps scale down the text by a factor based on--

      ERIK JONES: So we'll likely go through a Bluebeam overlay effort with the CA team to validate that we're not changing or adding scope, we're just tweaking text and just do a one off and have a huge session about that to convince them. And I think the other thing is that C4R as a platform, 2016 is the beta test. So there's a lot of tools available in '17 and '18 that we don't have, which is going to be part of our validation for getting the project up to '17 and then quickly into '18. Go ahead.

      AUDIENCE: I was interested when you talked about the volume of the drawings you have to print--

      ERIK JONES: Yes.

      AUDIENCE: --for this paper aspect. Have you looked at getting rid of that somehow?

      ERIK JONES: So the question is, is when we say when we're printing are we printing to say a hard copy?

      AUDIENCE: Yeah, is it actually paper or not?

      ERIK JONES: No. We do PDF, so, you know, we print throughout the week. But the Monday morning exercise is working with admin to slipsheet the sheets into our huge Bluebeam project, which takes a day turnaround. But the idea is that four days out of the week, they don't have a drawing that's older than four or five days.

      AUDIENCE: And what do the contractors use on site then?

      ERIK JONES: We provide them access to our Bluebeam project, but we typically do sessions. And so the CA team, including me, generate one offs Bluebeam sessions to track specific bulletins that are going out.

      The contractors themselves have their own set of drawings and they use platforms like ProjectWise to shield their information and then we basically just transfer it over on one off cases, usually during bulletins and IFCIFRs.

      AUDIENCE: I did wonder-- the last question. I wonder how live your subcontractor's models actually are?

      ERIK JONES: So the question is, how live are the models that we're coordinating within the Cloud? So the first generation of our Cloud-based transfer was a 24-hour turnaround. So Shaun set up a process where every 24 hours all the models we get up to the Cloud and then downloaded to local servers. With C4R, everything is up in the Cloud. So I may get a call from New York telecom saying, hey, I just made this change. All I need to do is reload and I get that change in real time.

      AUDIENCE: But subcontractors, they're happy to work in what is essentially a truly live environment?

      ERIK JONES: Yes.

      AUDIENCE: Are there no commercial issues?

      ERIK JONES: So the question is, is are commercial issues with subcontractors having live models?

      AUDIENCE: And example, HOK makes a change on their model--

      ERIK JONES: Yeah.

      AUDIENCE: --which affects the subcontractor. They work. And the next day you move it back. These issues become commercial contractors.

      ERIK JONES: Do you want to answer that, Ryan?

      RYAN KOCCOUREK: Yeah. I don't believe-- at this point, they're still working off of a model that is dated from a deliverable and that's what they're using. So they're using a federated model that-- so it's not, they're not live to our current design model at this point. Yeah.

      CESAR ESCALANTE: We're in a phase 2 design. This hasn't gotten into the construction phase yet. We don't see the contractors, the subcontractors there.

      AUDIENCE: But if you're doing design build, just like we do some design build using C4R, you still have that deliverable, that that's what they should be working on until you issue a bulletin.

      ERIK JONES: Right.

      RYAN KOCCOUREK: Yes.

      AUDIENCE: So that even though they can see the live change, they know it's coming.

      ERIK JONES: Right.

      RYAN KOCCOUREK: Yes.

      AUDIENCE: But until you issue that--

      RYAN KOCCOUREK: But as a protection of the architect.

      ERIK JONES: But to be clear, we don't have that relationship currently with our contractor. We have that relationship with our subs in the disciplines in design. But the contractor is provided deliverable federated models.

      RYAN KOCCOUREK: And a design build, that's definitely a different environment. That is a relationship that you build and you are negotiating between that gray area of errors and things that are accounting for it. In this relationship, it's more traditional. We're protecting ourselves that the digital design information is dated because of our delivery, so that we know they're matching, that there's not variation and changes happening between us.

      CESAR ESCALANTE: Well, we have to cut it down now.

      ERIK JONES: Sure.

      CESAR ESCALANTE: We can answer more questions in the hallway.

      ERIK JONES: OK. Thank you, everybody.

      RYAN KOCCOUREK: Thank you.

      CESAR ESCALANTE: Thank you guys.