Exploring Lean Construction and the Future of Building Design with Iris Tommelein

In this enlightening episode of the Built Environment Matters podcast, host Jaimie Johnston MBE engages with Iris Tommelein, a distinguished Professor of Engineering and Project Management at UC Berkeley. Iris, renowned for her contributions to lean construction and as a founder of the Lean Construction Institute, delves into her journey from civil engineer architect to a pioneer in project production management. She shares insights from her extensive research and teachings, highlighting the intersection of lean principles, project management, and the evolving challenges in the construction sector.

The conversation pivots around lean construction's impact on efficiency, sustainability, and innovation in building design. Iris emphasizes the importance of understanding customer needs, managing project variability, and the benefits of standardization and modularization. She also touches upon her groundbreaking work in site layout planning, the role of AI in construction, and the future of building design.

Listeners will gain a deeper understanding of the complexities and potential solutions in modern construction, including the need for integrated project delivery and the balance between creativity and standardization. Jaimie and Iris's exchange offers a compelling look into the future of the built environment, making this episode a must-listen for industry professionals and enthusiasts alike.

To learn more about Bryden Wood's Design to Value philosophy, visit www.brydenwood.com. You can also follow Bryden Wood on LinkedIn and X.

Transcript

Intro: 0:09

Hello, welcome to Built Environment Matters, a monthly podcast brought to you by Bryden Wood, an international company of technologists, designers, architects, engineers, and analysts working for a better built environment. Bryden Wood believe in Design to Value, to cut carbon, drive efficiency, save time, make beautiful places and build a better future.

Jaimie Johnston: 0:33

Hello and welcome to this edition of Built Environment Matters, the Bryden Wood podcast. My name is Jaimie Johnston. I'm Head of Global Systems here and this time I'm delighted to be joined by Iris Tommelein. Iris is a distinguished Professor of Engineering and Project Management in the Civil and Environmental Engineering Department, and directs the Project Production Systems Laboratory, P2SL, at the University of California, Berkeley, which is where I met her. She's been studying, developing, and applying principles and methods of project based production management, otherwise known as lean construction, which is the topic that I really want to get into. Iris has got a spectacular CV, so I can't talk about all of them, but she's hosted conferences on lean construction, she's published over 250 articles, books and book chapters and has given lots of keynote lectures on this. Incredibly, she graduated as a civil engineer architect in Belgium. She also has an MS in Construction Engineering and Management, an MS in Computer Science Artificial Intelligence, which is obviously a very hot topic, and a PhD in Civil and Environmental Engineering from Stanford. Crucially, and one of the reasons we're very keen to talk to Iris, she was a founder of the Lean Construction Institute. in Berkeley, and in 2015, she was awarded the LCI's Lean Pioneer Award. She's also the recipient of the prestigious 2022 PPI Technical Achievement Award for Thought Leadership in the area of Project Production Management and she was inducted into the National Academy of Construction in 2019. So, phenomenal. CV, worldwide recognised as one of the leaders in this topic. So, firstly, to put some context around it, this idea of lean, if you can sort of explain what it is. So obviously for decades people have been trying to emulate what manufacturing does and obviously people leap to parallels with automotive and things. I think one of the most powerful elements of manufacturing is this lean approach, so perhaps you can explain what it is, what it means, and that will be kind of useful grounding for the rest of the conversation.

Iris Tommelein: 2:26

I wanted to start by thanking you, Jaimie, for inviting me to be on the podcast. It's really an honour to be here. As you mentioned, I've been involved in lean construction for quite some time. I became aware of the concept of lean in the early 1990s, I think when a lot of other people had read The Machine That Changed the World, the book by Womack, Jones and Roos that really was a wake up call for many people in manufacturing and also posed interesting questions for us in construction. I quite like the definition that they have been using for some time, which is that lean is to do what the customer wants in no time and with nothing in stores. It seems kind of a very desirable set of objectives. But the challenge with these three objectives is that they're really in tension with one another, and it's very difficult to do all three. So it was said that Taiichi Ohno from Toyota actually discovered a major insight when he came to the United States in the 1950s, discovered the notion of supermarkets and saw that it was wonderful that customers could get what they want in no time. But he also realised that it came at a huge cost, which is to have all the space that's occupied by supermarkets. And so he took on the challenge basically to try to address these three challenges and understand the trade offs that one has to make in order to really optimise the whole. I see this very much applied to the world of construction. In construction, also we talk about project management. You can have three things, time, cost and scope, take any two. And here too, you know, we live in a complex world. We really need to understand many objectives, some of which will conflict with one another and the challenge that Lean poses is really to learn to make trade offs and to do so through scientific experimentation that Plan-Do-Can-Act cycles and more recently also, of course, using increasing amounts of data that can help inform our decision making. That frames my understanding of lean and I should add whether you call it lean or not, I'm rather agnostic about it. I think the notion of scientific experimentation and continuous improvement is very appealing to me and that's what I've been pursuing in my research.

