Optimizing Deployment Projects

Explore the revolution in construction design and efficiency discussed at the recent presentation event. Join Alex Kunz as he unveils a groundbreaking approach to data-driven, modular design, reducing construction timelines and enhancing adaptability.

Join PPI


In the presentation, Alex Kunz presented a transformative methodology for construction design, emphasizing data-driven modularization. Beginning in 2015, the focus was on crafting a modular product architecture, steering away from the conventional slow-paced design process. Kunz stressed the importance of balancing modular and integrated approaches to meet diverse customer objectives. The product development phase showcased a unique process, applying industrial-style verification tests and checklists to build and refine products before field deployment.

The presentation delved into the intricacies of computer-aided production engineering, where the product, process, and resource were integrated into one model for enhanced design behavior and adaptability. The system’s architecture, product development, and project deployment were detailed as the three pillars of their methodology. Notably, Kunz highlighted the success of reducing design time to under 22 minutes through the implementation of artificial intelligence, providing unparalleled adaptability for clients in a rapidly evolving construction landscape.


[00:00:00] Alex Kunz: Thanks, Gary. We’re going to talk data sets and a couple of other projects too. So this is what our deployments tend to look like. The, pretty big industrial projects, a lot about power distribution and a lot of cooling, things like that.

[00:00:22] Alex Kunz: When we say deployment, we’re putting these in lots of places around the world. So the name of the game is not copy exact, but certainly adapt. Reuse where we can, attend and deploy, and make lists around the world. Our journey began really in about 2015 with this group. At that time, it was about designing the gear.

[00:00:46] Alex Kunz: Built in 18 to 24 months. That was the target. The reality sometimes diverged from that. And it was, this is what we replied. A lot of coordination meetings. Hands on, hands on. Although it was a pretty slow pace. That little picture, very tightly integrated design, a million interfaces, very difficult to peel the design apart.

[00:01:10] Alex Kunz: Part of that’s because the requirements that you see on the right side there are written like, like Shakespeare, it’s, it’s a lot of prose. It’s difficult to understand that most easily the project requirements when they’re written in the format of a B2B. As a effectively a block hard to reuse that.

[00:01:32] Alex Kunz: So we were poking around and we said, maybe there’s some opportunities to, reuse designs and geez, if it’s, if it really will days where the data center could be, can’t redevelop a configuration engine, I don’t like this, but we adjust some parameters, like say, number of rows and data center tracks capacity, sometimes you want two stories and then we need four.

[00:02:00] Alex Kunz: For more if you do that, I need some more substation. Can’t we just build those rules into a file? It’s just the model and then have the design adapt for us, right, for our eyes. And so we showed this to project teams we were working with and said, you know, Presto, look at that. It’s like an incident data center.

[00:02:21] Alex Kunz: And we don’t think we need a year to design this thing. That’s 2015. The answer is, of course, I mean, that’s, that’s not quite a data center, but the ideal is compelled. If I need to do these things all over the world and I need to do it to be competitive, surely there’s a way to drive speed into the design and construction process and then you doing so drive quality and the network.

[00:02:53] Alex Kunz: So we set out an app to achieve that. We want, what’s in the bulky model I want is to design and, and I want standard instruction, but I need to do a number of different things, get there. So this is what that look like. First, we set out on deploying a modular product architecture and the topic about the dent needs.

[00:03:12] Alex Kunz: Probably everyone has a system architecture to the designs of what you’re working on. Sometimes it’s modular, sometimes it’s reintegrated. It’s best to be in control of that. It has serious consequences. All I have is downstream. We got involved in a major product development program to deploy products into our projects around the world.

[00:03:34] Alex Kunz: To deploy our product into the projects. around the world, which means we can’t just make the products and then release them to the grand public and they’ll get used. We have to integrate them onto a job site. And we’re doing a bit of a dance between a industrial manufacturing approach and a classic construction approach.

