Demain's Journey from Strategic Partnership to Commercial Entity

ALEX JONOVSKI: Hi. Thank you for tuning in. This is Demain's Journey from Strategic Partnership to Commercial Entity, part of Autodesk University 2022. My name is Alex Janovski. And although, we will have some in-project examples, this is not necessarily a technical, instructional presentation but really more of a case study of how collaboration between several companies evolved into its own independently operating entity. So hopefully, there's something you can learn from our experience.

Like I mentioned, my name is Alex Janovski. I lead at Demain. At any time, you can go ahead and scan that QR code, and you'll get my digital business card. On that, you'll have access to our LinkedIn, the website. You'll have my contact info, and you'll also have the ability to schedule a meeting with me if you're viewing this and you're interested in scheduling a follow-up meeting.

But my background is in mechanical engineering. I spent a decade at KLH Engineers and started with mechanical, HVAC, plumbing, fire protection design, got into project management, eventually as a principal and vice president of strategic growth before ultimately transitioning over to Demain earlier this year.

So there's four learning objectives that we'll get out of this presentation today. First one is learn about the industry problems that inspired the formation of Demain. These are the pain points that drove us to take action and most likely challenges that you may also be facing as well.

Learn about the history of how Demain's evolved from a branded collaboration to an own operating entity. This has been four years in the making. And although the why hasn't changed, the how and what have matured tremendously.

We'll learn about the challenges the consortiums had to overcome, many lessons learned on this journey, and then, finally, discover new insights that will help you implement your own industrialized construction workflows. Hopefully, you can glean from our experience to develop your own improvements within your own firms.

So before we focus on the industry-specific pain points, I think it's helpful to provide some context on how construction sits alongside other industries. And there are things that we tolerate externally that we don't tolerate internally one of which is, when you get a text message from your friend and maybe it's got an address in there and you hold your thumb on that address and it pops up and it says, here's where you're meeting me at.

Says, do you want to open this in your maps app? And click over there, and it pushes that address from your text messaging app to your maps app, gives you directions automatically on exactly-- directions on how to get there. You're pushing that data seamlessly from one piece of software to another piece of software. And that's something that you've come to expect in your personal life.

Now, that could be something that really doesn't happen all the time inside your professional life. How many times have you had an Excel spreadsheet where you're doing a calculation, write down the answer to that calculation, pop open another piece of software. You type in the answer.

And so imagine also all of the calculations and pieces of information you're doing that you communicate via an analog PDF or book spec or something to somebody downstream, a contractor, or asset manager, or whatever it might be. And they're reading your drawings, and they're writing it down as well. There's not always at that push of data, but it's something that you would expect in your personal life as you're going through, something as simple as receiving a text message with an address.

The other example is in the world of manufacturing. Would you send a car down a manufacturing assembly line twice? It's kind of a rhetorical question. Of course, you wouldn't do that, right? But imagine the scenario of a car going down a manufacturer assembly line. 3/4 of the way through, and you come to find out that we can't afford the doors on the car.

And so you take the doors off of the car, put it back to the beginning of the assembly line, and run it back down with cheaper doors. Now, that feels like a value engineerings exercise, right? There's many times where you'll get through design, maybe you begin site work, even portions of the building.

You come to find out there's a particular system that doesn't fit within the budget. It doesn't have the right lead times for the schedule of the project. And all of a sudden, you've got to put that redesign work back in, find a new system, find new equipment, redesign it, start the project again. It's essentially taking that car, if you're thinking of that manufacturing analogy, and putting it further back up the assembly line just to rerun it again.

Again, would not tolerate that in the manufacturing world. It's normalized, quite frankly, in construction. So these types of expectations that we have within our professional lives and how they differ from what we expect outside of construction.

Just another comment on the industries surrounding the piers of construction. This is an excerpt from a McKinsey study-- it released a few years ago-- on productivity over the decades since the end of World War II and various industries. And you can see pretty clearly in agriculture and manufacturing and a couple of the other industries there, the productivity that's increased dramatically in the decades passed since World War II.