Jaimie Johnston: 4:38

Yes, one of the things I found really interesting when we first met, so we at Bryden Wood don't use the terminology of lean. We didn't necessarily think of ourselves as lean practitioners, but I think the things we were trying to accomplish, which is, you know, taking out non value adding activity, trying to sort of get things to be more consistent and stable. I found it really interesting, actually, that without using the same language, we were thinking the same way. But, if you can just expand on that, that it's a mindset rather than a particular technology. I think certainly in the UK, people tend to launch onto specific terms. The terminology, or the phraseology, or the technology, but it's not that, is it? It's a mindset of how you think about these things and approach these things.

Iris Tommelein: 5:16

I 100 percent agree. It's a mindset, it's a willingness to question, you know, what the current state is and it's a willingness and an ability to envision what a better future state might be. And then it provides, you know, tools and methods and technologies to get us from the current state to a better state.

Jaimie Johnston: 5:35

Yeah, obviously you're a leading academic in this space, but from my understanding, your starting point was very practical. It was looking at site layouts and how people arrange sites. Is that true? And sort of looking at how you organise a site, because obviously people design the building, they design the end state, they don't necessarily put as much effort into the temporary states. And so, ad hoc things happen on site and that's one of the blockers. Is that where you started looking at some of the practical implications?

Iris Tommelein: 5:58

It is indeed. My advisor, Ray Levitt at Stanford, you know, suggested that I look at site layout and I date myself a little bit, this was in the mid 1980s that I started on that research. He suggested that I look at site layout, and I think a reason why he identified it is because it was a problem that had yet not been tackled, and mathematically speaking, it's also a very difficult problem. It's figuring out how much space you need and where the space goes, so it's a layout problem, but there's a dynamic aspect to it because things change on site the whole time, and that makes it very difficult to address. But what he recognised is that this problem had not really been addressed, in fact, by academics, and that we kind of deferred to the world of practice to deal with the problem in the best way they could. And that made it an interesting topic, of course, to study.

Jaimie Johnston: 6:46

Yeah, I mean, it's not dealt with academically, it's probably not even dealt with by professionals, I suspect, when you were looking at it, it was very much, as you say, it was the site practitioners, it was people dumping materials where they could possibly find space and things, and I think that's such a rich area, they go, you've designed the building, but if you haven't enabled the conditions on site that will allow you to do your best work, and see, that's a huge problem that people are running around trying to find materials, information, resources, and things, so looking at that, I mean, obviously now people do 4D planning, they probably think some more, but I guess that was a completely new frontier, was it, when you started looking at this?

Iris Tommelein: 7:19

It was very new, right? So we barely had computers. The first desktop computers came about in 1984. I remember the excitement of having a Macintosh computer and being able to walk around with it on campus. So computers, of course, were very limited in their capabilities compared to the capabilities that we have today, which are absolutely fabulous so the ability to collect data and to actually know on a much broader scale, what is going on where and who is involved. That has really opened up tremendous opportunities for us to rethink how we do our practices. At the time the world was very small in a way and very fragmented, very local. So when I started to look at layout problems, I soon realised that the challenge of layout doesn't exist in and of its own that really It's a confluence of two things. One is to have construction schedules where you specify what the demand is for your product and then the other part is to have supply chain schedules that can deliver what the construction site needs and what I realised at the time is that site layout is kind of the buffer in the middle that side, that tries to attenuate two sources of variability. One is in our construction schedules, it's very hard to be reliable in execution. There's a lot of variability for many reasons. And likewise in the supply system, there was a lot of variability again for many different reasons. And so if you are this hinge point, the site, where everything needs to come together. Given the situation we were in, we needed to have huge buffers we needed to really shield ourselves from all that variability if we wanted to have any form of reliable execution, and that was very difficult to achieve.

