INTERVIEW - Jim Morgan looks back at his years at Ford Motor Company and talks about the challenges of applying lean management ideas to new product development .
Interviewee: Jim Morgan, Senior Advisor, Lean Enterprise Institute
Roberto Priolo: In a recent presentation, you said that product development contributed to the evolution of the Toyota Production System. Can you tell us how?
Jim Morgan: I think the role of product/process development in shaping TPS is often overlooked. There is a product and customer focus that brings design, engineering and manufacturing together and creates a powerful alignment. It starts with standard product architectures that power their platform strategy and enables incredible global manufacturing flexibility. Designing and engineering products to standard manufacturing process requirements while simultaneously improving critical product attributes is also key. This ability to create a powerful system of continuously improving standards built on individual and organizational learning, and a deep understanding of their customer and the unique value potential of their product is very powerful. An important driver of Toyota’s ability to do this is a “go to the gemba” way of working. The engineers go to the plants, the dealerships, the environments in which their products are used – they deeply understand every aspect of their products and their customers. And they front load all of this knowledge into the product development process where they have the most leverage. Complexity reduction is another important contribution to TPS from product/process development. Using common parts across product lines without reducing product quality is central to effective lean manufacturing. This is much more than just part counts. It requires a deep understanding of the product and the manufacturing process – and then integrating and applying that knowledge. And finally, there is the quality of their launches. New product launches at Toyota are generally much smoother than at their competitors’. Standard architecture and standard processes play a powerful role here, as does the company’s very rigorous manufacturing readiness sign-off that is built into the development process. But it also has a lot to do with the pilot teams that are fully engaged in the product process development. They are a strong voice for manufacturing throughout the process. Then those same people return to their plants to support and lead the launch process with their colleagues. They go back with a deep appreciation for their customer, an understanding of critical product attributes and of which aspects of the manufacturing process are crucial for delivering those attributes. They become advocates for the customer and the product in the plant. Then all the learning from this program, all this knowledge will be applied to the next program. Very powerful.
RP: Let’s move to Ford now, and think about the culture that led to the development of the Model T, among other things. It was a reliable and cheap product that responded perfectly to the voice of the customer. Do you think that part of that way of thinking was still permeating Ford’s culture when the organization was trying to revolutionize its product development function?
JM: There is no doubt Ford has a strong culture. Henry Ford was in some ways the original “go to the gemba” product engineer. He was responsible for tremendous innovation at the gemba in both product and manufacturing processes. And he was absolutely relentless in his improvement of both. What he accomplished is incredible. Over time, however, I think it is easy to get lost and forget the principles that made the company great. At some point leadership got off track and started to focus excessively on serving stakeholders rather than customers. They lost their product focus. Many people in the company knew that the path we were on was not great. The new Ford under Alan Mulally, as well as organizations like Toyota or Apple, have proved that if you focus on making great the products and everything it takes to do that instead, the results will come. For a while we had it backwards. Ford always had fantastic people. It was leadership that made all the difference.
RP: The PD function at Ford is of course very different around the world – how can you standardize it while allowing for local flexibility?
JM: We tried to focus on three things when it comes to standardization: a standard process, so that we are all working to the same logic and event criteria; a standard set of skills and capabilities for all our engineers, with our TMM, Technical Maturity Model, so that we have alignment on expectations for our engineers around the world; and architectural standards, identifying what attributes of the design were critical to product performance, manufacturing, etc. This of course includes standard manufacturing processes. But at the same time we had to be able to customize our products to specific, regional markets. Customer preferences and expectations as well as regulatory requirements are often different. This was key and understanding what aspects of the product needed to be fixed and which were flexible took a great deal of work. It was very important to get this right and I think we made good progress. We realized there are things that are fixed and we can never sacrifice; others we made more market-specific. We put a lot of effort into developing our engineering organizations in all regions. It is crucial to get input from regional engineers who truly understand their market and it is equally important to have engineering skills sets and capability that we could rely on to deliver Ford’s quality expectations. This was a major effort and paid big dividends for us.
RP: What is the most difficult part of the job of a Chief Engineer?
JM: It’s a big job. You are asking one individual to be responsible for the success of complex products like the Fusion, the Corolla or the Escape, worldwide, and they have to work across functions without a lot of formal authority. It takes a certain kind of individual to do it. Even if they have the innate skills, it takes time and conscious effort to develop them. This should be an organizational priority, especially among senior leadership.
RP: How do you involve the customer in product development to ensure that what you are designing matches their needs?
JM: The process is slightly different for the chief engineer and program team than it is for the engineering functions. If I use the example of our Mustang chief engineer, he is totally immersed in his product and its environment. This is crucial. Products are contextual. The CE must understand the unique value proposition of their product better than anyone else. In the case of our Mustang CE, there isn’t a Mustang event he doesn’t go to; there isn’t a cars magazine he doesn’t read; he drives a Mustang; he understands competitors; he networks; he immerses himself in the lifestyle; and gets data from dealerships, from quality field data etc. He also has a tremendous technical understanding of the product. The real challenge is taking this monstrous amount of data and coming up with a single vision for what that product needs to be and interpret that in engineering standards – what does that mean in terms of chassis, for example? It takes an exceptional individual to do something like that. On the functional side, our job is to understand, within our discipline what the state of the art is, what the critical trade-offs are, what our suppliers are doing (their technologies and capabilities), what our competitors are doing and analyze tall vehicles in this class part by part to understand what engineering fundamentals enable a particular attribute performance. Then, when I sit with the chief engineer for the program we can have a very productive conversation. And this needs to happen very early in the program, where we can make a difference.
RP: Why do people struggle to see product development as a proper process?
JM: I think too often companies tend to have engineers working in individual cubes. They are all isolated. They often don’t see themselves as part of a larger process with a complex web of interdependencies. It is a very different, less visible environment than manufacturing. It can be very difficult “to see”. Value stream mapping can help you to learn to see in the PD environment.
RP: How does “traditional” lean product development relate to the principles of the lean startup?
JM: That’s an interesting question – I have never thought of lean product/process development as “traditional”. I have read Eric Ries’s book but am certainly not an expert in lean startup. What I understand is that lean startup is primarily for environments of great uncertainty and largely used in software development. My work on the other hand has primarily been with large, complex products in industries like automotive, aerospace, heavy equipment, etc. However, I do see some common ground. Customer-focused innovation, going to the gemba to deeply understand customers, and a validated learning focus are all central to lean product/process development. It is part of the “Study Phase” of lean product/process development and the immersion methodology to deeply understand your product’s full value potential. I also think that “minimum viable product” in the lean startup is a bit like minimum feasible maturity of data that is so key to understanding cross-functional interdependencies and creating flow in a lean product development process. While you can’t send “buggy” incomplete products to customers in the automotive industry, you can think in terms of internal customers and the data you exchange with them. It’s all about the maturity of data as you hand it off to the next internal customer. Exchanging information early and often definitely has an application in lean product development. I am happy to see the popularity of the lean startup initiative. I think that it will help bring a stronger focus on product, which sometimes gets lost in the lean community. I believe that product focus, however you define your product, will make organizations much stronger. And I think that the principles, methods and tools of lean product/process development will be central to this growth and to creating a truly lean enterprise. To this end I have agreed to work with the Lean Enterprise Institute in the US and with the Lean Global Network as a senior advisor to help advance our knowledge of lean product/process development and work with a select group of companies to bring this knowledge to the gemba, where it belongs.