Fields marked with a * are required


Where Lean Product Development Goes Wrong

Surprising how time flies by isn’t it. Here we are, now in March of 2011 and I’m thinking to myself “how did that happen?” Feeling the need to catch up, I called a friend of mine here in Austin and went to grab a drink. We spent a while catching up but soon enough, our conversation steered towards shop-talk. See, he’s an been deploying lean, six sigma and other similar initiatives for years. And what he said surprised me a bit.

Engineering is Unmistakably Different

Interestingly enough, one we started talking about work, the age-old mantra of metric-based initiatives came out: “what isn’t measured isn’t achieved.” My friend expounded on on the benefits of having those metrics as the foundation of any decisions you make in the initiative. It’s how you measure improvement. But having recently worked on an initiative to apply lean to product development, he readily admitted there are deep-seated faults in the approach. For a guy that’s now an executive who built his career on putting ‘measuring and improving’ aspects into almost every initiative he has ever run, it was a profound moment when he admitted “for engineering, you can’t use measurements because you don’t necessarily know where you’re going to go.” He went on to say “it’s a lot more like gathering and hoarding knowledge upon which you make decisions. How do you measure that?”

Lessons Learned from 3M

Walking away from that night, aside from catching up with a good friend, I couldn’t help but turn some of those points in my head again and again. I knew I had heard something similar before. And finally a few days later it hit me. Back in 2007, Businessweek published an article in their magazine called At 3M, A Struggle Between Efficiency and Creativity. It took me a little while to track it down. But below, in my opinion, is the most poignant point in the whole piece.

Indeed, the very factors that make Six Sigma effective in one context can make it ineffective in another. Traditionally, it uses rigorous statistical analysis to produce unambiguous data that help produce better quality, lower costs, and more efficiency. That all sounds great when you know what outcomes you’d like to control. But what about when there are few facts to go on—or you don’t even know the nature of the problem you’re trying to define? “New things look very bad on this scale,” says MITSloan School of Management professor Eric von Hippel, who has worked with 3M on innovation projects that he says “took a backseat” once Six Sigma settled in. “The more you hardwire a company on total quality management, [the more] it is going to hurt breakthrough innovation,” adds Vijay Govindarajan, a management professor at Dartmouth’s Tuck School of Business. “The mindset that is needed, the capabilities that are needed, the metrics that are needed, the whole culture that is needed for discontinuous innovation, are fundamentally different.”

Now in this specific case, the article is citing initiatives like six sigma and the like. However I’ve seen Lean Product Development initiatives that have gone metric crazy. And to me, that’s the exact wrong thing to do. I can understand the logic and desire to measure, benchmark and improve processes. But it actually fundamentally goes against the engineering process which is to iterate, learn something, trying something else, learn something and so on. To put arbitrary measures in place to accelerate that process could easily result in the wrong engineering decisions.

Conclusions and Summary

Believe me, I do believe there are some benefits to a Lean Product Development initiative. However, one must be very careful to educate executives on the fact that it applies very differently to engineering as compared to other organizations and processes. In those other departments, it’s often about taking costs out and accelerating processes. Taking that approach in engineering could prove disastrous as you’re forcing engineers forward without gaining knowledge to have confidence in their decisions.

Time to weigh in. What sort of metric-based initiatives have you seen in your engineering organizations? What positives or negatives have you seen as a result? Sound off and let us hear some facts from the front lines.

Take care. Talk soon. And thanks for reading.

Chad Jackson is an Industry Analyst at Lifecycle Insights and publisher of the engineering-matters blog. With more than 15 years of industry experience, Chad covers career, managerial and technology topics in engineering. For more details, visit his profile.

Like this post?

Sign up now to get more like it

Fields marked with a * are required


  • Lean design practices often sacrifice the development of core competence, at the benefit of lower cost development. It can work out well in a job shop, bearing in mind that off the project hours need to be set aside for internal development. Within a dedicated engineering dept, selling internal development can be incredibly difficult, especially when one considers lost opportunity costs. Rather, its common practice to bring in outside experts, shift responsibility to vendors, and/or outsourcing parts of projects, as such practices often have easy to measure criteria and are low risk short in the short term…

    • Ron, thanks for contributing on this topic. I think you have some valid points. Ultimately I think many organizations end up having a big mix of the approaches you mentioned. The question becomes how to find the right balance between them all.

  • Anonymous

    What’s measured matters, for sure. What we measure depends on our hypotheses – for example, measuring PD goodness as cycle time says things about our mental model of causality in PD. Another complication: mental models about Lean PD may vary more widely than warrants using the term as though we share one.

    As a WWTD (what would Toyota do) sort of PD guy for several decades, some of that time in the salt mines of six sigma, I’d have to agree that much of what constitutes six sigma (another term of uncertain utility due to substantial mental model variance) will have limited applicability in the *design* of products, production systems, and supply webs. Six sigma works better when we can see, touch, and measure widgets and it’s relatively safe to send everyone out for a pass instead of improving in a systematic way. On the other hand, making design work visible is hard work itself and products, production systems, and supply webs interact mercilessly: few good local fixes exist.

    So, what is to be done? First, some better mental models! We default pretty preconsciously to thinking of time lines, milestones, stages/gates, CAD models, simulations, presentations, tests, prototypes, contracts, stuff like that. What would better conceptualize what goes on in development? What flows through development? What arrests flow? How can we watch what flows in as near to realtime as possible? What are the time-domain dynamics of those flows? What are better strategies, tactics, practices, and culture for better resolving wicked design interactions?

    Just asking.

    • Jeff, good points about mental models. The phrase LPD probably means something different to everyone. And that could definitely be a problem.

      I agree some better mental models are needed. And I think there’s some interesting concepts being developed by some innovative engineering organizations. But by and large it’s been pretty stagnant for a while. I’m unsure how to ‘get the ball rolling’ with respect to that again.

  • Pingback: Kenesto: A New Take on PLM | engineering-matters()

  • Pingback:

  • Pingback: sepatu futsal nike()

  • Pingback: read more()

  • Pingback:

  • Pingback: hotmail()

  • Pingback: encuentra mas info()

  • Pingback: poemas()

  • Pingback: cloud hosting()

  • Pingback: referencia()

  • Pingback: que es un sistema operativo()

  • Pingback: saludbelleza()

  • Pingback: Kenesto: A New Take on PLM - Lifecycle Insights()

  • Pingback: Kenesto: A New Take on PLM » Lifecycle Insights()