Colab21 NZ - Blox Keynote

Good morning, New Zealand. Welcome to CoLab 21. I'm really excited to be virtually with you. I wish I could be there in person, but Scott wouldn't let me. For context, my name is Chris Giattina. I'm an architect, a manufacturer, and a builder. I run a company that I founded called BLOX, and we design, manufacture, and construct complex healthcare for some of the nation's largest healthcare providers. We have a team of about 600 people: architects, engineers, logisticians, computer programmers, manufacturing experts, and a host of other people who together work under one roof to create a condition where we can change an industry.

Our talk today is about platforms, programs, and projects, rethinking facility delivery with a product mindset. I'm going to explain what that means.

So let's start with the current state.

The current state is a project mindset. It starts with an owner who has a need, and that need may be a building. The building then creates a project. The project then says, we need an architect, an engineer, and a contractor. If the team is really working well together, they will come up with ideas that may be ad hoc prefabrication, and they will start thinking about ways that work, which is really good. This is a positive way that works on a project. If the owner has another project, they start the same process again. There's another group of architects, engineers, and contractors, and there's some more ad hoc prefabrication. This pattern repeats itself in a project mindset each time. What you get out of that is what I call the groundhog effect, where there is very little transference of intellectual capital from one project to another project. There is an unleveraged scale involved in this, which means that our overhead scales linearly instead of incrementally. Ultimately, there is very little speed to market in a project mindset.

The project mindset is the current state of our industry. What we're trying to get to is the future state, one of a product mindset. This is an LG washing machine. It is a product made in South Korea by the tens of thousands. A thimble full of detergent and a thimble full of water will sanitize my three teenage boys' clothes. It's an impressive machine. It needs four things to work: water, power, a place to discharge, and a space for it to fit. If it has all of those four things, it is an incredible tool. In the absence of any one of those four things, it's a worthless boat anchor. What we learn about a product mindset is it requires an ecosystem in order to exist. That ecosystem is what makes it useful.

The architecture, engineering, and construction world has an ecosystem that is built for a project mindset. For that first slide I showed you of Project One, Project Two, Project Three, and Project Four, we knew that we couldn't get to a product mindset in an ecosystem that is designed for projects. So we changed it. This change was towards transforming nouns into verbs, into actions: design to manufacture to construct. These things are thought of in this ecosystem as a singularity where design, manufacture, and construct are a single action, not a series of paralleled siloed actions. This is really important.

What we want in this ecosystem is to teach a legion of designers to leverage manufacturing productivity so that we can simplify construction. If we can do that, we can begin to change an industry for the better. We'll know it when it achieves this objective: two by two by two, twice as good. We want demonstrative quality improvements. Everything that comes out of the shop needs to feel, touch, and act twice as good as the stick-built version of it. The second goal is it has to be delivered from an end-to-end perspective, from the beginning of design to the certificate of occupancy of the building, twice as fast. Finally, it has to be delivered in such a way that it provides value to the owner, creating twice the value. This two by two by two is not an incremental change; it's a geometric change. It is two times two times two, which is an eightfold improvement. We're not looking for an 8% improvement; we're looking for an 800% improvement.

The industry focuses on a paradigm, which takes an idea and moves it to a design, which moves it to a model (building information model), which then goes to construction documents, which are given to a general contractor, which are given to subcontractors and pieces, which are then required for a series of submittals, which go back to the general contractor, which go back to the architect, which go back to the general contractor, and to the subcontractor, whether approved or rejected, which ultimately get fabricated, installed, and then punched. Somewhere way down here, the owner gets to use this piece, right? This is our paradigm, and almost all of the construction tech you'll hear about is shortening the gaps between these steps. If I can reduce the idea to design, if I can use technology to reduce design to model, or increase the speed with which an RFI or an ASI can be returned, then I can begin to improve that, but it won't get me an eightfold improvement. So we had to look for a fundamentally different way to get to two by two by two. It wasn't within this original path of the AEC industry. We said we'll go from a model to fabrication, and instead of shortening the gap between these two, we'll simply eradicate it. We'll eliminate it. Now, parenthetically, you could imagine that we probably ruffled a few feathers with that, but this is what we have to do. We have to go from model to fabrication. When we do that, we change the game.