Jaimie Johnston: 8:59

Yeah, and that's also what we've often found, that you try and fix one problem and realise that's not the problem, it's the consequence of another problem, and then the picture gets broader and you start opening up the problem going, 'Oh, actually, we're tackling the wrong things,' so you then started moving into the materials management, supply chain management. If you can elaborate on that point about variability, it's one of the, I think, dawning recognitions. Well, it's probably been known for a long time, but I think people are really grappling with this lack of standardisation, lack of repeatability, the fact that everything is a prototype makes it almost impossible to apply some of this thinking and some of these techniques. Is that a fair comment?

Iris Tommelein: 9:34

Yes, yes, no, I 100 percent agree. Everything is a prototype and it's wonderful to prototype, right? It's wonderful to apply human ingenuity to invent new things. So, I certainly am in favour of prototyping. The challenge is of course that inventing new things, better things is only one of these many objectives that we need to achieve. And there are other objectives in terms of you know, doing what the customer wants, for example, with you know, growing world population we need to have, more housing for people. We need to have the finances to be able to build these houses. We need to have the space. We want the houses to be sustainable. There's many different objectives to be achieved. So, you know, variability crops up in many places and entropy will increase if you don't pay attention to what's happening around you. And it's all too easy to introduce new things and then complain about the fact that our world is too complex. One of the expressions I try to convey to my students, and I think it's a quite pertinent characterisation of the state of the world is that everybody today is complaining about how complex our world is, but that complexity of course is. the consequence of a lot of the variability that we introduce ourselves. So I call it self inflicted complexity. And that I think in and by itself is a useful term because once we realise it's self inflicted, it gives us a way to perhaps begin to think about how to control it. And this is where the world of variability, of course can be harnessed through standardisation, interchangeable parts, modularisation, and all these wonderful things that Bryden Wood and and others have been doing such pioneering work on.

Jaimie Johnston: 11:11

Yeah, we've obviously been looking at this for a long time now and trying to simplify construction. There's a real debate in the UK at the moment about the potential benefits of standardisation and what it would unlock versus the the way our business models work, like every engineer wants to add value by being creative and doing an interesting thing. We've always had this sort of thing of, you know, is that level of bespokeness properly adding value? And I think it's quite right, you're talking about what's the value to the customer. Is the level of variability between, you know, different schools, different healthcare wards and those things actually sufficiently adding value? And I think there's a real fear that standardisation will result in lack of good quality design, lack of decent architecture. I actually think it's the other way around. We would say that standardisation allows you to put tons more effort into the design of a thing. If you're going to repeat it, you'll spend loads and loads of time optimising the design, then you repeat it and you magnify the scale, the benefit, but that's a real conversation we haven't had or resolved yet in the UK, but everything feels like it's telling us exactly what you're saying. Simplify the design, get into repeatability, get into commonality, leverage, you know, improvements in processes, how you start to unlock things.

Iris Tommelein: 12:22

And this gets back to changing people's mindsets, right? It's really all in the mind, right? Do people really appreciate how much value there is for them with having every building being a bespoke building? Or, can they appreciate that through standardisation, you may actually have opportunities to be more creative? I think the apparel industry is a beautiful example where obviously clothing sizes have been highly standardised and so it makes it very easy for us to go to an online store and pick whatever item we want and know exactly that what we buy is going to fit, you know, plus or minus, right, a little bit of variation, but it gives us a huge opportunity for people to design and be creative in the production of apparel and reach the customers and satisfy the customers wants and wishes in many different ways. So it's kind of this notion, I guess, that, you know, mass customisation can really help us with, standardisation being an important part of that.

Jaimie Johnston: 13:16

Yeah, we haven't reached mass customisation. There's obviously mass personalisation, you can order yourself a very specific sneaker that you designed yourself because it uses a completely standard process, so yeah, it feels like it's like an hourglass. That's the standardisation pinch point to unlock all these other things, which will get us back to mass customisation and mass personalisation. But yeah, it feels like we're on the precipice of something, but everyone's slightly afraid to make the jump in. I think the other thing that I was interested in your work, it's certainly something we saw in the work on the Forge. So for instance, we designed the superstructure to enable the following packages to be more productive. And that's quite alien because normal trades are doing the thing that they do well to leave site. They're not normally trying to benefit the people downstream. But again, we didn't use that terminology, but I think you talk quite a lot around this sort of holistic idea and understanding your place in the system. So perhaps you can explain some of those things about the holistic nature of this thinking rather than individual trades and tasks.