And you can actually see construction flat lining. And after a brief increase for the first couple of decades after World War II, actually decreasing in productivity. And it speaks to the lack of digitization, and we're starting to see more and more of it in construction, but the past 50, 60, 70 years really hasn't kept pace with the other industries and from a global market perspective.

So now, we zoom in a little bit further into the world of construction and try to understand why are we not productive as some of these other industries? What's holding us back? And I like this graphic. It shows a little bit of those efficiencies in a little bit more granular scale.

What you have here are the different columns of a project delivery. You have the owner, the architect, engineer, so on and so on, all the different stakeholders that are deploying the project.

At the very bottom, you've got this dashed red line, and it's got this sawtooth motion to it. And you see the increase within the column, and then, as it goes from one column to another one, you see a sawtooth down. So if you look under design build contractor, that increases as it goes to trade, sawtooth down. Increase again within trades, as [INAUDIBLE] sawtooth down.

And what that sawtooth down represents is the rework from phase to phase that increase represents the value that's added by that particular stakeholder. So for example, if you were to look at engineering, you see that increase that's going up. That's the value that an engineer provides to a particular project. That's them doing the calculations, lay out, everything that an engineer does for the project.

But you see a sawtooth down as it goes to bidding and estimating. The bidding and estimating has to go through a rework process just to digest the deliverables that were given to them by the engineer. And the engineer is going to give a [INAUDIBLE] team a PDF floorplan and a book specification.

The estimator's got to go through that PDF floorplan. They've got to count every single light fixture that exists within that floorplan. They've got to look through all the specs and just figure out what's going on.

That's a lot of risk, takes a lot of time. And you compare that to that earlier example I talked about with that address and how you just push and pull that out from one software to another one, what's holding us back from sending a bill of material from an engineer's model directly to the estimator, and how much time that would eliminate on a take-off exercise.

But there's rework that the estimator's doing. There's time that's being wasted and just understanding what's going on because they're not provided the deliverables that they need to do their work. They're getting the deliverables that the engineer provides. They've got to translate that to get the deliverables that they actually need to do their work.

And so what the concept here is, well, how can we use data, how can we use information in a way to mitigate some of those sawtooths? And if we were to collect data in the very beginning, iterate it, validate it, optimize it throughout the project, find ways to push and pull that information between all of the stakeholders, is there a way that we can get rid of all of those different sawtooths down, and so that there isn't a sawtooth down.

There isn't a rework that's happening between each of these phases, and you start to understand that this difference between the streamlined flow of information where nothing is recreated and that sawtooth. It really represents the potential that we have within our industry. That represents the difference in the optimal delivery model. That represents lower costs, higher quality, quicker timelines, and how we deliver our projects.

Zooming in just a little bit further on some of those relationships, in this case, between design and construction, we've got a few bullet points here on how some contractors have viewed design professionals in the past. And this is pulled from actual polls.

So in the months leading up to the formation of Demain, as I was with KLH and some of my partners there, KLH presented a series of contractor peer groups. And at the time, it was to show off some of our design tools and to also understand more from the contractor's perspective of how can a design professional better serve the contractor.

So we asked those contractors what do you think of engineers? What do you think of design professionals? And these were the answers they provided, and these were pretty consistent across the country. And these peer groups went from coast to coast. These were national contractors.

They said they were a necessary evil. They felt engineers were arrogant, uncoordinated deliverables, poor communicators. And maybe if you're a tradesmen or tradeswoman now, you're look at this and this resonates with you. If you're a design professional, it's got candidate relationships with contractors. Maybe see this, and you've heard some of this feedback.

If you're a design professional, you're reading this and you're getting a little defensive, I'd encourage you to reach out to some of your local contractors and engage and see what they really think. But I think the key that was given to us from that feedback was, at the time, I was an engineer. It was design professionals, you need to understand, regardless of who is holding their contract, the true consumer by deliverable is the contractor.

And that's important because, in an engineer's case, for example, an architect holds that contract from the engineer many times. And the architect is seen as that client of that engineer. The ones paying the engineer to do their services. And it's very easy to only think of the architect when you're doing that deliverable.