To make all of this work, it requires a platform. The title of the talk is platforms, programs, and projects. It starts with an ecosystem or a platform. That platform takes the building information model and coordinates raw material, which is then digitally processed into specific parts, which are then put together by operators, not necessarily by skilled tradesmen, into sub-assemblies, which are installed by operators into two-dimensional panels, which can be aggregated into three-dimensional modules, which can be further nested into large Uber modules, which can then turn into buildings. This is our platform, and it is the way BLOX is beginning to undertake changing an industry.

It is important not to think about this as a linear process from A to B or one to seven. This is sometimes the situation: the exigencies on the site mean that raw materials need to go straight to sub-assemblies because we have a brilliant supplier, or maybe we have a part that can go straight to the job site. There are hundreds of other exigencies that will require different pathways to find an optimal path from a raw material being converted to a building. That's our objective.

Underneath that platform is technology. That technology we have is called Weaver, and it's about tying disparate things into a whole. Weaver is raw materials organized digitally with a series of constraints, size, shape, location, capacity, skills, etc., organized in such a way that they reside on the cloud and can be produced into a digital catalog, which an owner or user can select from. At the same time, there are real-world manufacturers that can use this data to make parts. These parts then are delivered not just as digital formats but as physical effects. This is an important component of what it takes to change a platform. If you peel back and look at what that platform is underneath, it looks like a series of roots. It starts with raw material, standard parts, and non-standard sub-assemblies that can be aggregated into groups. All of these components work as part of the platform to produce bespoke or relatively bespoke derivative products. Specifically, that platform is a container which holds the Design Manufacture Construct (DMC) operating system. That operating system has analog components and digital components, essentially rules. These things are constantly being developed but have a concreteness right now. It organizes the components and the application. If we use the analogy of the Apple phone as a platform, then the Waze app is an application. Ultimately, there are services that take the platform and extend it beyond just design, manufacture, and construction, to the service life of the building.

These pieces go together and organize external events like the supply chain. They create kits of parts, which may be made by BLOX but also by other manufacturers. They create standard modules and all the DNA associated with that. They create configuration tools that make new modules and building program pieces. This platform exists a priori before a project starts. Once a project starts, it pulls out of this. Step one is there's a Project One, and then step two, multiple projects come out of that. These projects are really products, which then allow us to scale this thing incrementally and then geometrically. This is the way the DMC platform works. It creates a condition where our gains accumulate. Our products are pulled out of the platform where we leverage scale, allowing us to aggregate demand and create a responsive supply chain. It allows us to scale our overhead incrementally instead of linearly. It allows us to develop robust standards, both digital and analog, and expand this across a wide group of people. It enhances speed, which in many cases, provided the quality is there, adds value to the owner, creating more than the sum of the parts.

The path to 20 clinics in 12 months is the way we're going to talk about this journey. I think it's worth noting that this was during a pandemic, but who cares? So we start with this notion of complexity and utility where complexity is measured on the vertical axis and utility is measured on the horizontal axis. What we're looking for is ideally low complexity, simplicity, and high utility. There's a curve that says if you start at zero, zero, and move up, to get more utility, you add complexity. Every year, the AEC industry starts right down here at zero, zero. One brave soul decides to move from this place we've been at for a couple of thousand years and tries to move up the complexity curve and add some more utility. They move up, get scared, and then rush back down to that safe spot of low utility and low complexity.

We've taken a different approach. We asked, what if the curve didn't go exponentially up but looked like a sine curve with a hump where all the dead bodies hang out? What if we could take a path that starts with version one, something simple with undeniable utility, then move to a place with a lot of utility but also a bunch of complexity? We'll show you that path and then have a cathartic moment, an epiphany, and realize that you could get to this far side of complexity. The future is version four, which just keeps going. Version one was several years of work. Version two was several more years of work. Version three was what you saw over the last 12-14 months. Version four is just a hint about where we're going.

