Topics covered: Lean engineering basics
Instructor: Earll Murman, Annalisa Weigel, Al Haggerty, Hugh McManus
This video is from the IAP 2008 version of the class.
The following content is provided under a Creative Commons license. Your support will help MIT OpenCourseWare continue to offer high quality educational resources for free. To make a donation or view additional materials from hundreds of MIT courses, visit MIT OpenCourseWare at ocw.mit.edu.
ANNALISA WEIGEL: So if I can have your attention please, we are going to break from our simulation for just a moment to talk about our next module, called Lean Engineering Basics. There are two key takeaways that we'd like you to get from this module, and they're worth reiterating and I will say them several times during the course of the module. The first thing we want you to internalize is that lean thinking applies to engineering just as much as it applies to factory processes. And two, that engineering plays a critical role in creating value in lean enterprise. And our presentation today is broken down along those two lines. And I'm going to start talking about why lean thinking applies to our engineering processes.
Here are our learning objectives for this module. They are five-fold. So at the end, you should be able to explain how our lean principles and practices apply to engineering. You should be able to explain why customer value and this upfront part of engineering and the conceptual design are critical to product success. You should be able to describe how lean engineering enables lean throughout the whole enterprise and the product lifecycle.
Fourth, you should be able to describe some tools we use for lean engineering. And lastly, you should be able to apply lean engineering techniques to redesign your simulated airplane. So we'll spend the first half of this module talking concepts. And we'll spend the second half of this module in an active learning exercise, trying to apply some of the things we learned to the redesign of your simulated airplane.
A few days ago, we had a question about wastes in engineering compared to wastes in the factory. And this chart is actually the answer to that question. We did say we'd defer it a few days, and now we're going to tackle it. So here are five lean thinking steps we talked about in the first day, what they mean for the manufacturing process, and then lastly, how we translate those over into engineering.
Now, one of the challenges we've had in applying lean to engineering has been a reaction from the engineering group that says, well, you know, you can apply lean in the factory, but engineering is just different. You can't really apply it here. And yes, of course, engineering is different than the factory operations. But that doesn't mean that these lean principles-- which are very universal, and you've seen applied across the enterprise from office processes to manufacturing-- why they can't apply to engineering as well.
The difference, mainly, from manufacturing to engineering, is a thing that's flowing through the system. So in a manufacturing context, you have the raw materials that are flowing through the system, and being processed and changed. In engineering, it's really information that is flowing through the value stream-- that is being processed and changed. Your design emerges, uncertainties are reduced, expectations are clarified, and so on. These are all examples of the information that's flowing through your engineering value stream.
So for manufacturing, the addition of value at any step is pretty visible. We told you that you have to look and see if a thing is physically changed to add value. And you can usually see that as your material gets processed. This is a little bit harder to see in engineering. When you change part of your design or when you do an analysis, it's not quite as easy to see that you've change the information. But you usually have.
The second contrast in that manufacturing, your goal is very defined. When you start manufacturing, you have a very specific set of specs and drawings. And at the end, you expect to come out with exactly the product that you wanted to when you started the manufacturing process.
Now this is different than engineering, because in engineering our goal is emergent. We have some sense that there are requirements, and we have maybe some notion of how we might meet those. But the whole process of engineering and design is to look at different alternatives and to then come up with a set of specifications for product that you can build. So your goal is really emergent in that sense.
Now, we go down to the value stream. You can do a value stream map for information just like you can for material flow. The one difference is what's actually flowing through that.
Now, if we move on to our concept of flow, which is trying to make everything seamlessly go, in manufacturing, iterations are usually considered waste. They're indicative of rework in the process, or a process or design that wasn't spec'd right up front. But in engineering, as you all probably recognize, mostly being engineering students, iterations are OK. We plan to do these.
And that's a key word there is that planned iterations are good. We recognize that going through analysis, and looking at problems, and looking them again is important. The key there is that you want your planned iterations to be as efficient as you can.
The fourth concept of pull, which in a manufacturing sense is driven by tag time, for the engineering processes, that's usually driven by your enterprise needs for new products to be developed. And then, the concept of perfection, which in a manufacturing context means processing without repeating errors, how does that translate into engineering? We would think of it as engineering processes that enable your whole enterprise improvement. And I'm going to expand on that concept in the second half of the lecture.
Here, we're revisiting our seven wastes that we identified-- over-production, inventory, transportation, unnecessary movement, waiting, defective outputs, and over-processing. So I'd like you all to think back to your engineering experience, either from classes or maybe from summer jobs. And I'd like to hear some examples, in an engineering context, of any of these seven wastes. Go ahead, please.
AUDIENCE: So yesterday, at the New Balance factory, we were on the right side of the factory. We were talking about how the upper part and the lower part of the shoe was actually manufactured in China. But then, they shifted back over here just to essentially glue the top and bottom parts together so that they can say, assembled in the United States. And our group asked if wasn't that a waste in transportation, the cost, and the time, and all that kind of stuff just so they could say, assembled in the United States. And they want-- they felt that it was worth it that they could just say, you know-- that they put the US logo on it in turn for having that transportation waste.
ANNALISA WEIGEL: Interesting, OK, so that to me has some elements of both manufacturing and the engineering design, and perhaps some business strategy to it. Can we try to think of just isolating examples to the engineering process. Think about conceptual design. And let's talk about some examples. Go ahead.
AUDIENCE: Well, at my internship last summer, they were talking about how a lot of older people had really great skills in specific areas. And they were worried that the older engineers weren't communicating those skills to the younger engineers. And so when they left, there would be waste, because people would have to relearn that specific engineering skill. So they created a Boeing Wikipedia, and were encouraging engineers to type up articles to try to keep that information that other people needed.
ANNALISA WEIGEL: That's a very interesting example. Let me ask the class-- these are the seven waste categories. What do you-- which category do you feel that example might fit in? Inventory-- having more material or information than you need? Any other thoughts? OK, Earl, you have an important--
AUDIENCE: Just that New Balance, we heard an eighth waste category, which was, for their environment, unused associates creativity, which was sort of a loss of human-- a waste of human resources. Would this fall in that category?
ANNALISA WEIGEL: Yeah, to me it falls in eight. I might also say it perhaps falls in one, if I thought that I had to produce two engineers, and the information wasn't officially being passed between the first one who got the knowledge. And then, I had to go through the exact same steps to get the second engineer that same knowledge without taking any advantages.
But this is one of the interesting examples of translating largely manufacturing a material-based instances of waste into engineering, is that sometimes is a very clear translation. And sometimes it's a little harder to figure out where it is. But I think we can all agree that example that Emily gave, it's feels like there's something that's being wasted there in an engineering sense. A lot of experience-- and engineers' knowledge is very experiential-- is being gathered, and then sort of just left to go away and not be utilized by the company anymore.
Let's take another example.
AUDIENCE: I was just wondering, could that be thought of as over-processing as well, because you need to kind of do more from scratch training of the [INAUDIBLE]?
ANNALISA WEIGEL: Yeah, I could take that argument, definitely. Can you-- go ahead.
AUDIENCE: I guess I may be missing a point. So I just want to clarify, how does it help me to solve the problem by classifying it in one of these seven ways? For example, if I know what the problem is I'm throwing out talent, I'm throwing out knowledge that I've got to then retrain, how can I use these-- sort of this classification-- to help me solve it?
ANNALISA WEIGEL: Sure, what you're doing is you are standing on the shoulders of giants of people who spent decades of years, and probably millions of hours of brainpower, trying to figure this out. So let's start with this is our analogy. And then we'll probably create unique categories of waste that apply to engineering. But this is a great start, where in absence of some classification system, you may spend a lot of time trying to figure out what that is. So it's really just a creative tool for us to help understand the parallels to engineering.
AUDIENCE: I think it's more of, like, finding waste you use these. If you like looking at your organization, you would look through this and be, like, oh, OK, I see this, and this, and this, and it helps you find new waste instead of just analyzing waste that you probably [INAUDIBLE].
ANNALISA WEIGEL: Excellent, thank you. Let's have another example of a waste that's different than the ones we talked about. [INAUDIBLE]?
AUDIENCE: Mine would be either waiting or an unnecessary movement. I was working with GE Nuclear in California. And every time we were doing a purchasing order or test specifications that had to be approved, it had to be approved in Georgia, which is a three hour time difference. Which means that either you have to come to the office at 6:00 in the morning if you're wanting your thing to be processed right away when they open, or you have to stay up later at night to finish it.
So everybody was very upset about that. We were losing six hours in a day of work. And the tests were being done in Massachusetts. So the engineers had to fly over there, spent some time running through the tests and get the results back. And it was a waste of time for everyone, and energy, and other things.
ANNALISA WEIGEL: Great, great, and a good example of waiting-- waiting is a very common kind of waste, if you think about information and design that's happening. How about other examples?
AUDIENCE: I work here at MIT, and the first week, I had to buy something for a project. And no one how to buy anything. Like, my advisor didn't know. Eventually, they found out that the woman in charge had just moved, and no one had replaced her. So I guess it was waiting, or a defective output, or something like that.
ANNALISA WEIGEL: There's several kinds of problems with that particular process, yeah. Unnecessary movement also happens quite frequently in an engineering sense, as well as transportation. So if you think about how many times you move information, change information from the inputs of one analysis program into a format that's compatible with another analysis program-- think about going back and forth here on campus between MATLAB and Excel happens frequently.
Now, if you go out into a very complex industry like aerospace, the tools are far more complex. And translating the inputs of one of the outputs to another, and so on, is a large deal. They're not necessarily made to be compatible. And then, we heard [INAUDIBLE] talk about a lot of unnecessary movements that may happen-- moving people to various places to test things to get analysis results for your design. Because sometimes these complex products are so large and expensive, we can't afford to have testing facilities locally to try to minimize that kind of waste.
All right, we're starting to get a sense. And we'll talk about them further as we go through the simulation game and the rest of our module today. I wanted to point out some data that we have about the efficiency of engineering processes. If you have any doubt that there's waste in engineering, this should help convince you that there is at least by some informed people.
So this is a measure of effort that's wasted. 40% of the product development effort was classified as pure waste. About 30% is necessary waste. In another survey, we had 30% of product development time that was charged to just set up and waiting. You can easily see why those don't add a lot of value to the customer.
And not only is effort wasted, but time is wasted. 62% of tasks, on average, were idle at any given time in a survey of particular companies. And 50% to 90% of task time is found to be idle in various Kaizen-type events that are run in an engineering context at different kinds of companies. So clearly, lots of room for improvement here in the process of engineering.
There's been a good body of research done here at MIT. And they produce the Product Development Value Stream Mapping manual. And this is authored by Hugh, who's in the back of the room. The same basic techniques apply as you might do value stream mapping in the factory context to the engineering context, except that the flows are information rather than physical, and your value added steps help to transform this knowledge or to reduce the uncertainty, which is a primary role of why we do analysis in engineering.
And if you're interested, you can consult this publication. There's a lot more material here than we can cover in this module. But let me give you some real-life examples of organizations that have applied product development value stream mapping and had some successes.
So this is an example on the F16. And they had some particular problems with what they call their build-to-Package process. So if, for some reason, they needed to make changes to the build-to-packages, like you all have in front of you for your SIM, there was a big, long process that actually had to happen from I need a change to, OK, I can actually make a change. It numbered a lot of steps. You can kind of count them all here. It goes here, and then it goes down there, and then it goes all the way through there, and all the way through there before we get out to a change.
So applying some of the tools of value stream mapping, the F16 build-to-package process was reduced down to something like this. So now, we had single-piece flow being able to go through the system. We had an allowance for parallel processing of tasks, rather than single processing of tasks. Concurrent engineering principles were brought in to help achieve this kind of leanness in process, as well as co-location of all the various different units between design, and manufacturing, and quality that needed to be co-located to accomplish this.
And if you wanted some illustration of the results that can be achieved, we have that here in this slide. So this is actually a picture here of the build-to-package support center that resulted from this value stream mapping activity. It's a facility that's down on the shop floor. So it's very close to the things that they're trying to change.
They created these kinds of improvements-- in cycle time, from getting a change request in to having implemented that, 75% reduction of cycle time. Process steps were reduced by 40%, handoffs by 75%, and travel distance of the information, and paperwork, and so on was reduced by 90%. These are very, very real kinds of savings that can be achieved in the engineering process by the application of value stream mapping techniques.
Now, we're going to move on to the second concept that we'd like you to take away. And that is that engineering plays a critical role in creating value in the enterprise. So we've just seen how we can apply some of our lean thinking techniques-- including value stream mapping, the concepts of waste, and so on-- to the process. But then, there's a really important reason why we want to lean out the engineering process. Because it's a key enabler for lean in the rest of the enterprise.
The reason for that is represented here on this chart. So we have on the y-axis, essentially, the percentage of your lifecycle budget that you might attribute to these. And here on the x-axis, we have lifecycle phases, starting from concept development through detailed design, production use, and disposal.
Here, we show various curves. So as you go through the engineering design process, you as engineers are making choices. You decide to use a particular material. You decide on a particular design. That has manufacturing implications, performance implications, and so on. And as you make those choices, which are right here in conceptual design, you are determining a priori the cost of that system by your choices.
At the same time as we move through this process, the leverage that management has to make any changes starts to go down dramatically, because a lot of the knowledge and the cost is being committed there. But as cost is being committed early, it's really not being incurred by your organization for a while. Because you're not buying materials, you're not bending metal, you're not into the expensive parts. That starts to happen over here. But yet, you've already decided it way back here in conceptual design.
And a similar curve is shown for knowledge. This is what we know about the design of the product, the performance, the quality, the use, the reliability, and so on. As you start out early in a design, you just don't know a lot about it. It's a process of discovery, and analysis, and refinement. And that knowledge grows as you go further down in the lifecycle phase. But it doesn't grow nearly as fast as you're committing cost to that. So there's a lot of uncertainties that exist in the process.
But it's this extreme leverage that we have up here in concept development to determine all of the properties of our system that's so fundamentally important. And this is why lean thinking needs to start with engineering. Because the engineers are making those critical choices that are going to determine cost, and performance, and reliability, and safety, and usability, and maintainability, and so on.
So lean engineering is really about doing the right thing right. It's got three components to it. You first have to create the right products. You have to do that with effective enterprise and lifecycle integration. And you have to use efficient engineering processes. And we're going to take each of those in turn.
So creating the right product means focusing on the customer. And to do that, you have to shift some resources up front to the conceptual design process so that you can spend enough time to really make the right choices about the product. Effective enterprise and lifecycle integration means that we should use our lean engineering tools so we can create value throughout the product lifecycle and enterprise, and being efficient while we do so, so apply the lean thinking to eliminate waste and improve the processes of engineering.
So starting out with our first point about creating the right products, how do you know what's right? The customer is the one who specifies that for you. And generally, when they're thinking about value, they have got four large elements in mind that sum up to be their value. There are some elements of features, and performance, and quality. There's some element of schedule and when I can get it. There's an element of cost that they have to pay for that. And then there's some element of price-- of what it costs you to make that.
And if you think to any purchase that you make, you are either consciously or unconsciously balancing all these parts that equate to value of a product in your mind. So you may want a computer that has a certain kind of performance and price to you. But if you can't get it for four weeks, you may decide that that's not really a good value proposition for you. And you may choose to set some other combination of attributes for yourself that really defines value.
Engineering drives the cost of all the products. So 80% of the product's cost is determined through the engineering design when these choices are made. So the number of parts that you have, every part costs some money. Parts have to be inventoried. Parts have to be designed. Parts have to be transported, they have to be maintained, they have to be quality controlled, and so on.
And each of those actions incurs a particular cost, as well as tolerances on parts. I'm sure some of you who have gone through engineering classes have talked about how strict tolerances can really increase the cost of producing a product. Whereas if you relax tolerances, you may get to a slightly lower cost on your parts.
You can think of assembly techniques-- different assembly techniques cost different amounts of money, some are much more complex and complicates-- as well as processes to treat raw materials, and the tooling approach that you might use, again, that ranges from cheaper to more expensive. Materials-- if you want to build something out of titanium, it's going to cost you differently than to build it out of other materials.
Avionics and software, design complexity, whether or not you're reusing previous design efforts-- these all contribute to the product's cost. And these are choices that the engineer is making. So this is, yet again, another illustration of why it's so important to try to make the right choices, spend the amount of time you need to do that up front.
This is a reflection back to our suppliers talk. Don't forget suppliers. They're a critical component of your design and ensuring that you have the right cost on your system. Typically, 60% to 80% of value is added by suppliers. So when you think about the engineering processes, don't neglect them.
One of the best practices for achieving the engineering result that you want is to use integrated product and process development. It's a concept that utilizes a couple of elements-- first, the principles of systems engineering to translate your customer needs into a product architecture and a set of specifications; using integrated product teams so that you can bring knowledge from all the different lifecycle parts into your engineering activity.
Remember, we talked about the cost committed early on in the engineering activity and the uncertainty of knowledge. One way to increase the amount of knowledge you have is to bring people in from all the different lifecycle phases. So bring someone in from manufacturing. Bring someone in from the customer community who uses it. Bring somebody in from all the different parts so that you can increase your knowledge as early as you can.
Third, the IPPD approach utilizes modern engineering tools. And we're going to give some examples of that in a few slides. And it all can't really function unless we've got the right kind of human resources on board, which may require a certain skill set or certain set of people. So it's not just that you have capable tools, you need capable processes, and you need capable people to actually execute this successfully.
So here's a list of some of our tools of lean engineering. And I'm also going to show a couple of detailed examples in the next couple of slides. So we have digital tools that increase the timing of handoffs, decrease waiting, increase quality. There are production simulation tools that you can use, which are much cheaper on a computer than actually having to go out, and build a physical part, and try to play around with that. You can think about common parts and specs in reusing design, the design for manufacturing assembly, which we're going to talk about in the context of our planes, and so on. All of these are very useful tools for lean engineering.
And to show you that these are being used out in industry, this is an example from Boeing. This shows you how they brought together various different digital tools that went into producing the hardware. So they were able to use a CAD program to do different layouts and three-dimensional visualizations. They had a parametric solids modeling tool. They had some assembly models that were done in 3D CAD.
They electronically release their build-to-packages. They used a computer to simulate the manufacturing and assembly. And all this was done with far less cost than trying to go and build your hardware, and do all of your playing around in the physical space.
So I'll give you an example of the production simulation. I need to break a moment and go into my movie. Let's move on to another tool of lean engineering, that's common parts and reusing designs. So if you're using common parts, and you're reducing the total part count as a result, you're reducing costs, because every part that you don't have to design, you don't have to manufacture, and QC, and tag, and everything.
These are some great illustrations of trying to use what we call mirror parts. Do you need to have parts designed differently for the right hand side and the left hand side? Could you reconceive your design such that they used a common part? And this would then save on the number of unique parts. Also have to realize that common parts can increase the quality of your design-- less points of potential failure, less points of uncertainty, fewer moving parts in your manufacturing process, less room-- I'm sorry, fewer mistakes to be made in mistaking one part for another if I've got all common parts and so on.
So let's talk about part count reduction. This is largely a goal of what's called design for manufacturing and assembly. So I'd like some input from you guys on why we would reduce part count? We've covered a lot already, so you can kind of shout them out.
AUDIENCE: Faster assembly.
ANNALISA WEIGEL: Faster assembly. What else?
AUDIENCE: Easier for your supplier.
ANNALISA WEIGEL: Easier for the supplier. Thank you, Mr. supplier. Thank you, that was good. Yes?
AUDIENCE: Less variation--
ANNALISA WEIGEL: Less variation,
AUDIENCE: --to get tolerance build-ups?
ANNALISA WEIGEL: Yes, indeed. Does everybody catch that, the concept of tolerance build-ups? If you're reducing the part count, each part has a specific tolerance to it. The more parts you label together, kind of that-- the bigger that uncertainty in potential tolerance grows. If fewer parts, that comes down. What else? That is good.
AUDIENCE: Less chance of delivering mistakes?
ANNALISA WEIGEL: Fewer chances to make mistakes, because every part I handle has some probability that I'm going to make a mistake with it, and I have a few of those. Yeah, what else?
AUDIENCE: In many designs, increasing part count requires increased lubrication. And oftentimes, joints and things-- the more parts you have, the more need for lubrication, more work, [INAUDIBLE].
ANNALISA WEIGEL: Sure, so operational considerations that you might want to think about. And what are others? [INAUDIBLE]?
AUDIENCE: Simplifying the supply chain?
ANNALISA WEIGEL: Simplifying the supply chain, yep. Others? Go ahead.
AUDIENCE: Depends on situation, it could be cheaper [INAUDIBLE].
ANNALISA WEIGEL: Right, yes, it reduces cost. That's what your boss really wants to hear. It's going to reduce some cost for the enterprise. We've covered almost all of these. They were-- excellent discussion, and some others that we brought up that aren't quite on this list.
It's important to keep in mind, though, that sometimes, but not all the time, reducing your part count would require some performance trades. So cost and schedule savings may be big, but you may be trading off a little bit of performance. And if your customer is OK with that, then everybody wins in the end.
One particular aspect in aerospace systems is, of course, mass when you're thinking about that. And sometimes, going to common parts and fewer parts can increase mass, which may sort of dictate a performance ding to the system, but like I said, not always. And I think I'll show you an example later on that demonstrates that really clearly.
So what I want to do now is take you into an active learning exercise. And we're going to think about applying these lean engineering principles and practices to redesigning your airplane with a goal for part count reduction, and designing for manufacturing and assembly. So your first goal is to satisfy the customer. And the customer has a couple of desires.
They want the mold line of the airplane to remain the same-- exactly the same. So this is the outer shape. The customer also requires that the landing gear-- but just the landing gear-- must be brown. So it comes from a particular kind of material, and the customer feels that they really need the strength of that material on the landing gear. So those have to stay the way they are.
Thirdly, the customer has the desire for in-service quality to go up. Right now, the airplane is kind of fragile. You may have been handling a full airplane and noticed that the tail section tends to break off quite easily. Hugh will demonstrate. Oh, my goodness. [LAUGHS] So the wing is also, apparently a fragile part. It depends on where you hit the airplane.
But for example, I was sitting at the customer mat at one table. I took delivery of an aircraft. And as soon as I grabbed it, the tail section fell off. This is a real thing. So perhaps, you can address the customer's desire for a slightly more robust design. And fourthly, as we've been talking about from the beginning, the customer really wants 12 airplane to be delivered per round. So they want you to increase the delivery quantities.
You want to think about reducing your manufacturing cost, because this is good for your enterprise. So your parts are going to cost $5 per part, regardless of part. Less parts then equals more capacity for you. And thirdly, we want you to incorporate the suppliers. What kinds of innovations could you generate by working better with your suppliers? Could you reduce a part desercity? What else could you do applying lean engineering principles in concert with your supplier?
So I'm going to give you about 20 minutes or so to talk in your teams and redesign your aircraft. You're going to work with your facilitator. And you need to demonstrate that it satisfies all of these criteria for the customer.
ANNALISA WEIGEL: All right, everybody take your seats again, please. I could tell you're all having fun redesigning your airplanes. Let me use the next couple of slides to finish out this module to give you some motivation for why lean engineering has been helpful in practice. I'm going to cite a couple of real world examples here.
The first is an exercise in design for manufacturing assembly to reduce part counts. In the latest iteration of the F-18, called the E/F, the company the builds that went on a part count reduction exercise by employing design for manufacturing assembly techniques. In each of the major assemblies for the plane, they went and reduced the part counts from the C/D version, which was a previous iteration, to the E/F version. So in total, we went from having 14,000 plus parts in the C/D version, to having just over 8,000 parts in the E/F version. This was a 42% part count reduction.
Now, we talked before about how sometimes, part count reductions come with sacrifices in performance. But this was not the case. So the F-18 E/F version turned out to be 25% more capable than its previous predecessor. So this was an excellent win-win situation. And not only was the customer happier about the increased performance, they were absolutely delighted by the lower cost of the plane, because parts that are not on the plane don't have to be designed, they don't have to be tooled, they don't have to be NC programmed, they don't have to be manufactured or assembled, anything.
They don't have to be stored, they don't have to be inventoried, they don't have to be controlled, and they don't have to be scrapped. And if you have fewer parts, they don't need to have spare parts for those extra parts as well. So that reduced maintenance and repair costs. Question?
AUDIENCE: Does the manufacture necessarily have to pass on the cost to the consumer [INAUDIBLE], because I imagine quite a bit of time and money goes into R and D to try to get the cost [INAUDIBLE].
ANNALISA WEIGEL: Yeah, so there certainly was a lot of engineering costs to redesign the plane. And there was an interesting arrangement between this company and the government. So there was some, if you would call it, cost-saving sharing or profit sharing that went on. So the company was incented and rewarded for keeping costs down. They didn't have to give all that savings back to the government. They didn't get to keep it all either. But they got to keep enough that it was an incentive for them to actually meet these objectives.
And at the time, this was somewhat of a radical way of thinking about government contracting as well. And that's not a trivial area to overlook. Because sometimes, those contracting and legal issues can keep you from doing what otherwise might seem very lean to you.
Let's look at another example of how lean engineering tools helps reduce the manufacturing label. So what I'm showing you here on the y-axis is account of manufacturing labor in terms of hours. And on the x-axis is the number of production units that we have. So right here is where the first physical production unit is made.
This blue line right here shows the labor hours per production unit before lean engineering processes and tools were applied. This curve down here shows the results after lean engineering processes were applied. And what happened was that nine units were actually built virtually before anything got to the manufacturing floor, such when they did get to the first physical unit that was produced, the total manufacturing hours to do that was significantly less than previously, before learning the lean tools. And in addition, the sort of steady-state manufacturing hours required for the same comparable kind of product was much lower, in the end, than using the non-lean processes.
This is another example of how better engineering tools help reduce some of the costs associated. So on the y-axis here, we have a staffing level. And on the x-axis here, we have months from the end of the conceptual design phase. And this just shows the results of the design and IPT labor that was required for vehicles of comparable sizes. And what you see is that, as we slowly introduced different kinds and better of lean engineering tools, we were able to reduce the staffing level and shrink the time that was required to accomplish that milestone.
And lastly, lean engineering enables faster delivery times. And particularly because spacecraft have such a slow reputation in the industry, I thought I'd show you a space example. This is Iridium, which is a satellite program. And where it's typical to have 12 to 18 months of cycle time in the satellite industry, this particular program accomplished a cycle time with 25 days, which was just literally unheard of. And they did it largely through the application of lean engineering and lean manufacturing practices to the program.
So just to wrap up, we talked in this module about lean engineering, and how lean engineering can enable lean manufacturing, and how working with the supply chain, all these three things can come together to create affordability of our products across the enterprise through the application of lean, by reducing costs per unit as we go down the assembly line.