Iris Tommelein: 14:12

Yeah, as you said, if everybody working in a sequential order for that matter optimises the system from their own perspective, then obviously you can't go very far because what's got optimised up front very much constrains what the next person can do and so they can't really deliver the best that they might see in the project delivery system. So, I've been a very strong advocate of what's called set based design and Integrated Project Delivery, trying to bring together different people to share ideas and to explore search pages together so that they can find these overlaps how systems can go together, because everybody looks at the world with their own optimisation function, and it's clear that not everybody can have the optimal solution. The parts won't go together if everybody has the optimal solution. So some collaboration and integration is absolutely necessary. And what we find then of course is that the early work really needs to enable, as you mentioned, needs to enable what's going to come next. And there's opportunities of course to do some major restructuring on how work is done because some information needs to be available early because of the way our current supply chains are working and other information can be postponed until later points in time. The options that we have in terms of designing things may be very rich and broad, but then in terms of fabricating things we may find that there are many fewer solutions and so understanding the world around the project delivery system is really important because it's these supply chains that will ultimately feed the project. And so the broader you can reach in bringing people together and developing shared understanding, whether it's through direct conversation or through standard interfaces and agreed connection points whatever you can do in that regard, you have, of course, an opportunity to better optimise the whole.

Jaimie Johnston: 16:05

Yes, you touched on Integrated Project Delivery. Are there ways of procuring things that you think are best aligned with the work you've been doing? I think one of the blockers here is that the forms of contract and way we procure things kind of gets in the way it forces certain behaviours even before the project started. And I think it's one of the things that I'm really interested about is that, as we talked about earlier, the solutions to these things aren't technical now. It's the surrounding ecosystem. So have you got thoughts on procurement or ways of organising projects that facilitate a lot of the outputs that would be, I think, fascinating because it's a, it's a topic we need to get into next, I think.

Iris Tommelein: 16:40

Yeah, so, a little bit of history. I've been very fortunate to work here in the Bay Area because we have many forward looking designers and builders and owners who really want to, you know, develop the next generation of sophisticated buildings. I mean, we're close to Silicon Valley, there's a lot of biotech facilities, obviously. The owners of these facilities have very high demands on, on what the facilities need to deliver and so they're pushing the industry forward and the industry also has been very creative in addressing needs so that we can move on and advance from a cleanroom at very dusty situations to a type one cleanroom or even better. P2SL my research lab, the Project Production Systems Lab was founded in 2005, Glenn Ballard and I were at the time fortunate to work with healthcare providers, specifically Sutter Health that wanted to become the owner of choice to upgrade their facilities to meet more stringent California building requirements and at the time the state of California had developed a new permitting agency called the Office of Statewide Health Planning and Development and the mandate of OSHPD was to make sure that every new facility, specifically every acute care facility, would remain not only standing after a major earthquake, but would remain fully operational. It left the whole industry up in arms as to how do we do that. And OSHPD itself had challenges in reviewing design drawings and specifications to determine whether the new designs would indeed be up to par. The consequence of these permitting requirements was that OSHPD became a major bottleneck in the system. It took them a long time to review the thousands of drawings that were given to them for any one project and the response of the industry at the time was that if OSHPD takes so long, let's try to submit our drawings sooner so that hopefully we will get our permit sooner. But what happened in that process is that as people were submitting drawings sooner the drawings were increasingly incomplete, and so OSHPD took more time to review, and OSHPD sent the drawings back a couple of times for redoing and updating and resubmitting, and so the industry was really in this downward spiral of permitting. So we invited OSHPD and the larger players in our industry to come develop a value stream map to map out what it would take to deliver a 100 bed hospital, and not just to produce the drawings for construction of the 100 bed hospital, but actually to look at the real customer, which was OSHPD, to develop drawings and specifications that OSHPD would easily be able to review and approve and that really brought our industry together to think about the bigger problems of how do we really work together in a more integrated fashion? We were also very fortunate at the time Sutter Health had a brilliant legal counsel, Will Lichtig, who I think you interviewed who also took on the challenge of questioning the contracts that we were using at the time, and he realised that the contracts in place were not really suitable for this Integrated Project Delivery and Will developed his own integrated form of agreement contract to bring people together in a shared risk and reward situation. And that really propelled the thinking around target value delivery in our industry and really spurred a lot of people to think more about relational contracting and the project delivery process in contrast to very competitive design bid build type projects where there's really very little incentive for people to collaborate.