Let's start with standard modules 1.0. We have some really great institutional clients, some of the largest healthcare companies in the world. They came to us with a stack of drawings, threw them on the table, and said, tell me how you're going to standardize this. They had a whole array of building types: new hospitals, old hospitals, vertical expansions, horizontal expansions, new clinics, old clinics. They said, we have robust design standards that come at a department level, but we have this amount of variation that is inescapable. We looked at all of this and studied it intently. Despite their design standards, they didn't have intelligence standards that could be converted into action. The action resulted in an array of variations. For example, pretend this is an emergency department, and these are exam rooms. There were hundreds of exam room types or patient room types, even though their standards allowed for only four or five. We found a way to compress those pieces into a series of standard modules, known intelligent standards, that could be produced in such a way that they could still achieve the end game.

The first step was to eliminate unnecessary variation. Once the unnecessary variation was eliminated, we were able to standardize. By standardizing, we could create robust, intelligent parts out of these pieces, much like the automotive industry. Once we could create standard parts, we could begin to create interchangeable parts that could work for a client from Miami to Maine, from Georgia to California. This was really exciting. We did three things: we looked and understood how to remove unnecessary variation while keeping the necessary variation, standardized the parts, and turned the standardization into common denominator parts that would work across many regulatory zones. This allowed us to order in bulk for things we didn't yet know the destination for, leveling our production lines and supply chain, significantly changing our approach.

If we look at the cost graph of stick-built construction, stick-built was the baseline. Initially, at low volume, stick-built was the same as at high volume. Unfortunately, we were more expensive at low volume, but as we added volume, we significantly dropped our costs and reduced our prices. This area was reduced by almost 30% in 24 months—a pretty big move.

That takes us to the freestanding emergency department, the second step on this complexity curve. This one still tightens my spine every time I look at it because it has so much complexity. We started knowing that if we were to reach the next level, we had to develop substantially larger parts and modularize more of the building. We used the Boeing chunking approach, which involves building advanced planes using 22 big chunks from 10 or 12 countries, assembling them in one place. Our module is called an Uber module, not because we like ride-sharing, but because it's the largest thing that can move on a Department of Transportation right-of-way in the North American road systems. It is four meters wide, four meters tall, and up to 20 meters long, packed with complexity. While the size of the Uber frame can vary, all connections are standardized. Digital fabrication allows us to create it in any shape, enabling the creation of various modules like central plans, CT modules, x-ray labs, and more, which add up over time in our digital catalog.

All these components reside a priori before a project starts as well-defined parts. This is a building information model of a freestanding emergency department, an acute care hospital with complex life systems. It is heavily modeled, containing numerous components broken down into parts. For instance, an MEP multi-trade rack breaks down into sub-parts and a bill of materials, further down to specific components like elbows. Our in-house software allows rapid development of bills of materials, coordination, and distribution of these parts, turning them into G-code for bespoke manufacturing.

This is one of our first iterations of the Uber module line, systematically adding pieces as sub-assemblies are fed from the side. This piece is being installed at a job site, connecting a large span space of 60 feet. Pausing to observe, you can see the level of complexity and utility: a slab and a knee wall in the morning, transforming into a highly complex building system by lunch.

The next step was our clinic program, where an international client wanted to build 500 clinics in five years, starting during the pandemic. Their objective was to create accessible and affordable healthcare for Americans, a mission close to our team's heart. We embraced the challenge, developing a system to build 100 clinics per year, eventually aiming for two per week. While we're not there yet, we're on the path. We had to move from high complexity to increasing utility by decentralizing the delivery of building systems, treating each module as a separate piece connected with one port. This simplified field installation, despite increasing manufacturing complexity. The results are promising, with a significant reduction in construction time and cost, hitting 66% improvement in duration from baseline and 33% cost reduction.

We aim to produce one clinic every two and a half weeks, an impressive feat. The clinics are being produced in three states over 12 months, showcasing the scalability of our approach.

The final step in our journey is acute care facilities with patient beds. We've been developing a universal patient room for several years, able to handle various patient types. This standard module can be used and deployed in multiple departments, organized into Uber modules for efficient assembly. The structure allows easy connection of MEP systems, creating a streamlined installation process.

These patient rooms are currently being deployed in four states, demonstrating the effectiveness of our standard patient room module. In a short period, we've moved from a slab on grade to a highly complex and functional patient room. This level of rapid deployment highlights the importance of a product mindset and a robust platform to normalize deal flow and supply chain processes, enabling continuous improvement and scalability.

Thank you for your time, New Zealand. I'm available for questions.

‍