Dear Gemba Coach,
My company already has a deep rooted lean culture. However, it would seem that the next evolution would be in my department, Research & Development. Do you have any suggestions on how to take lean tools from process improvements such as kaizen, 5S, etc. to new product development?
I believe you are absolutely correct in your intuition – I strongly believe that the full power of lean can be reached through the feedback loop between product development and production process, which means developing lean thinking both in R&D as well as manufacturing, and bringing the two together. However, as always, when looking at tools, the real question is: to what purpose?
The fundamental aim of lean, I feel, is satisfaction and growth: satisfaction of customers, satisfaction of employees, satisfaction of shareholders and society at large, and growth both of the company and the individuals within it. In that respect, I believe there are three overall aims to lean in new product development:
- Better products – products that better hit the sweet spot in the target segment, by better satisfying customers. This, in itself is never a given because, firstly it’s very hard to correctly identify what customers are really looking at in a product –- and it is usually quite different from what they say, or from what marketing thinks. Furthermore, value is a ratio of performance to price, so finding the right balance between customer benefits and production costs is never easy. My new Prius, for instance, is incredible because of the plug-in magic, so far superior to the previous one in terms of energy performance, but I can see many cost-cutting efforts that affect my interface in the car (plastics, ergonomics, etc.). So, I now have a science-fiction car as almost fully electric, which has a better engine, but that I don’t love the way I did the previous one (and so that I won’t defend as passionately). Such trade-offs are extremely difficult to master as the product is being developed and kaizen is essential to continuously learn about customer preferences.
- Better engineers – there is no question that better thinking leads to better products. Better engineers can also ultimately lead to fewer headcount per project as much of the fumbling disappears. Many companies, however, consider that competence can be hired or fired. A key part of applying lean tools to new product development depends on the deep assumption that developing towering expertise is a fundamental responsibility of the company – not just the person himself or herself. The question thus becomes, how do any of the lean tools develop engineers’ technical competence.
- Better processes – obviously the development process itself matters, and the aim of lean thinking in R&D is to reduce the development lead-time. However, one should be very, very wary of tackling this aim before having cleared the previous two, as many bad blunders can be made. I have seen many “lean in engineering” efforts aimed at reducing the development process lead-time (or worse, the engineering headcount) that have ended in disaster for the company. The lean strategy to reduce lead-time is to reduce rework: zero redesign. This, obviously, is incredibly hard to do and rests on better understanding the product upfront and then better cooperation between all involved during the development process. Several lean engineering tools have been specifically designed to address this issue and help engineers better see the consequences of their design decisions both on the product (the interface with other functionalities) and on downstream partners in production and at suppliers.
If we agree on the scope of lean thinking in new product development, let’s look at the question of how to apply process improvement tools to R&D. Getting started with lean in any area other than production can be something of a struggle because it’s hard to get a clear picture beforehand of the kind of issues you will need to attack. A long tradition of lean in production and many years of various experiment (with varying degree of luck), makes it easier to get started.
For instance, 5S in production can’t hurt. It might not deliver what you expected if not linked to standardized work, but it’s as good as any place to start. Conversely 5S in engineering doesn’t make any sense, at least to start with – it will, in all likelihood, get everyone’s back up with little gain. What problem are you trying to solve? That all pencils are in their proper place? Shall we draw a line on the desk for the pencil place? Worse, once you’ve pushed 5S in engineering (and management is very good at pushing silly ideas on the working stiffs), you’ve also burned the first cartridge of change, and doing the next step will be hard, hard, hard. (This is not to say, when we grow up, that some policing of files in the IT system is not helpful, but that’s stretching the idea of 5S rather far).
A Lean Vision of Engineering
After years of trial and error, here’s how I see lean programs in unfamiliar environments. We’re looking at four components:
- A gemba program of “go and see”
- Pull flow to give an architecture to progress
- A dojo program of on-the-job training by the supervisor
- A kaizen program of workshops to get people across functions working together
The lean vision of engineering hinges around the notion of “chief engineer” – one person designs the product much like a fashion designer designs a clothes collection. The chief engineer is more than just a project manager – he or she is the main architect of the product, and the person with final say in all technical debates (In the literature, originally defined as “heavy-weight” project manager – check out Chapter 9 in Product Development Performance by Clark and Fujimoto).
In lean engineering, executive management makes two critical choices: (1) the customer segment the product aims to touch and (2) the chief engineer who will design the product and get it to the market. The chief engineer has no authority over other engineers – these continue to report to their functional bosses – but still has the responsibility for the success or failure of the product (the chief engineer is not without influence – imagine what it does to a career if the chief engineers wants you or, on the contrary, refuses to work with you). Chief engineers are tasked to translate customer preferences into technical parameters. They usually design the product’s architectures, and are also responsible for establishing both the project’s milestones and how they intend to manage these milestones.
Go See
The first task of the chief engineer is genchi gembutsu: going to the gemba to see for oneself. Genchi genbutsu in engineering means first understand customers usages and conditions of use. Customers do the weirdest things with products, mostly because they don’t particularly care for the product other than it helps them do something they want to do. In Clayton Christensen’s terms, customers rent the product to get something done. This must really be understood. Genchi Genbutsu, for instance, will let the chief engineer realize that many people who drive pick-up trucks work outside and wear gloves in the winter, so all knobs should be large enough to be handled without taking gloves off.
Genchi genbutsu is not limited to customers: chief engineers also visit plants, to see for themselves real production conditions, and suppliers, to see what innovation could be used for their product (as well as get a feel for how tested and secure such innovations are). Many trade-offs occur at the gemba in terms, for instance, of feel of materials versus cost, or astuteness of some specific solutions. The first program to set up in order to bring lean thinking to your new product development is a gemba program, where you schedule visits to customers, manufacturing sites and suppliers not to put out burning fires, but just to understand what is possible, difficult but hopeful and downright impossible in terms of design possibilities.
Pull flow in engineering is nothing else than establishing a rhythm of new products and sticking to it ruthlessly.