Jaimie Johnston: 20:22

So that, I didn't know that actually, that's a phenomenal story. If you swapped out some of the names for, GlaxoSmithKline or Circle Health. I would say we went through a very similar journey with some of our big customers. It was always the customers that, are trying to get the outcome of the built asset. You know, the building is a purpose to do it, to achieve some, some other big outcome. Yeah, we've always had that, that interaction actually, it's customers coming and saying, look, what can we do? How do we join, the thing rather than contract and throw the risk over the wall and things. So, yeah, that's a phenomenal, I think, validation is something we've probably learned a few times, but we've kept saying to people that no party can do this unilaterally, so.

Iris Tommelein: 20:56

Exactly.

Jaimie Johnston: 20:57

That's very interesting. I think your colleague Todd Zabel le we found a quote when we were doing our prep for this.'Buildings leak in the intersection of trade contracts.' And I don't know whether he meant like leak air, physically leak, because it's all the interfaces or whether he meant leak value because it's I mean our experience has always been it's the interfaces between the different bits that cause all the trouble that's why this standardisation of tasks and components and things, repeatability helps all of those things.

Iris Tommelein: 21:24

Yes. And he also, I mean, in addition to what you mentioned, all these interpretations of leaks, I mean, he really wanted to tackle this notion of, you know, if you have a project and you break it down in pieces and you manage every piece individually if every piece individually gets performed optimally, will you have performed your project optimally? And the answer is, you know, probably not because the pieces are not independent of one another, there's a lot of interfaces, right? There's a lot of interconnectedness. And so again, if you optimise at the local level, you may not optimise at a global level. So yeah, buildings leak physically, Todd had a roofing contracting company. So leaks were very much on his mind at the time when, when he was developing his first Building Information Models in the 1990s. But then of course, in terms of contracts, there's always issues with scope overlap and scope gap and, who, you know, addresses which part of the scope. And again, this gets us back to Integrated Project Delivery. You need to be able to have conversations around who is going to do what and who's in the best position, right, to perform a certain task. And it's not like everybody has to perform the same tasks. And it's not because we've always done it one way that necessarily we have to keep doing it the same way. So these discussions, we talk about work structuring, these discussions need to be had in every project. How are we with the team, you know, knowing who is on board, who has what capabilities and what context we're in, how are we going to do the work together?

Jaimie Johnston: 22:49

Yeah, one of the phrases that you use, work density, I absolutely love that phrase. So we used to have a mental construct. We said, imagine you're looking at the assets, and you've got a pair of thermographic goggles, but instead they're looking at, we would call cost densities. You're looking at the bits of all the trades, all the interfaces. We imagine looking around the building going, that bit is blazing white hot, that's the bit where we should pre fabricate. So we weren't using it in quite the same way, but perhaps you can explain what you mean by work density, because it's a great concept, and it very much aligns with some of the things that we've thought about over here.

Iris Tommelein: 23:22

So, work density came about as we started to do research on takt planning. And again, this was on a Sutter Health project where, you know, speed was really absolutely crucial. And the question was, how can you gain speed on a project? And it was obvious, and we're going back to 2011, 2012 in the community of lean practitioners, we were gradually improving, practicing different lean methods, but takt planning was quite new at the time. And the question is, how do you do this on a project? and the notion in takt planning, of course, is that you need to have a very reliable beat for every step in a process to be performed. And so we're trying to replicate that with process steps on a construction project. And we were trying to find, you know, what is the beat for the process so that everybody can be sure that they will be able to do their work within that beat. So, it's a line balancing problem as it's called in manufacturing. It's not a new problem. What's different for construction, of course, is that we don't have linear assembly lines. We necessarily are working in two dimensional space, if not in three dimensional space, for the work that we do. So we had to think of a slightly different concept. But the notion is really that you want to give every trade the proper amount of time to do their work in a given area. And some trades need to spend a lot of time, for example, in the electrical closet, the electrician will spend a lot of time there. But of course, the mechanical contractor probably does not have anything there because all the electrical gear is there. So I wanted to capture somehow how much time the trades would spend per area. And of course, that depends on many different things. It depends on the types of materials that need to be installed. It depends on the scales of the trade, the tools that they have, the methods that we have. But importantly, it also depends on whether, for example, you decide to prefabricate or not. If you're going to stick build something, you're going to spend a lot of time in a certain area. if you can prefabricate, then obviously you will spend much less time in that area. So that's where the notion of work density came from. It's first of all to try to characterise for the trades how much time they would need based on, you know, all the assumptions about work structuring that I've just mentioned, means and methods, crew sizes, and so on. And then with that understanding, then try to define how much space they would need and define the zones of work that would suit everybody so that we could actually balance how the work is being done. And indeed, one of the nice things about work density is it's a generic metric, right? It's amount of time per space. So we can talk about any trade, we can talk about any scope of work, and it gives us the opportunity to talk about speed in regards to investments we can make. In doing the work in a different way, whether it's with robots on a construction site, for example, or whether it's doing it in an off site location. We can at least begin to explore these options and see if they're beneficial for the takt, for the speed at which we try to deliver the project.