[00:03:53] Alex Kunz: And then, of course, we get it to seal the planet. What happens if it’s sealed? So there’s a number of different things we do to hit on these four buckets. And we’re going to talk about what those look like as we go. But the first moniker that there is. Great background for all of this in consumer products, even at Eger, MIT, there’s a lot of really great lessons to apply from aerospace, other vinous that deploy ation this approach to pots.

[00:04:28] Alex Kunz: So we bottle the system architecture, we model the system architecture. We go define what are the requirements of. A cooling system or power distribution, data center, offer prep. If we’re talking about vaccine production, there’s a number of different punctual requirements for our customers that will go auto, identify what components satisfy those requirements and then package them up into what is actually the modules at products.

[00:04:59] Alex Kunz: We then model the configuration. There’s something, you know, sometimes we do this whiteboard. So to sell, sometimes we’re using the suites. This is the Swedish company. We like. We used to use the Germans, but they product went out of business. There’s different platforms we use for auto like the product architecture.

[00:05:19] Alex Kunz: And this is another view of what it looks like, right? Every project has a built in system off at Parkinson’s. So it was leveraged the model. The first is understand what it is. So this picture up here, that’s what we would call in dairy type, the integrated product architecture. And as you imagine what the consequences are, you were.

[00:05:41] Alex Kunz: System be tightly integrated. You might get unique performance, but you have countless interfaces to manage calf plus dependencies. Very difficult to replace anything. Very difficult to commission. Difficult to operate, difficult to build. So we’re in the business of crafting a balance between modular, integrated in a less the right amount, given the customer objectives.

[00:06:07] Alex Kunz: The other thing we do is build out very substantial or breakdown obstruction. WBS, I think you get a conventional sense, it’s like a convenient e voicing tool. In our world, it’s really a taxon. We’re really trying to understand the nature of project and how do I break it down from major systems to minor, to platforms, assemblies, products, owners, reach it, machine level piece.

[00:06:35] Alex Kunz: And we do that for a number of reasons. One, we can either. Analyze the projects and understand how bad things are. And bad to us means uniqueness. So we can understand where the reuse is. Or two, we can use to drive the reuse. If our number of discrete values in the WDS gets really high, then we know there’s going to be a lot of variegation.

[00:06:59] Alex Kunz: We use that to drive standardized designs. Okay, let’s shift gears forward a little bit. Out of the way. Product architectural load in product development. There’s a few features of what this looks like. We use a different process. We’re not in a classic design development, instruction documents, shop drawing phase, like none of that exists in product development.

[00:07:22] Alex Kunz: We’d applied more of what the industrial group would call an NTI, new product assertion type process that features things like EDT, DMT, PDT. These are verification tests, checklists. Basically we build these products before they get released out into the wild. That’s an unusual approach. In the building industry, usually the building is the first to occur.

[00:07:48] Alex Kunz: And if we’re truly in the product development business, that’s not. We don’t get to do that. We don’t want to find out if it works in the field and do some testing. Our product development efforts are also shielded from projects. They take place with discrete teams. Which means it’s not an ADT. They look different, right?

[00:08:09] Alex Kunz: We get different outcomes because we’re using different teams and that I would describe this as like total product and process design. There’s a tendency that building industry or industrial like stay away from the detail, whether it’s I want to stay out of the nuts and bolts design, I want to stay out of these methods.

[00:08:27] Alex Kunz: And we’re really taking a very different approach of like, we’re going to get into all of the nuts and bolts, the threads, on screws and the means and methods for equipment. This is just an artifact. We’re not supposed to be this of like what the PLC product lifecycle or NPI, what that process looks like.

[00:08:47] Alex Kunz: But the key thing is there’s a series of steps we used to check along the way. Another thing to highlight when we say product, what we’re interested in is how the design behaves, and in particular, outlet design, Hayes, as we change things and so we create rules just like that hokey movie from the beginning.

[00:09:07] Alex Kunz: The set of parameters is driving the design, but we craft the design. We do that on every single product. We build the rules so that we can then choose what our configurations are. If you see, you have a talk, I almost always, I have to use that picture. I’m very inspired by the automotive and aerospace industry, but we’re applying the same approach of let’s have platforms that support many different configurations.