But it's this paradox that we have that engineer's contract is held by the architect, but the deliverable of what they're producing is actually a deliverable for somebody else. And the first step to eliminating the sawtooths within that red line I showed in that previous slide is, as design professionals, humbly accepting their role within the project delivery.

And how do trade firms view each other? It's not limited to just the gap between design and construction. There's also that gap between the trades that happens out in the field as well. And we have ways that we do use today to try to manage that. And you might have challenges to spatially coordinating everything, getting them to fit above the ceiling. Or maybe their priorities aren't aligned.

For instance, maybe electrical needs to purchase the switch gear today to meet the schedule of the project given the lead time of that switchgear. But maybe HVAC isn't ready to order it because the equipment selections aren't final. And as that equipment selection gets final, that's going to affect switchgear sizing.

So you see this conflict of priorities of, well, what do we do? If we don't order the switchgear today, we're going to run the project late. And HVAC isn't ready to confirm on a size.

So it's really these types of experiences between the trade firms, between contractors, but also between design and construction, these types of frustrations that help to reinforce some of the pain points for Demain in the early years leading up to the formation of just there's got to be a better way. There's got to be an easier way, a better way to deploy construction. And those are the things that inspired us to take action.

And that's why we created Demain, and Demain is a consortium, seeks to bring joy to construction. And as a consortium, it creates the structure for its member companies to deliver the built environment through data manufacturing. And even the name of Demain lends itself to the coming together of the silos, design, the DE, manufacturing, the MA, installation, the IN, Demain brings all of that together into one.

And the current roster of members within Demain are also the founding members of Demain. You have DMG, which is a business consultant out of Sacramento, California. They played a significant role in consulting the other member companies but also providing the introductions between the other member companies to bring some of these folks together at the table originally.

You've got Rex Moore, which is one of the largest design build electrical contractors in the country. They're based out of Sacramento as well. Construction Innovations, again, based out of Sacramento. Construction Innovations you could think of as a lean electrical manufacturer, provides assemblies, kits to support installation on a variety of project types from buildings, but also very large presence in the renewable energy space, specifically in utility scale solar.

You have KLH engineers. KLH is nationally-ranked MEP consulting engineering firm based out of [INAUDIBLE] Kentucky. They've got a software engineering department that allows them to create a lot of really proprietary, really cool design tools that creates a lot of efficiencies, increases quality for their engineering, but also allows them to implement some really unique strategies on building information modeling.

And finally, we have Tweetgarrot Mechanical, one of the largest design build mechanical contractors in their state of Wisconsin. And they have their own means to manufacture kits and assemblies as well. And they offer a nice complement to the combination of Rex Moore and Construction Innovations just on the [INAUDIBLE] employment side.

And so combined experience, 300 plus years of experience. Each of these companies are very much strong and innovative in their own respect, especially focused in the areas of data and manufacturing as it relates to the built environment. And the consortium's role is really just to pool those resources of its member companies to solve the problems that otherwise couldn't solve individually. And Demain does that by providing the means to integrate with one another and unique entries into the market.

Brief timeline of Demain. So again, this was not an overnight thing. This was something that's taken years to develop. The first meeting was in 2018, and at that time, it was the company's come together, understand that we're going to do something.

We're frustrated with our experience within construction. There's got to be a better way we can leverage the data means of KLH and the manufacturing process of the other companies in some way to execute the built environment in a much better way.

Exactly what that was, I'm not sure we had a firm idea or an aligned idea of exactly how that would look. But we made a commitment to one other to do something. It was really that fall where we started to work together on projects, and I'll show a couple of examples of Demain members working together and some of the things that we were able to figure out that helped push us forward.

But those first project between Demain members, you start to see things like a contractors from Tweetgarrot driving, supporting the engineer at KLH and advising them on how to lay things out, what materials you should be using and giving the contractor perspective. And you started to see a lot of this cross-pollination of expertise and strengths from the different member companies strengthening everybody.

Started solar collaboration, which I'll talk about a little bit, in the spring. Participated in a summit in Denver in March 2019. Gained some early advocates, got some early market feedback on what Demain should look like. Began co-locating employees later on that fall. I'll talk about the share cloud Infrastructure in the next slide, and launch that in February 2020.

