What is Lean Product and Process Development (LPPD) and how does it help create high-functioning teams? The following short comments from LPPD experts all share key insights into the value of this set of ideas. LEI’s Josh Howell recently spoke with Jeff Liker, Jim Morgan, Jim Womack, and Eric Ethington on this topic; you can watch a video capturing this conversation here.
************************************************
Jim Morgan: Let’s talk about what LPPD is. In my view it’s a set of principles and practices that we first identified at Toyota and have since evolved in a number of different industries that promote collaboration, transparency, and rapid learning, in the development of both process and product simultaneously, leading to the creation of really effective value streams. And when you think about that and you think about where product development is in an organization, your degrees of freedom for designing that value-stream, or really designing your future state, is much greater than it is in any other activity that takes place in organizations. And when you add the fact that product development when done well engages just about every function in the organization, from not only engineering and marketing which are obvious, but also manufacturing and supply chain and finance, it’s really an opportunity to bring the organization together to sort of design their future, hence the name of the conference. And the decisions that you make during that time period are going to affect the organization for many years to come so it’s a really crucial opportunity
Jim Womack: Well, that was stating the positive. Let me state the opposite, which is that if you do LPPD right, you avoid “If you do LPPD right, you avoid what most organizations do most of the time post-launch of a product, which is go immediately into rework mode.”what most organizations do most of the time post-launch of a product, which is go immediately into rework mode.So, if you have not designed the production process properly ahead of time, we know we’re going to be doing rework. And an awful lot of the kaizen that has taken place in the lean community is in fact reworking a defective process that never should have been created that way to begin with. So, if through LPPD you get process right, well then production can actually work. Now of course then you go into kaizen to actually improve it beyond what was envisioned; but instead, most of what we do is rework to get back to where we should have been to begin with. Same thing with suppliers. You’ve got misaligned suppliers. The handoffs are not properly understood, and so now you go into rework mode when it turns out suppliers can’t keep up or are doing the wrong thing, which shouldn’t be necessary. What supplier development should be about is actually developing a good process to be a better process.Same thing with marketing and sales. If you get it wrong in terms of what the customer wants and you launch the product, well then you’re immediately into rework known as discounting or all kinds of tricks in the car industry, and promotions and so forth which are actually avoidable if you actually listened to the customer; and then through LPPD translated that into what the customer actually wanted. So that’s the negative. Let’s avoid rework. Jim’s already given the positive. You put those two together and you’ve got some great reasons to do LPPD.
“When you get engineers together, like when we’ve used Value Stream Mapping to visualize their process in a graphical way, and particularly when done cross-functionally so that people start to understand problems that they’ve created for others and others have caused for them; they seem to almost immediately get excited.”Jeff Liker: One of the obvious differences in the factory is that you can touch, smell, taste–the physical process is real, so normally engineers are thinking about design—you have control of the physical world. And there’s a lot of physical elements in manufacturing that you move around, change, color-code and all that. Whereas in product development it’s all in people’s heads: communicating through verbs, words or equations. So the engineers are thinking, “what are you going to do? Move us closer together? You’re not going to change the language of engineering. I’m an expert on engineering. I’ve been studying this my whole life and I already know it. You’re not going to teach me how to become a better engineer.” And, if there was something important most engineers think they can learn it from a book or computer.
So the idea of learning something new by having consultants come in and somehow change the way they work doesn’t seem real appealing. But when you get engineers together, like when we’ve used Value Stream Mapping to visualize their process in a graphical way, and particularly when done cross-functionally so that people start to understand problems that they’ve created for others and others have caused for them; they seem to almost immediately get excited. And when they are value stream mapping or collaborating in an obeya (a meeting room where they populate the walls with information about how they’re doing compared to their targets and they meet regularly to check up); once they get started with these types of activities, they don’t complain anymore that this is a manufacturing thing. That accusation doesn’t even come up anymore. It only comes up in the theoretical stage when you’re trying to explain this work intellectually. So we try to get them doing something as quickly as possible and that helps everyone see how to solve the problem.
And the leadership is very important so we talk about the chief engineer role—an overall system architect. This can be a very important intervention. And having a strong cross-functional team that meets regularly and stays together is very important. So we’ve come to conclusion that basically what you’re doing is creating a high performing team. In manufacturing the machines, equipment, process is more central. The equivalent in engineering is the team—the people are the machines—and getting them to work more effectively. Then there’s various tools like visual management so they can visualize process and assess where they are compared to where they’d like to be. And then there’s basic things like GTS (Grasp the Situation). In manufacturing, for engineers the gemba is where the customers are. So we try to get them to go to the gemba and talk to the customers and understand how they use the product and not depend on marketing to translate what they think customers want. So this is very much a human process, and at the center is what we call a high-performing team.