[00:09:34] Alex Kunz: We do this because the customer doesn’t always want the same thing, can’t just build a product. We worked it out, and I said, we need to be able to configure, so we need optionality, so we need behavior. There’s another artifact of what that looks like in our world. It’s one model, made to fix, there’s behavior built in.

[00:09:55] Alex Kunz: And this is a little different than the world I grew up in, where we needed a design change. It’s like an act of Congress. And it launches up the 400 person crafting. To us, design changes are not a crafting issue, it’s not a chain order issue. It’s more of a system issue of crafting the way I want the design to behave.

[00:10:14] Alex Kunz: Yes, I can make that chain, and here’s what will happen. And I know what the consequences are. Because of my either modular product architecture, or a few consequences, or integrating it, where I don’t like it, I change something. With a product development, we also have this key team, computer aided production engineering.

[00:10:35] Alex Kunz: What those guys are doing is designing the product, process, and resource. We use a specific platform for this. This is what one of, this is an example of a module within a product, the top left, and then we also develop the process, the how, how it gets built. We do that with mechanical engineers. They, they go to factory floors, they go to job sites, they listen.

[00:11:00] Alex Kunz: Big part of design, we just sort of listen to what’s happening on the real job site. And then we craft an integrated model. We reflect the product, the process and the resource in one place, in one model where we have behavior, we can see how the model behaves. To us, a model is tends to be based, but it has process and resource captured.

[00:11:26] Alex Kunz: Insane product architecture, that’s the design, but we like that because then it can reuse the product, but we can also reuse the process. So when we’re innovating and building something new, we don’t have to go start scratch, develop a whole new process, or go ask the GC house like they can have them. We have a catalog of products we can’t buy.

[00:11:51] Alex Kunz: Okay, so we’ve been through two, we’ve been through system architecture, product development, now on to the third. Hector of our work project deployment. This is really the integration aspect of the work. Again, a product is a cooling system, power transmission, buffer prep vaccine, any number of different system that we captured, the scenery modules, that’s no guarantee that it’ll work within the context of the project that the whole, and there’s usually a big break between the product design teams.

[00:12:29] Alex Kunz: And then the ADs, the engineers of record, site adaptation, the taking of this catalog on it, the insertion of it into a specific job site. There’s lots of reasons for that. Organizational codes may be different. There’s any number of reasons why it crops up. So we use people, real people. We call them technical design integrators.

[00:12:49] Alex Kunz: They also tend to be mechanical engineers. Nature. And they are the ones doing the actual integration of multiple products into job sites. And this is what that tends to look like. These are products on the left side, these job sites on the right side. And we just use our, you know, we use our eyes. We go look at how the products are coming together.

[00:13:10] Alex Kunz: And then we verify, I guess, actual requirements and you’re factoring all that good stuff. And then all of us to process it together. The player, you could say, a very technical terms, the stage voice of rep yourself will tell you’re familiar with that. But it’s become the B and C platform building design, to the detriment of performance.

[00:13:34] Alex Kunz: So we do a lot of work managing the, the dance between manufacturable data builders in one world and documentation, the minimalism second. So we feel we’ve come a long way from the job site eating where construction is trying to complete design. And people are on their elbows wondering what you think charitable Navisworks coordination process when we don’t have that so much in that went away because we end a lot of this very high precision design and coordination up front, but that’s no guarantee of success.

[00:14:09] Alex Kunz: We then need to roll out standard process into this deal. So we have effective construction management group are a big part of us here today focused on production in, in New York. In our world, that tends to start with staining a process. That’s what one of those looks like. They get more complicated.

[00:14:30] Alex Kunz: And then what we’re really in the business of is all introducing the process out to the field. Because if you remember the map, there’s not one city, not one state, not one country, and not one region. These things are That we’re deploying, they’re going everywhere and there’s no one builder or supply chain that can serve the progress, which means we have a lot of variability against the people, the people are always different.