Jaimie Johnston: 26:25

Yeah, that aligns with some of the stuff we tried on The Forge where, yeah, we were talking about factory conditions on site and saying actually off site is not necessarily the best place for the activity if you can conduct it in very productive conditions on site. Maybe that's more beneficial. One of the most interesting and maybe counterintuitive findings that came out of the Cambridge study was whereas on the actual project, they poured the slab in two pours or four pours. The Cambridge team said actually you should have a smaller pour, you should have more smaller pours to get the takt time and that was really counterintuitive to me. They were saying smaller batches sometimes make you go faster, which is contrary to the traditional thinking of going just do the biggest lump of stuff I can and drop it in. Perhaps you can elaborate on that because I know that's something you touch on the batch size and working the takt time around the common drum beat rather than necessarily the size of things that was quite an eye opener for us.

Iris Tommelein: 27:16

Yeah, so the notion in takt planning in construction is that, of course, you can zone the workspace and you can treat it as a single space, in which case, then if you're going to give every trade access to the space by themselves, so they can work in optimal conditions, that's a big premise. Right, that's the goal of takt planning is you try to give the space to one trade so they can work unobstructedly by other trades and work in the best way possible. So if you have a very large space, then obviously, when work needs to be done sequentially, it's going to take a long time. So what we do in takt planning, we try to create concurrency, we try to create multiple assembly lines, and we do that by dividing this maze in smaller pieces. And in theory, the more pieces, the faster you can go. In practice, again, There's a limit to that, of course. If the pieces get too small, they become impractical for the trades to be productive. You know, if you need a scissor lift, you need space to move around a scissor lift.. If you give not enough space, the scissor lift is going to become meaningless and then the work densities also vary. So certain things you cannot make smaller, right? So back to this electrical closet, you cannot divide the electrical closet in half. It wouldn't make sense to do that. So there, there are practical limits, but theoretically, the more, you know, the more concurrency you can create, the faster you can go. So, what's interesting where we still have a lot of research questions as far as that goes is how is work done and how much space do people need and what are the right means and methods to use in certain contexts? And how can we ensure that there will be predictability in the completion time? So one of the challenges I still see in our industry gets us back to variability, is that we don't have a good understanding of what in manufacturing is called process capability. So if you look at assembly lines in Toyota or elsewhere, every step in an operation is very tightly timed, and they know exactly, what one person or what one machine can do. And any person, any machine can do for that given step. In construction, we still have a lot of variability in that regard. And so it makes it a little bit more difficult to come up with the right times to balance our production systems.

Jaimie Johnston: 29:28

Yeah. So when we first met and I was explaining the work we were doing on platforms, again, it was a sort of massive validation that a lot of the things we were doing around common components and the idea that you could take lessons learned from the Forge and you could reapply those lessons to the next iteration. We had our own interpretation of why that was a good idea, but actually, talking to you, the more we hear about it, the more we go, yeah, we're definitely on the right path. This has to be the best opportunity we've got to get that stability, to get that repeatability, to properly make the big shift into a manufacturing mindset. So, it's another one of these areas where there's such alignment. It's sort of fantastic that someone on the other side of the world has landed on some of the same potential solutions as we've been developing over here. So, we love it when that happens.

Iris Tommelein: 30:08