And then, finally, all of this led up to the decision last year to establish Demain as its own independently operating entity, and prepared for launch in spring of 2022. And so you can see this escalation of trust over the years and developed relationships over the years that led us to the point that we were confident that this was the right move with the right partnerships together.

And for this consortium to reach its true potential for all these companies to reach the true potential, it was time to establish Demain as its own independent company.

Shared Cloud Infrastructure, I alluded to in the previous slide there. One of the challenges that we had within Demain was how do we align the workflows and information flow from member companies and a member company. And in order to do that, we launched Shared Cloud infrastructure, and that allowed Demain to operate is really a facilitator and a storage for information, for software.

And some of that software is custom software that some of the member companies developed, and that's a great way to help align workflow. So at that point, KLH developed quite a bit of design tools, engineering tools, whether it's a feeder calculator or a tool to help set up models or tools for panel schedules or HVAC loads, whatever it might be.

And in order to gain alignment and how we all leveraged those tools, putting them in a central repository where any Demain member company would use those tools-- and they would actually standardize around them-- was key on getting some alignment with workflows.

And what you had over the years is not just KLH having software engineers developing those tools, but Tweetgarrot, Rex Moore, Construction Innovations also hiring their own software engineers. And then you got to the point where the software engineers from the different firms, they're huddling together every single day.

They're getting feedback from engineers at KLH, folks from the shop at Construction Innovations, folks from the field at Rex Moore, Tweetgarrot, and the engineers at Tweetgarrot and Rex Moore working with the engineers at KLH. And you've got the best of all of these companies coming together and creating workflows that supported everybody's needs.

And so, slowly over the years, you start to see alignment on these workflows. And by placing that software, not on somebody's private server but on Demain's server and using Demain's at central spot, now everyone had access to that software, and you start to see some alignment.

We also use this central cloud for prefabrication libraries that the manufacturing facilities produce so that the engineers are using those libraries when they're doing their designs. Talk about an example in a little bit where Tweetgarrot's prefabrication library lives on the Demain server. And because it's on the Demain servers, KLH is able to access it. And they actually use that prefabrication library in doing their designs. That's really informing how they're designs. That's limiting the choices they can make just to what's available within that shop.

And then we'll also use it to facilitate the flow of information. So if you've got an engineered model that KLH has produced, you're very easily able to push that information from that engineering model to the manufacturing facility at Construction Innovations or the spooling machine at Tweetgarrot, and push and pull that information in a really seamless way.

So that's 1/2 of the coin of the structure that Demain provides. The other 1/2 of the coin that differentiates the member company's at Demain is this ability to deliver manufactured assemblies. And so these are a couple of overview shots of the facilities that Demain member companies.

On the left, you have Tweetgarrot's facility. On the right, you have Construction Innovation's manufacturing facility. Combined, it offers up about 450,000 square feet of manufacturing space. And these are run, these are thought of, these are operated as manufacturing. This is not a typical prefabrication space to where you're just looking at a drawing and looking at a project and seeing what can you put together on that particular project to save some time. This is viewed as a manufacturing facility and trying to productize. And as you do productize, how do we take that productization and use it to inform design on the very front end so that what you're getting is really just a productized design as opposed to productize and design after the fact.

And the benefits for manufacturing we'll talk about as we show a couple of case studies following this, but that predictability is the biggest thing. And the predictability of within a project as the project goes on, predictability from project to project to project to project, and the ability to precommission and factory test and increased safety.

You can imagine the tools you have are readily available. You're working inside a conditioned warehouse as opposed to on a ladder outside in the snow during the winter. And so you get a lot of benefits from having this manufactured deployment style.

So a couple of case studies and how we put data and manufacturing together to create some differentiation in our deployments. We'll use a solar example here. And so that's one of the first areas that Demain member companies collaborated on. And these were utility-scale solar projects.

And Construction Innovation heading in Demain was already established leader in the space and providing manufactured electrical solutions, kits and assemblies for utility-scale solar. And here's just a couple of examples of the types of kits and assemblies they're are providing.

