Toyota Product Development System

1
3

Industry Week Article

Here's a list of 13 principles from the Toyota Product Development System, as explained in the book The Toyota Product Development System: Integrating People, Process And Technology by Jeff Liker and James Morgan.

Is anyone working to apply this system at their company?


What do you think? Please scroll down (or click) to post a comment. Or please share the post with your thoughts on LinkedIn – and follow me or connect with me there.

Did you like this post? Make sure you don't miss a post or podcast — Subscribe to get notified about posts via email daily or weekly.


Check out my latest book, The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation:

Get New Posts Sent To You

Select list(s):
Previous articleA Tax On Bad Management
Next article"The Vicissitudes of Over-production"
Mark Graban
Mark Graban is an internationally-recognized consultant, author, and professional speaker, and podcaster with experience in healthcare, manufacturing, and startups. Mark's new book is The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation. He is also the author of Measures of Success: React Less, Lead Better, Improve More, the Shingo Award-winning books Lean Hospitals and Healthcare Kaizen, and the anthology Practicing Lean. Mark is also a Senior Advisor to the technology company KaiNexus.

3 COMMENTS

  1. I’m certainly curious to learn more about it. Lean product development is getting some traction in software development: the ‘agile programming’ community has been growing for the last ten years or so, and recently Mary and Tom Poppendieck have been pointing out to us how much agile programming ideas are like lean product development ideas, and pointing out areas in which we can learn more from lean. I haven’t yet read Liker and Morgan’s book (I’ve just read the Poppendiecks’ books and Michael Kennedy’s book on the subject), but I’ll find time soon.

    I’m especially curious since I work for a company that does hardware design as well as software; lean might be a way for me to apply some of what I’ve learned to other areas of the company.

  2. David,

    I really think you are on to something and hope to hear about your progress!

    Whenever there is a product or service there is a value stream. And whenever there is a value stream Lean is waiting to help.

    Good luck,
    Ron

  3. We implemented a form (I call it a form because it wasn’t the exact way) of this at a previous Company. The Engineering processes we looked at were initially Software Development, then we expanded to Hardware Design, etc. The Chief engineer and I came up a with the way, when we mixed what I knew about LEAN & what he knew about rapid prototyping. We figured out the thing we were missing was how we capture & maintain the different “modules” lessons learned & design CTQ’s. Long story short, we took an historical 18-30 months SW cycle down to less than 4 months, with a concept to monetized design (customer purchasing new units) from 3-5 years down to roughly 12-13 months. Using this. As with most things at this former company, I was forced to move on because I was not leadership material, he was eventually pushed into another area because several others ‘ladder climbers’ stole his thunder & received the credit for the work. What is interesting is that now that we are out of it, the new products are reverting back to the old processes.

    So yes, it does work and can work in a very short period of time (we began in April/May of 2005, with noticeable improvement by November/December 2005 results. These tracked all through 2006.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.