Well, and you've really moved very fast forward in getting all the systems integrated, because I think there's a number of players who in, and by themselves, have tried to standardise, but I think the huge challenges have been to get everybody on board, right?

Jaimie Johnston: 30:26

Not sure they're all on board yet, but it's a work in progress. Like you, yeah, we've still got lots to cover. It would be remiss of me if I didn't ask a question about AI, given it's such a hot topic. So you started looking at AI in 1985, is that? Is that true?

Iris Tommelein: 30:41

Yes, it dates me again, right? It's kind of inevitable.

Jaimie Johnston: 30:45

You must have been in a world of prediction at that point. It'd be just interesting to get your take on how things have progressed, what you think the current state is. We've talked on this podcast before about everyone's got tons of data, but is it in a fit state for teaching AI? How close do you think we are to really deploying some of these buzzwords in construction?

Iris Tommelein: 31:04

So, regarding AI, there is this famous proverb, right, that says 'be careful what you wish for because it may come true.' In the 1980s, we were working on expert systems and we were, you know, doing list programming, very specialised computer based systems. We were trying to extract all the rules from experts to try to capture them in computer systems. And some of that worked and some of them worked quite well. But it was really hard to maintain these systems, and they became rather unwieldy, and our computers were not as fast as they are today and so it was only wishful thinking as to where we thought things could go. So, you know, leaping 30 years forward, it's it's very exciting Now that we're past this kind of winter of AI, there was a winter of AI in the late 1980s, early 1990s, where people realised that, we needed to begin to think about using computers and artificial intelligence in somewhat different ways because the rule based systems really weren't fit for purpose on the scale that we needed them to work. So yeah, so here we are with a very smart computer systems that can do machine learning and tons of data. Indeed, as you already mentioned, structuring data in a way that we can make sense of it is a big issue. And again, it's going to take a lot of discipline, I think, up front as is the case in project delivery in general, I think we need to invest more resources up front in order to reap the benefits later. For example, if we set up cost estimating systems with a nomenclature for different types of activity description, we want to make sure that our estimates are going to be tied to what happens on site. So it's not just about the estimators understanding the nomenclature and the categorisations, but also the field people who do the actual project implementation and controls need to, of course, work off the same set of labels, and that's going to take an enormous amount of time, I think, still, to get all the people on board to do that, unless we have more machines, more 360 cameras that can extract what actually happens on site and do some of the labelling ourselves. I expect really very rapid growth and many successes in the very, very near future. I can't wait. Next year we'll be in a very different place. Two years from now, it's going to be radically different from what we're doing today.

Jaimie Johnston: 33:17

I presume all of this would be, again, accelerated by more stability, less variation. You know, you get a better data set. You'd have a closer link between the models, the activities, and all these things if you were doing very repeatable things. I guess, again, everything's telling us that the same thing about simplifying, getting standardised components, repeatable processes.

Iris Tommelein: 33:36

Exactly, exactly. And then the other part, besides the repeatable processes and reconciling, you know, the other side, of course, is are there different ways to look at the world? You know, are there different conceptualisations that we need to describe construction, to do our project controls maybe to further restructure how we do the work together with more machines and there too, it's hard to predict what the future will bring, but I think there'll be major changes in work methods and in materials, sizes of materials, delivery systems that will change our industry very radically, very soon.

Jaimie Johnston: 34:13

But again, they'll need quite a big cultural change, won't they? All of these things seem to be linked, that the technology and the culture always seem to go hand in hand, that they go, yes, there's loads of technology we could deploy, but we will have to think differently in terms of how we design and procure and deliver and assemble these assets.

Iris Tommelein: 34:27

That's it.

Jaimie Johnston: 34:29

Fantastic. We'll wrap it up there. I could have asked lots more questions, but hopefully I'll see you again over in the Bay Area soon. Iris, thank you ever so much for joining us. It's been a really interesting conversation. I hope all the listeners have enjoyed it as much as I have.

Iris Tommelein: 34:40

Thank you very much. I really appreciate the opportunity and I very much enjoyed it as well, Jaimie. We'll be in touch.

Jaimie Johnston: 34:46

So thank you ever so much for listening. And please join us on the next edition of Built Environment Matters.

Intro: 34:52

Thank you for listening to Built Environment Matters, a podcast brought to you by Bryden Wood. Listen and subscribe wherever you get your favourite podcast, and you can follow Bryden Wood on LinkedIn and Twitter.