You can see, on a given project, they might have 1,800 feeder kits. They have string wire kits, combiner box assemblies, and they're seeing some of the benefits that we were talking about earlier, right? You're able to factory test. You're able to factory inspect. You're able to leverage just-in-time shipping to help support flow on the project site. And predictability, predictability and cost, predictability and quality. And they were seeing that.

Now, what we wanted to do, though, is combine that with KLH's ability to derive data-driven workflows. And so just to give you a sense of scale before we get into that there of what these projects look like. These are large-- hundreds of megawatts potentially. And you're getting hundreds of thousands of zip ties, and miles of wire and hundreds of thousands of individual wires and hangers.

And so there's a lot of components that you've got to organize. Now, it does lend itself well to manufacture deployment given how repeatable it is. And there are fewer stakeholders on this than, say, a hospital project, right? On a hospital you've got many trade. You have many contractors. You have many design professionals. You have many folks that you've got to coordinate through and challenges.

And so that's scheduling and procurement and all of that is much more complicated on a building project than on a solar-scale project. But that was kind of the benefit. It served as a testbed for us in developing some of these data-driven manufacturing workflows within the Demain teams.

And so what we ended up doing here, and on these projects Construction Innovations actually would receive an AutoCAD file, a two-dimensional AutoCAD file from a third party engineer. And that would have the basic engineering schematic on there.

And typically, what they would do is they would take that AutoCAD file, and then they would convert that to PDF. They would mark up that PDF with a field engineer reviewing it, marking it up, and saying, OK, we're going to use assemblies here. I'm going to use these kits here. I'm going to manufacture these portions here. I've got these-- and they're marketing up with the standards of their shop.

So there was a conversion that needed to happen, and it happened manually in analog with a field engineer marking these up. Now, [INAUDIBLE] there's hundreds of thousands of wires. There's hundreds of thousands of zip ties. There's millions of feet of wire. And so that's a large task to take on as an analog effort of somebody going through and marking up a PDF of all this.

And so, what we did was we took KLH's design software team and Construction Innovation's field engineers and we put them together. And they developed a set of algorithms that allow them to take that preliminary design that was given to them in AutoCAD and translate it into a Revit model, translate it into BIM.

CI provided the manufacturing standards, the institutional knowledge, and KLH provided the software engineering. And what that allowed us to do, by getting into Revit, is allowed us to get into a more robust data strategy. Now, we had the opportunity to use the information within the model to make associations between, OK, I see this on the floor plan. That's going to align with this assembly.

OK, I see this happening on the design and how these are all laid out. OK, well, I've got these options. I can quickly optimize, I can quickly validate, quickly iterate using the information within the model as opposed to a field engineer reviewing it using their institutional knowledge.

There's a way of taking some of that institutional knowledge and putting that within a data-driven workflow. And that would allow the team to get to a bill of material that they could export from Revit and eventually put through their manufacturing process, which was already developed, pretty matured through on the Construction Innovation side.

And so these experiences were crucial, not just for advancing solar work, but for testing out new workflows that we eventually carried into building construction. And again, like I said, there are fewer variables in the solar field. But it was a nice testbed that allowed us to say, OK, well, this works here. And how do we pull this off now including plumbing and mechanical and working with the structural and architect, things like that. It was key for building some of those early experiences and getting some of those early wins.

We started out some of the solar collaboration in 2019, and I think some of those ones there helped influence everyone to say, OK, there's a there. Let's see how-- this is worth pursuing further.

So let's give another example more on the building side, and we'll talk about the mechanical and plumbing on this example. And prior to the project, on the project I'll be showing here, this is a industrial project. And we're using the chilled water system as the example here.

And before the project, the engineers at KLH and the representatives from-- project management from Tweetgarrot, site super from Tweetgarrot, they would collaborate. And they said, OK, here are the materials that we're going to use on this project, that we are going to bid for this project.

Here are the fittings that we have standardized within our shop. Here are the lengths of piping that we use. Hypothetically speaking, we'll standardize on one inch copper and 1 and 1/2 inch copper, not 1 and 1/4 inch copper. So make sure we use one of those two sizes.