[00:14:59] Alex Kunz: So we’re going to have a different team all the time, but better out of steam process, I think, and what the owner’s request was, geez, I just want to walk on two jobs at the same time, see the same thing. Can I do that? Doesn’t that make sense? And we agree, and the analogy we like to use is when you’re Toyota and y’all launch a new factory by asking the local region, what do you think a Tacoma should look like this time?

[00:15:24] Alex Kunz: It’s very top down, and we take the same approach of being very top down, and then leveraging very high precision 3D modeling to verify that we’re doing the right thing. And then we have to really benefit the luxury that I’ve done in a couple other places to bring something less than a square. So.

[00:15:43] Alex Kunz: Product and process gets implemented, rolled out, a lot of templates, a lot of learning, a lot of psychology to, like, hey, don’t tell me how to do my job. It’s opened up lots of other interesting opportunities, such as 4PO, 4 Party Logistics, where the owner team is saying, geez, this is great, I can handle demand.

[00:16:02] Alex Kunz: Now that I have all this insight across multiple projects, have this very rigid work breakdown structure, all this data I can mine, I can get really savvy on procurement. We’ll see how that plays out, that, that, that story is still being written. Oh, we do have a lot of good details. So to recap, come a long way from the original configuration where we said we should switch from design in a year, design in a day.

[00:16:35] Alex Kunz: We’ve rolled out these four pillars of work, let’s say, MPA, product development. The integration work is really about site adaptation and in the field of actual management. The consequences of what’s happening is that we’re now doing designs in under 22 minutes. What we say at design, this is about 500 million dollars worth of construction, and then another 500 million in equipment goes inside the building.

[00:17:00] Alex Kunz: It was pretty substantial, it’s like the photograph I showed at the beginning, but now there’ll be about 15 of those of one site. The catalog of products has grown. It started at one or two sort of school bus size integrated systems. And we’re up to about 50 of these things right now that was important for adaptation.

[00:17:23] Alex Kunz: So as market demands as what our customers, customer wanted to buy a change, they were able to adapt. Yes, anyone here has read machine to change the world, which is a really an old is like one of the great punchlines with Hey, we think Toyota is going to become the largest car manufacturer because not because of just the time because they’re, you know, they will develop some technology that Clean the clock of every other car comes into bits out there.

[00:17:53] Alex Kunz: And incredibly that kind of happened with hybrid tech. We, well, after publishing that book, and we’re seeing something like this play out at the data set space where the AI and now worse, it’s like very real. So we read in the news, a lot of the buzz artificial intelligence. What that’s done to us was we threw away all of our high level, top, top data set and fixed.

[00:18:19] Alex Kunz: And plucked out the AINL pods that we needed and reconfigured the solution and rolled it out to the field in under 22 minutes. So the client’s ability to adapt with the customer where they need this is a good shit and it’s working really well. That’s allowed them to drive an acid, acidy increase. Yeah.

[00:18:38] Alex Kunz: As the supply chain gets more complex and then in TBI terms, there’s year three success and most benchmarks is in pretty good shape. Revenue’s going up, props going up. And certainly Barclay as well. Applause there. Thank you.

Read More


Read Biography

Alex Kunz, PE


Alex Kunz, PE


Alex is the principal at A.G. KUNZ, a company focused on systematizing the construction industry through an integrated approach to design and construction.

The company helps owners deliver complex construction projects around the world through its technical design integration, production engineering, and software development services. The company is particularly focused on the global datacenter industry and driving accelerated project delivery through model-based design, analytics, and project production management.

Prior to starting A.G. KUNZ, Alex led the services group at Gehry Technologies, an award-winning consulting and software development company that brought together architects, engineers, builders and computer scientists to help deliver many cultural, hospitality, and civic projects of note around the world, with a focus on construction precision and cost predictability. Prior to that, Alex was a technical engineer and consultant for Strategic Project Solutions, serving projects such as Heathrow Terminal 5, the retrofit to London’s St. Pancras rail station (CTRL), and industrial and energy facilities.

Alex is a professional engineer in the state of Colorado and received his B.S. in mechanical engineering from Cornell University.