Folks have tried over and over again to make construction more efficient by applying lessons from manufacturing. Typically this means producing buildings in factories, instead of on-site by hand. And while it’s possible to build a building, and a profitable business, using factory methods, it hasn’t resulted in a quantum leap in construction efficiency - it often yields no cost improvement at all. My takeaway from this is that if we hope to achieve the kind of productivity improvements in construction that manufacturing has seen, we need to go beyond surface-level understanding (“factories make things cheaper, so we’ll build buildings in factories”), and drill down to the exact mechanisms at work in an improving manufacturing process.
I work at a GC that has bought in fully to Lean Construction and while it has some benefits and good practices, I think it's gain on efficiency is mostly marginal. It works more as a backstop against "ensuring you don't finish months behind schedule" more than "we're gaining efficiency and finishing early".
The problems with it mainly boil down to its only as good as how much buy-in you get from your subs. I just finished a $50m base build project using Lean Construction concepts. The project had around 50 different subcontractors on it. The big, union electrician who does ~$30m/year with us every year? Pretty easy to get him to buy into it and his team has done it before, so they understand the concepts and how it works. Trying to get the fire protection sub whose owner/PM still uses an aol.com email address to buy into it? Nearly impossible.
The other problem is that since subcontractors are independent from us, they have little incentive to show efficiency in their pull planning. If they determine they can complete their scope in 3 weeks with maximum efficiency, they're going to tell me 5 weeks during our pull planning, so they have some float and I'm not threatening them with LDs if they're late. If they tell me 5 weeks and finish in 4, then they look great. What do they care about the entire project schedule? The lack of skilled labor / companies across the country means that even if they screw me on schedule, chances are I'm going to come crawling back to them to bid my work next time I have a project. We've got very little leverage to enforce compliance.
We've toyed around with paying subs bonuses for finishing quicker, but it's hard to get an owner to agree to allow us to spend money (almost all of our jobs are GMP) for incentive bonuses. Why would they agree to spend additional money to make sure someone meets their contractual obligations?
Anyhow. I look forward to future posts about Lean Construction. It really does have some beneficial additions to a job, and I'm curious to hear about others best practices.
Could you apply a CONWIP system by redefining WIP from "physical items being worked on" to something like "tasks which are ready to be started"? You've previously used the example of a worker needing to take a break from nailing to reload their nailgun - the joints that are in position to be nailed up could be considered WIP.
I hate, hate, hate the explanation of TPS as primarily a way to reduce WIP. It's lead to multiple generations of managers who know how to do basic math to calculate the total value of WIP vs the enterprise value of the company and conclude that TPS only results in incremental gain, primarily through reducing inventory and implement a shallow version of the system that's essentially "strip out all the safety and fingers crossed nothing bad happens".
The way I would explain TPS is that it starts from a premise that predicting the future is a fundamentally expensive activity that needs to be balanced against other fundamentally expensive activities and that we tend to miss this because a lot of our evaluation frameworks implicitly treat predicting the future as free and that we need to design holistic systems with *regret minimization* as the core north star metric.
ie: If you're asked to design a factory that can produce 1M pins per day with a maximum quality tolerance of X for the lowest cost possible, implicit in the evaluation is that you already know 1M pins is what the market demands and any pin that fails X has a value of 0 and all pins that pass all have the same value... *but you don't know that*. The good thing with the metric is that it's simple and context free, the bad thing is that it strays people off the path of regret minimization. How would you design a pin factory if you didn't know how many pins you needed to produce and didn't know what quality they needed to be? You'd probably design the lines to be more modular, easy to set up and tear down as demand fluctuated, you'd probably design quality to be something that could be ramped up or down with a different mix of quality/price tradeoffs as you learnt what quality the market demands. All of these changes will inherently make this factory worse at producing pins at the 1M/day, quality X level at the benefit of being better across a range of other parameters, but this also makes the evaluation a lot trickier because how do you compare tradeoffs?
At the core of TPS, you have two operations that you can use to manipulate the cost of predicting the future: you can move information back in time or you can move decisions forward in time. All of TPS is building out systems that manipulate one of those two variables. eg: Kanban is a combination of making sure your upstream knows you're out of buffer as fast as possible and delaying the decision of starting production until you know there's a high probability need for that production to be used.
TPS is not a system for building the same thing cheaper, if you have a fixed endpoint, the TPS version is always going to cost more than the non-TPS version. Instead, TPS is a method for producing vastly better *quality* for just a small increase in cost and to use that quality to justify the higher cost.
To think about TPS from a building perspective, you have to start from the end and work backwards: What do people regret about buildings once built, lived in and EOLed, what was the future point where that regret became known and where was the decision point that lead to that regret and can you either move the information point back or the decision point forward such that regret is minimized.
eg: one common regret about buildings is layout, things look fine on a blueprint but once you move in, there's a bunch of niggling little layout issues that you wish you could have changed. You can move the information point back by, eg: building out a VR simulation of the house and performing a standardized set of everyday tasks in the house and discovering issues early and iterating on the design. You can also move the decision point forward by building in a system that makes tearing down walls and changing doors/windows etc easier, so lightweight wood construction vs concrete for example. This is the How Buildings Learn perspective on building which is that buildings can't be evaluated at a static point in time, but instead as learning systems where the decision cadence should be matched to the layer of the building that has the right flexibility.
Another thing a TPS style system would consider is, rather than start with a blueprint up front and producing what's on the blueprint come hell or high water, what are major points of learning and how do they get integrated into the design. eg: will a certain soil test alter the design implications depending on what the result of the test is? If so, then build this flexibility into the process of building the house. Usually, what this means is that we can find areas of cost saving by discovering what aspects of the house are overspecified for the specific conditions and rather than relying on static rules of thumb, we can strategically strip out materials that don't affect performance.
The problem with TPS and descendant systems is that they're all holistic systems, which means that they can lose most of their benefits if just one part of the system isn't operating in line. Usually, the biggest hurdles of properly adopting the system is getting the regulatory side on board. Regulations that were built under the assumption of Big Design Up Front can have a hard time wrapping their heads around lean/agile systems and the interface costs eat up all the other gains. This is partially the explanation of why advanced framing is so slow to catch on, platform framing is tried and true and easier to sail through regulatory approval and the material saving of advanced framing isn't enough to justify the increased regulatory risk.
Ultimately, truly implementing TPS style systems are a lot harder than they look because the existing way of doing things is stuck in a local maxima and taking a holistic look at the system means that many things need to change before things are better than they are before. This leads to a lot of shallow implementations that don't really change things for the better and people being underwhelmed with the results. Construction, especially, seems stuck so deeply in the current local maxima that even though there seems theoretically so many ways of doing things better, getting out of the hole is the biggest hurdle.
The article is great for beginners of Lean Construction but for those veterans, they seemingly have been left a lot empty.
I founded Lean Station in 2015 to get the best of the management methods of agile (or Lean) and structured CPM approach to improve the effectiveness of decisions in construction projects.
IMHO, the process is in stationary and the WIP product is in motion in manufacturing where as it’s inverted in construction where the process is in motion and the WIP product is stationary.. this being the fundamental difference and further convulsed and adversarial contracting making the application of Toyota based management or Lean Construction not as simple as it’s written or publicised.
A key aspect missing in the article is that of constraints (the necessary non-value added prerequisites). Unlike a bottle on an assembly line in a bottling plant, and a dispenser programmed to dispense - the construction equivalent is the detailed planning (pull planning) and the commitment of the subs (monitored by PPC). The constraints for the detailed plan can be any of the 10-20 checklists that needs to be completed all the way from design- safety- procurement- compliance (all these needs to be done before each of the task gets on to the assembly line for further commitment from the subs)
I wrote an article on this, some years back (Construction pull planning with only kanban is like running a marathon with one leg tied up) https://link.medium.com/V9gzShzlQkb
The availability of reliable information both for planning and execution are extremely critical for data driven decisions, this creates a need for real-time flow of information all the way from the schedule (Master program) to the daily task list which in turn opens the needs for a real-time robust data analysis system that can compute the impacts (of variations, delays etc) and alert key stake holders of potential risks in planning or execution.
We are advancing towards an integrated Lean project delivery system addressing these concerns and much more with Lean PlanDo. It’s meant for lean mature Clients/ GC / MC to drive a culture of Lean in their projects, well beyond the hype.
In homebuilding (perhaps even more so in GC work), production workflow is project portfolio management with embedded and supporting processes. We have blended Lean and TOC; we do what works, without regard to the denomination from which it comes.
Great article! A couple of thoughts that may help.
The fundamental purpose of any lean system (TPS being one of these) is to maximize flow of value to the customer by eliminating waste. Inventory is the most-focused-on waste in manufacturing for several reasons: it's (generally) very visible; cash is tied up in raw materials, purchased components, WIP, and finished goods; space is required to store all the inventory; and inventory hides (acts as a buffer for) other wastes. However, inventory isn't the only waste.
There are a number of ways people have enumerate waste; my favorite uses the mnemonic DOWNTIME:
*Defects
*Overproduction
*Waiting
*Non-utilization of people's skills
*Transportation
*Inventory
*Motion
*Excess Processing
Thinking of that, in construction (or any service industry, really), you can see a number of more prevalent, more insidious wastes than inventory. Waiting chief among them - how many times have you seen a crew waiting for weather, or materials, or guidance? Or a job site waiting for the next trade to come and do their thing? Do we ever see Excess Processing waste? (gold-plating or rework?) Transportation -- moving materials from distributor to warehouse, to job site, to actual work location? Lean systems such as TPS work by making problems obvious and applying a variety of tools to minimize wastes.
In your Gantt chart example, there certainly isn't WIP to pull out, but there is plenty of other waste. How often do the steps start and finish exactly on time? What are the wastes that prevent flow of value and smooth flow of work? Value stream mapping may help, as we identify the value-adding processes and the gaps between. In manufacturing, these gaps are filled with inventory. In service work, these gaps are filled with time - waiting and delays.
One final thought, my favorite lean quote: "There are four purposes of improvement: [making the work] easier, better, faster, and cheaper. These four goals appear in the order of priority." -- Shigeo Shingo
Couldn't you get TPS benefits if the construction firm handles enough buildings at the same time, even if they're not within a single housing project? If you build 100 single family homes at once across the city, you can maximize the utilization of each subcontractor (vs them wasting time between jobs) and ensure that, say, an electrician wouldn't be called in before the job site is ready for them to start working. You would rapidly determine the biggest bottlenecks in your process (say, the concrete pouring team is constantly struggling with the foundation) and could improve on them by sending in someone to observe what the contractors are doing, even if they're ambivalent about finding ways to improve.
The only condition would be that you only work on one specific type of project. So the company could only churn out identical single family homes or identical townhouses or identical low-rise condo building, with no customization offered at all. Have any companies tried something like that? Usually if you go on a construction company's website they have a ton of different stuff in their portfolio rather than an endless list of completely identical houses.
I'm wondering how you limited work-in-progress in your pin factory simulation. Is that "Basic CONWIP" (an overall limit) or Kanban? Is source available?
I work at a GC that has bought in fully to Lean Construction and while it has some benefits and good practices, I think it's gain on efficiency is mostly marginal. It works more as a backstop against "ensuring you don't finish months behind schedule" more than "we're gaining efficiency and finishing early".
The problems with it mainly boil down to its only as good as how much buy-in you get from your subs. I just finished a $50m base build project using Lean Construction concepts. The project had around 50 different subcontractors on it. The big, union electrician who does ~$30m/year with us every year? Pretty easy to get him to buy into it and his team has done it before, so they understand the concepts and how it works. Trying to get the fire protection sub whose owner/PM still uses an aol.com email address to buy into it? Nearly impossible.
The other problem is that since subcontractors are independent from us, they have little incentive to show efficiency in their pull planning. If they determine they can complete their scope in 3 weeks with maximum efficiency, they're going to tell me 5 weeks during our pull planning, so they have some float and I'm not threatening them with LDs if they're late. If they tell me 5 weeks and finish in 4, then they look great. What do they care about the entire project schedule? The lack of skilled labor / companies across the country means that even if they screw me on schedule, chances are I'm going to come crawling back to them to bid my work next time I have a project. We've got very little leverage to enforce compliance.
We've toyed around with paying subs bonuses for finishing quicker, but it's hard to get an owner to agree to allow us to spend money (almost all of our jobs are GMP) for incentive bonuses. Why would they agree to spend additional money to make sure someone meets their contractual obligations?
Anyhow. I look forward to future posts about Lean Construction. It really does have some beneficial additions to a job, and I'm curious to hear about others best practices.
Could you apply a CONWIP system by redefining WIP from "physical items being worked on" to something like "tasks which are ready to be started"? You've previously used the example of a worker needing to take a break from nailing to reload their nailgun - the joints that are in position to be nailed up could be considered WIP.
I hate, hate, hate the explanation of TPS as primarily a way to reduce WIP. It's lead to multiple generations of managers who know how to do basic math to calculate the total value of WIP vs the enterprise value of the company and conclude that TPS only results in incremental gain, primarily through reducing inventory and implement a shallow version of the system that's essentially "strip out all the safety and fingers crossed nothing bad happens".
The way I would explain TPS is that it starts from a premise that predicting the future is a fundamentally expensive activity that needs to be balanced against other fundamentally expensive activities and that we tend to miss this because a lot of our evaluation frameworks implicitly treat predicting the future as free and that we need to design holistic systems with *regret minimization* as the core north star metric.
ie: If you're asked to design a factory that can produce 1M pins per day with a maximum quality tolerance of X for the lowest cost possible, implicit in the evaluation is that you already know 1M pins is what the market demands and any pin that fails X has a value of 0 and all pins that pass all have the same value... *but you don't know that*. The good thing with the metric is that it's simple and context free, the bad thing is that it strays people off the path of regret minimization. How would you design a pin factory if you didn't know how many pins you needed to produce and didn't know what quality they needed to be? You'd probably design the lines to be more modular, easy to set up and tear down as demand fluctuated, you'd probably design quality to be something that could be ramped up or down with a different mix of quality/price tradeoffs as you learnt what quality the market demands. All of these changes will inherently make this factory worse at producing pins at the 1M/day, quality X level at the benefit of being better across a range of other parameters, but this also makes the evaluation a lot trickier because how do you compare tradeoffs?
At the core of TPS, you have two operations that you can use to manipulate the cost of predicting the future: you can move information back in time or you can move decisions forward in time. All of TPS is building out systems that manipulate one of those two variables. eg: Kanban is a combination of making sure your upstream knows you're out of buffer as fast as possible and delaying the decision of starting production until you know there's a high probability need for that production to be used.
TPS is not a system for building the same thing cheaper, if you have a fixed endpoint, the TPS version is always going to cost more than the non-TPS version. Instead, TPS is a method for producing vastly better *quality* for just a small increase in cost and to use that quality to justify the higher cost.
To think about TPS from a building perspective, you have to start from the end and work backwards: What do people regret about buildings once built, lived in and EOLed, what was the future point where that regret became known and where was the decision point that lead to that regret and can you either move the information point back or the decision point forward such that regret is minimized.
eg: one common regret about buildings is layout, things look fine on a blueprint but once you move in, there's a bunch of niggling little layout issues that you wish you could have changed. You can move the information point back by, eg: building out a VR simulation of the house and performing a standardized set of everyday tasks in the house and discovering issues early and iterating on the design. You can also move the decision point forward by building in a system that makes tearing down walls and changing doors/windows etc easier, so lightweight wood construction vs concrete for example. This is the How Buildings Learn perspective on building which is that buildings can't be evaluated at a static point in time, but instead as learning systems where the decision cadence should be matched to the layer of the building that has the right flexibility.
Another thing a TPS style system would consider is, rather than start with a blueprint up front and producing what's on the blueprint come hell or high water, what are major points of learning and how do they get integrated into the design. eg: will a certain soil test alter the design implications depending on what the result of the test is? If so, then build this flexibility into the process of building the house. Usually, what this means is that we can find areas of cost saving by discovering what aspects of the house are overspecified for the specific conditions and rather than relying on static rules of thumb, we can strategically strip out materials that don't affect performance.
The problem with TPS and descendant systems is that they're all holistic systems, which means that they can lose most of their benefits if just one part of the system isn't operating in line. Usually, the biggest hurdles of properly adopting the system is getting the regulatory side on board. Regulations that were built under the assumption of Big Design Up Front can have a hard time wrapping their heads around lean/agile systems and the interface costs eat up all the other gains. This is partially the explanation of why advanced framing is so slow to catch on, platform framing is tried and true and easier to sail through regulatory approval and the material saving of advanced framing isn't enough to justify the increased regulatory risk.
Ultimately, truly implementing TPS style systems are a lot harder than they look because the existing way of doing things is stuck in a local maxima and taking a holistic look at the system means that many things need to change before things are better than they are before. This leads to a lot of shallow implementations that don't really change things for the better and people being underwhelmed with the results. Construction, especially, seems stuck so deeply in the current local maxima that even though there seems theoretically so many ways of doing things better, getting out of the hole is the biggest hurdle.
The article is great for beginners of Lean Construction but for those veterans, they seemingly have been left a lot empty.
I founded Lean Station in 2015 to get the best of the management methods of agile (or Lean) and structured CPM approach to improve the effectiveness of decisions in construction projects.
IMHO, the process is in stationary and the WIP product is in motion in manufacturing where as it’s inverted in construction where the process is in motion and the WIP product is stationary.. this being the fundamental difference and further convulsed and adversarial contracting making the application of Toyota based management or Lean Construction not as simple as it’s written or publicised.
A key aspect missing in the article is that of constraints (the necessary non-value added prerequisites). Unlike a bottle on an assembly line in a bottling plant, and a dispenser programmed to dispense - the construction equivalent is the detailed planning (pull planning) and the commitment of the subs (monitored by PPC). The constraints for the detailed plan can be any of the 10-20 checklists that needs to be completed all the way from design- safety- procurement- compliance (all these needs to be done before each of the task gets on to the assembly line for further commitment from the subs)
I wrote an article on this, some years back (Construction pull planning with only kanban is like running a marathon with one leg tied up) https://link.medium.com/V9gzShzlQkb
The availability of reliable information both for planning and execution are extremely critical for data driven decisions, this creates a need for real-time flow of information all the way from the schedule (Master program) to the daily task list which in turn opens the needs for a real-time robust data analysis system that can compute the impacts (of variations, delays etc) and alert key stake holders of potential risks in planning or execution.
We are advancing towards an integrated Lean project delivery system addressing these concerns and much more with Lean PlanDo. It’s meant for lean mature Clients/ GC / MC to drive a culture of Lean in their projects, well beyond the hype.
In homebuilding (perhaps even more so in GC work), production workflow is project portfolio management with embedded and supporting processes. We have blended Lean and TOC; we do what works, without regard to the denomination from which it comes.
Great article! A couple of thoughts that may help.
The fundamental purpose of any lean system (TPS being one of these) is to maximize flow of value to the customer by eliminating waste. Inventory is the most-focused-on waste in manufacturing for several reasons: it's (generally) very visible; cash is tied up in raw materials, purchased components, WIP, and finished goods; space is required to store all the inventory; and inventory hides (acts as a buffer for) other wastes. However, inventory isn't the only waste.
There are a number of ways people have enumerate waste; my favorite uses the mnemonic DOWNTIME:
*Defects
*Overproduction
*Waiting
*Non-utilization of people's skills
*Transportation
*Inventory
*Motion
*Excess Processing
Thinking of that, in construction (or any service industry, really), you can see a number of more prevalent, more insidious wastes than inventory. Waiting chief among them - how many times have you seen a crew waiting for weather, or materials, or guidance? Or a job site waiting for the next trade to come and do their thing? Do we ever see Excess Processing waste? (gold-plating or rework?) Transportation -- moving materials from distributor to warehouse, to job site, to actual work location? Lean systems such as TPS work by making problems obvious and applying a variety of tools to minimize wastes.
In your Gantt chart example, there certainly isn't WIP to pull out, but there is plenty of other waste. How often do the steps start and finish exactly on time? What are the wastes that prevent flow of value and smooth flow of work? Value stream mapping may help, as we identify the value-adding processes and the gaps between. In manufacturing, these gaps are filled with inventory. In service work, these gaps are filled with time - waiting and delays.
One final thought, my favorite lean quote: "There are four purposes of improvement: [making the work] easier, better, faster, and cheaper. These four goals appear in the order of priority." -- Shigeo Shingo
Hey Brian, do you know anything about China-based Broad Group?
http://en.broad.com/
http://en.broad.com/NewsDetail-86.aspx
Couldn't you get TPS benefits if the construction firm handles enough buildings at the same time, even if they're not within a single housing project? If you build 100 single family homes at once across the city, you can maximize the utilization of each subcontractor (vs them wasting time between jobs) and ensure that, say, an electrician wouldn't be called in before the job site is ready for them to start working. You would rapidly determine the biggest bottlenecks in your process (say, the concrete pouring team is constantly struggling with the foundation) and could improve on them by sending in someone to observe what the contractors are doing, even if they're ambivalent about finding ways to improve.
The only condition would be that you only work on one specific type of project. So the company could only churn out identical single family homes or identical townhouses or identical low-rise condo building, with no customization offered at all. Have any companies tried something like that? Usually if you go on a construction company's website they have a ton of different stuff in their portfolio rather than an endless list of completely identical houses.
I'm wondering how you limited work-in-progress in your pin factory simulation. Is that "Basic CONWIP" (an overall limit) or Kanban? Is source available?