So we had all of those types of conversations before the project even started, and that got alignment between KLH before they started the design, and Tweetgarrot on what they could actually produce within their manufacturing facility.

And you're also having conversations at this time of what availability issues are there? And what's tough to get? What has long lead items, which has been really, really challenging over the past couple of years, has been that supply chain. And so we got ahead of all of that.

You can imagine, if you don't have that conversation, if you don't have that collaboration of here's what we're standardized on, that all shows up later. You can either figure it out and prevent it from happening in the very beginning. Or you can wait for the RFIs or substitution requests or submittals that happen down the road of, hey, here's an RFI. I can't get this piece. I can't get this fitting here.

Or hey, here's a redesign that's required because you've designed and laid something out that doesn't match with the standards of my facility, and it's not constructable. And so I've got to redesign this, and I'm going to send it back to you for you stamp it and tell me that's OK.

That's all waste, and those are all sawtooths on that screen that I showed earlier in the presentation. That's the stuff that normally happens on a project that we wanted to get rid of. So we aligned on that before the project started. And more importantly, once we aligned on it, we embedded that into the engineer's workflow.

And so what we did is we took the prefabrication libraries that the team aligned on, that Tweetgarrot provided. We put those on the Demain server. And we allowed KLH to only design from that prefabrication library.

So if there was a chilled waterline that was going in, KLH was pulling in the chilled water standard from Tweetgarrot. And so, if it was coming in at 8-foot lengths or 10-foot lengths or whatever Tweetgarrot had standardized on, that's what was being pulled in. If there was a certain fitting that Tweetgarrot didn't standardize on, it didn't have, that fitting wasn't available for the engineer to even use.

And so it's a step beyond just getting alignment and saying, OK, here's what we're going to follow. It was you're only going to be able to use those parts and pieces that Tweetgarrot has when you're doing the design. And what's nice about having Tweetgarrot developing the standards for design the designers of KLH to start using and using a data-driven workflow to do that is now we could create some links to a costing database into that model.

And so what we could do is start to eliminate manual takeoffs because, if the fittings and the piping and the material and everything that's within that model developed that fabrication library, developed by Tweetgarrot, it's got a live-link to costing, you don't need to go through and highlight and click off and figure out exactly how much is something is in the model. You just pull up the number of what the cost is of material in the model.

And so it also gives you a step towards a constructable model because you're spatially coordinated. You're using parts of pieces that are constructable. And you're getting input from the field and from the shop before the design even starts, so you understand how they prefer to route things. You understand how they want to avoid and how they might want to couple piping and duct work on a multitrade rack. And you get ahead of that before the design even starts.

And so, obviously, of course, this also supports a manufactured deployment. And that allows you to get to this point where you're doing pipe spools or multitrade racking. You also get the benefit from factory inspection and testing and all the different things you get from the manufactured deployment.

And again, you get to push this model data all the way from the design model all the way through the fabrication. So you get a seamless transfer of information of data throughout the entire project. So there's another ways of where you're taking out the different sawtooths of that project.

So between those two case studies, those examples on those projects and really the entire presentation, there's a few takeaways that I hope you garner from today's presentation. One is that data is the common denominator between everybody.

Every workflow should leverage data. Every workflow should produce data. Every software that you use should be able to push and pull data between its database and databases of other software. And if you can get to how does data connecting the common language and converting that, then you'll be able to have seamless workflows.

The second one is informed design with manufacturing and field standards. That's how you prevent rework. That's how you prevent delays from RFIs and substitution requests. That's how you get the institutional knowledge of the shop and the contractors into your design process.

It's absolutely key, if you're combining data with that manufacturing, and you're going to get to a real powerful position.

Finally, engage. The roles and responsibilities as this continues to develop and mature in our industry are going to change over the coming decade. And the ceilings that we once had as individual companies are going to change as we learn how to collaborate and work together in unique ways.

So please, feel free to reach out to myself, but also to the contractors that you're working with or architects and engineers that you're working with to find out what that better way looks like.

And that concludes the presentation. Thank you again for watching. My name is Alex Jonovski with Demain. And I appreciate the time.