1
Lean Product Development Practices – Applying Lean Principals and Project
Management Tools to New Product Commercialization
Christopher HallerDevelopment/Commercialization Program and Portfolio Management
2
Agenda
A. Goal of Presentation B. Presenter Background C. Traditional Product Development – Guild Method or “All
Hands on Deck” Style D. Lean Product Development E. Knowledge Based Set Design in Action (Examples) F. Conclusions / Recommendations
3
A. Goal of Presentation
Discuss the general concept and benefits of Lean Product Development (LPD) focusing on four areas:
Principals of Design System Thinking Knowledge Sharing Cross functional teams
Discuss how Project Management Techniques and Lean Product Development can be used together
Provide examples in multiple industries around lean product development
Show how LPD can be applied to defining long term product development roadmaps/product portfolios
4
B. Presenter Background
Sat on initial teams that assembled the stage/gate processes for both research & development and product commercialization in
Ran several pilot programs for stage/gate R&D Became a primary Program/Project Manager Portfolio Manager assembling Product/Technology
Roadmaps Six Sigma Black Belt and PMP certified
5
C. Classic Product Development/Commercialization
Point based design – single solution focused Loop backs (rework) very prevalent Resources and budget typically grows as project
progresses and moves to large (manufacturing) scale Teams become cross functional as development process
matures Technology introduction and selection often driven by
schedule – not driven by data/knowledge Often programs are large in scale – time to market
long, cost is high and much DIP (Design in Process) Knowledge is not shared or reused effectively
6
C. Classic Product Development/CommercializationGuild Method
Old Time Inventor Style – single individual or group focused
Focused on functional style management Product segments developed in silos and thrown over the
fence:
Development time long, much waste during the process due to poor communication between product development chain, customer doesn’t always get what they want….
Most common style at small companies, success very dependent on having right people at each juncture of the process
7
C. Classic Product Development/Commercialization“All Hands on Deck” NPD Style
“All hands on deck approach” – ala the program to land a man on the Moon by the end of the 1960s – either a crisis stopgap or “the BIG named program”
Larger companies -> assign the majority of the technical and business resources to a key program
Focused on a Projectized Organizational structure but usually without a strong PMO focus (many times co-run by technical or business leaders)
Technical leader and technologist often minimize importance of PM and often PM relegated to schedules and action item lists
Development time is short, development cost and waste is high in order to meet a short timeline
Many times these projects get out of control if not well managed (scope and budget creep)…
8
D. Lean Product Development
Origins of Lean Product Development Much of Lean Product Development born out of the US Air
Force fighter/bomber development process used in World War 2 (this methodology allowed us to play catch-up to a technologically superior enemy)
Toyota and other Japanese manufacturers given the “manual” during the rebuilding of Japan in the late 40’s and 50’s
Japanese companies realized that they couldn’t compete with huge assembly line manufacturers using the classic guild style methodologies for either manufacturing or product development
Japanese borrowed many ideas that were part of the US Air Force process and honed them to bring us to where “lean product development” is today
9
D. Lean Product Development
Lean Manufacturing: Inventory reduction Increased productivity Reduction in scrap and rework Reduce lead time from order entry to delivery of product from weeks to
days Reduce changeover from hours to minutes Build to Order vs. Build Forecast
Lean Product Development: Reduced DIP (Development in Progress) Increased productivity & leveraging of knowledge Reduced loops backs and false starts Reduced development cycle time Increase flexibility to navigate changing marketplace Products that meet customer expectations at maximum value
to company
10
D. Lean Product Development – Tangible Benefits
Market Research: Development Cycle Times reduced by 30% 1
Resource utilization improved by 70% 1
New product performance measures improved by 33% 1
Product Quality improved by testing early in development cycle by 38% 2
Market share increased from 6% to 25% in one year 2
Toyota Prius – development cycle time reduced by 38% 3
Kodak Film Development example: Reduced development cycle time by 50% Improved physical properties over 10x in a 3 year time period Maintained a payback of 4x development cost over life of development
(>100 M$ over a 10 year period) Reduced variability in multiple areas over the life of the product
1 Shooting the Rapids: Managing Product Devleopment in Turbulent Environments, MarcoIansiti, California Management Review Fall 19952 Product Development Practices that Work: How Internet Companies Build Software, AlanMacCormack, MIT Sloan Management Review Winter 20013 “The Toyota Way,” Jeffrey K Liker [Tata McGraw Hill, 2004]
11
D. Lean Product Development
Lean Manufacturing:
1 Going Lean Stephen A. Ruffa (AMACOM 2008)
2 http://leanmanufacturingtools.org/wp-content/uploads/2012/02/house-of-lean1.jpg
12
D. Lean Product Development
Lean Product Development:
Set Based Flexible Design
Integration Focused Leadership
Dynamic Cross Functional Teams
Knowledge Sharing/ Continuous Learning Process
Essentially equivalent toflow -> fewer projects ata time but load leveledR&D (work is notback end loaded) – alsoprojects have reducedcycle time & DIP
Traditional Product Development – back end loaded
Lean Product Development – Load Level Flow
13
D. Lean Product Development – Target Examples
Automotive – Toyota Prius 10
Automotive – Harley Davidson 8
Pharmaceutical – Ely Lilly Chorus unit 1
Software – Microsoft Internet Explorer 3.0 6
Computer Hardware – NEC SX-2 Project 7
Computer Hardware – SGI Challenge Project 7
Photographic Materials – EK Abrasion Improvement Project
Photographic Materials – EK Technical Roadmap Development
14
D. Lean Product Development – Set Based Flexible Design Use of multiple options throughout the research/development
process to arrive at the optimum answer or series of answers Options are arrived at through brainstorming and “try-storming” Options are assessed and eliminated based on
data/observations Attempt to drive options to fast failure to define tradeoff curves Options are not only assessed in a controlled experimentation
mode but also in integrating or benchmark experiments/events Multiple options may even be carried through part of
commercialization Set based design should avoid loop backs late in the design
process or during costly parts of commercialization
15
D. Lean Product Development – Set Based Design Examples
[NEC] Many concept possibilities discussed and modeled, most promising were investigated at the bench scale. Close to the project end, one technical option was chosen and the design was “frozen” at this point
[NEC] & [SGI] Use a flexible model of product development where many options are explored and carried through process – this fluid design process allows to react to changing specifications and “surprises” throughout the development process
[Toyota] Design groups develop sets of solutions in parallel and gradually narrow these sets based on additional information and experiments. By focusing on convergence of the options rather than tweaking one solution – Toyota reduces back tracking in the process.
[Toyota] In order to maintain flexibility, design groups converge to a final solution as close to market introduction as possible.
[Microsoft] Uses an evolutionary approach to design that is flexible and has an architecture that is modular and scale-able.
[Eli Lilly] Chorus uses experiments to drive to fast failure to reduce the field of options and also vet other options efficiently
16
D. Lean Product Development – Integration/System Design Leadership
Team leadership is driven from a system viewpoint – not at an individual technology viewpoint
Flexible development requires joint evolution of the system (concept & requirements) and technology/detailed design
Use of periodic integration or convergence events to examine both individual and system performance
Team leader must facilitate integration approach along with monitoring customer/sponsor requirements, marketplace conditions and schedule
Integration events are key for the technology selection process and moving the project forward. Management reviews (gates) will usually follow successful integration events
Phase/Gate system can still be used but gate reviews are more informational in nature (schedule is driven by integration events)
Leadership style is dynamic and focused on knowledge based approach
17
D. Lean Product Development – Integration/Convergence
The Lean Machine, Dantar P. Oosterwal (AMACOM 2010)
18
D. Lean Product Development – Integration/System Design Examples
[NEC/SGI] Shows a strong focus on exploring interactions between concept decisions and design details. The interactions are explored through prototype cycles (integration events).
[NEC] The integration group was formed with a responsibility to lead both concept development and implementation over several project generations
[SGI] Simulations and early prototypes help uncover problems before committing to expensive complete and representative prototypes
[Toyota] Chief engineers perform vital systems integration activities by controlling the narrowing process, insisting on broad exploration and resolving disagreements across functions.
[Toyota] Emphasis on nemawashi – finding the best solutions for the entire system – locates a solution at the intersection of the feasible regions for the individual technologies
[Microsoft] Attempts to get a low-functionality version of the product (i.e. integrated prototype) into customer’s hands at the earliest opportunity
19
D. Lean Product Development – Dynamic Cross Functional Teams
Project teams need to be cross functional at the start of a project
Sponsors and project leader should examine team membership and define appropriate members – representatives should range from research & development, manufacturing, supply chain, engineering, finance, quality and especially customers (internal/external)
Cross functional teams at the start of a project will lead to better option generation, diverse thinking, concurrent engineering and better team atmosphere
Resource loading should be somewhat level during the life of a project – not going up exponentially at the end to address loop backs late in process
Resource commitments will be dynamic – all functions will have different time commitments depending on the stage of the project
20
D. Lean Product Development – Dynamic Cross Functional Teams Examples
[NEC] Early research done in laboratory and then customers brought in to help with specifications. Members of research and the technology integration were then brought in with knowledge of manufacturing, system design and past technical approaches. Substantial resources are dedicated before the concept is frozen.
[SGI] Critical decisions are made by a “core” Business Team representing wide variety of expertise from research, engineering, manufacturing, marketing, quality etc…
[SGI] Relies on lead customers to test products and partners with universities and research institutions for sampling the latest trends
[Toyota] The review committee makes final technology decisions based on engineering, marketing, manufacturing and other feedback
[Microsoft] Teams have broad-based experience of shipping multiple projects. Also an architecture was used where separate component teams fed into the product development
[Microsoft] Customers have a chance to influence the design at a time that the development team had the flexibility to respond.
[Eli Lilly] Chorus taps into a network of external experts and vendors for both information and evaluations the team cannot perform
21
D. Lean Product Development – Knowledge Sharing/ Continuous Learning Process
"The essence of knowledge is, having it, to apply it (use and share it); not having it, to confess your ignorance." Confucius
Ineffective sharing or loss of knowledge is the key driver of having to rediscover knowledge (waste), loop backs (more waste), design shortfalls etc…
Knowledge sharing both within the team and outside of the team is key to reducing cycle time for new products
Documentation and sharing of knowledge enables reuse of knowledge effectively in both current and future projects
Documentation can be as simple as using a quick A3 with trade off curves, or documenting and collaborating with Google Drive and Dropbox or more elaborate tools like Asana, Sharepoint and Yammer. Regular exchange of learnings between teams is also a key output.
Team leaders must make knowledge sharing and transfer a priority
Essentially projects should be viewed as a continual learning and improvement process
22
D. Lean Product Development – Knowledge Based Development
Product Development in the Lean Enterprise, Michael N. Kennedy (Oakley Press 2003)
23
D. Lean Product Development – Knowledge Sharing/ Continuous Learning Process
[NEC] Emphasis on discovering and capturing knowledge about interactions between technical possibilities and the concept before committing to a concept
[NEC] By keeping integration groups involved with several product generations, group members were able to effectively utilize the knowledge base to direct future products
[SGI] As a project progresses, the source code (specification) is shared by all members of the team facilitating communication and integrating individual efforts.
[Toyota] Uses trade off curves and design matrices (Pugh analysis) to communicate feasible regions of design space and criteria around concept selection
[Microsoft] Use of “daily builds” of software to check in new code providing rapid feedback and knowledge transfer to the team.
[Eli Lilly] As data flows from the experiments, the team modifies the experimental plans constantly to drive the experimentation as efficiently as possible
24
E. Lean Product Development – Product Design Examples
Film Development Program Example Program was focused to address an issue in the trade (premature failure of
product) Creatively adapted stage/gate process to drive towards a set based design
with a series of product introductions to improve issue Used brainstorming sessions early in the development phase to identify many
technology approaches that covered film design, customer processes and end use projectors. Used six sigma design principals to optimize technologies
Utilized benchmarking events to assemble technologies and send samples for aggressive testing and customer evaluations
Effectively used a consistent cross functional team containing R&D, product development, manufacturing, customer reps, systems over the life of the project
Held several workshops, weekly team meeting w/extensive online notes, multiple gate reviews, several patents/reports to facilitate communication
Through a series of commercialization programs introduced 3 products silently over a three year period that dramatically improved issue (improvedperformance over 10x) and silenced all customer complaints
25
E. Knowledge Based Set Design in Action
Development Programs – Pugh Analysis
Program 1
Program 2
Program 3
26
E. Lean Product Development – Product Design Examples
Development Programs
27
E. Lean Product Development – Product Design Examples
Development Technical Roadmap/Portfolio Definition Used lean development approach to generate and execute technical
roadmaps for cost reduction programs since 2004 Assembled a large cross functional group comprising of R&D, product
development, manufacturing, supply chain, purchasing, customer reps and systems to annually brainstorm and define sets of technical options and programs. The team planned work to drive towards development and commercialization of these technical options. This team continued to work on the projects through development & commercialization
Utilized benchmarking events regularly to assemble technologies and verify technical roadmap directions and schedule. Drove to fast failure with early production scale coatings and customer assessments. Maintained a flexible development/concept approach to maintain a steady stream of cost reduction projects
Held regular workshops, weekly team meetings and many gate reviews, communicated with notes, patents/TRs – roadmaps and direction regularly reviewed/updated with team
Through a series of programs and smaller projects introduced over 10 products changes silently over a eight year period that saved the company 3 M$ on a yearly basis but over the lifetime of the product line is around 100 M$ -> payback of 4X versus development cost.
28
E. Knowledge Based Set Design in Action
Film Technical Roadmap Definition – Roadmap 2007
29
E. Knowledge Based Set Design in Action
Technical Portfolio Analysis
Option Cost
Savings Timing Risk (Int)Risk (Ext Customer Resources
Proposed Introduction Cum Risk
Value w t - risk,res,time
(Months)Technology 1 174 2 1 1 1 Program 7 1 174Technology 2 45 4 1 2 1 Program 7 1.333333 34Technology 3 50 2 1 1 1 Program 8 1 50Technology 4 207 2 1 1 1 Program 8 1 207Technology 5 100 4 1 1 1 Program 8 1 100Technology 6 150 6 2 1 2 Program 8 1.666667 90Technology 7 853 0 1 1 1 Program 8 1 853Technology 8 138 3 1 1 1 Program 9 1 138Technology 9 891 6 1 1 2 Program 9 1.333333 669Technology 10 0 6 2 1 2 Program 9 1.666667 0Technology 11 3119 9 2 2 3 Program 9 2.333333 1003Technology 12 1680 6 1 1 2 Program 9 1.333333 1260Technology 13 150 6 2 1 2 Program 10 1.666667 90Technology 14 891 6 1 2 1 Program 10 1.333333 669Technology 15 2070 9 2 2 3 Program 10 2.333333 666Technology 16 690 9 2 1 2 Program 10 1.666667 311Technology 17 150 6 2 2 2 Development 2 75Technology 18 -250 6 2 1 2 Development 1.666667 -150Technology 19 600 9 2 1 2 Development 1.666667 270Technology 20 323 6 2 2 2 Planned 2 162Technology 21 400 6 2 2 1 Planned 1.666667 240Technology 22 1191 9 3 2 2 Planned 2.333333 383Technology 23 690 12 2 1 3 Deferred 2 259Technology 24 2070 12 2 3 3 Deferred 2.666667 582Technology 25 1035 12 2 2 3 Deferred 2.333333 333
Risk: Resources:1 - Low2 - Medium 1 - Low Resource requirements3 - High 2 - Medium Resource requirements
3 - High requirements - greater than 50% resources for a significant amount of time
Risk (Int) - includes technical and manufacturing risks along with uncertainty around cost reduction estimatesRisk (Ext Customer) - includes likelihood that external customers have issues with the change or reject performance of modified product
30
E. Knowledge Based Set Design in Action
Film Technical Roadmap Definition – Roadmap 2011
31
E. Lean Product Development – Product Design Examples
Film Technical Roadmap Definition – cost savings over time
32
F. Conclusions
Using lean product development methods does lead to reduced cycle times, minimized rework (loop backs), higher returns for development dollars and a more engaged product development team atmosphere
Lean tools are being applied in many different product development areas ranging from automotive to computer to drug/chemical products
Use of set based design and integration/system leadership lead to a flexible product development cycle that is responsive to rapidly changing customer expectations and marketplace conditions
LPD is scalable for the product/technology scope The Kodak film development area has adopted many of the lean
development concepts and set based design. The use of integrating events at both bench scale and at full production scale as early as possible has been critical for technology selection. Much of the success is an outcome of maintaining a solid cross functional team with strong communications and a high degree of knowledge sharing.
33
F. Recommendations
Lean product development concepts can be implemented at any time in the product development cycle
Possible first steps:1. Encourage set based solutions and utilizing integration
events early in programs2. Implement system based leadership on project teams and
drive towards a flexible product development process3. Drive towards cross functional teams and involvement of
customers early in development4. Foster knowledge sharing through simple A3 style reports
and usage of team knowledge sharing and collaboration tools
Both teams and leadership need to support the lean initiatives in product development to be successful.
34
Discussion / Question and Answer
35
For More Information
Chris Haller, [email protected]: www.cjhaller.com/Portfolio.htmlLinkedIn: www.linkedin.com/in/cjhaller/
Resources list:1. A More Rational Approach to New-Product Development, E. Bonabeau, N. Bodick
& N. Armstrong (Havard Business Review March 2008)2. Developing Products in the Half the Time, Preston Smith and Donald Reinertsen
(Van Nostrand Reinhold 1991)3. Going Lean, Stephen A. Ruffa (AMACOM 2008)4. Managing the Design Factory, Donald Reinertsen (Free Press 1997)5. Product Development in the Lean Enterprise, Michael N. Kennedy (Oakley Press
2003)6. Product-Development Practices that Work: How Internet Companies Build
Software, Alan MacCormack (MIT Sloan Management Review, Winter 2001)7. Shooting the Rapids: Managing Product Development in Turbulent
Environments, Marco Iansiti (California Management Review, Fall 1995)8. The Lean Machine, Dantar P. Oosterwal (AMACOM 2010)9. The Machine That Changed the World, James Womack, Daniel Jones and Daniel
Roos (Free Press 2007)10. Toyota’s Principles of Set-Based Concurrent Engineering, Durward K. Sobek II,
Allen C. Ward and Jeffrey K. Liker (MIT Sloan Management Review, Jan 1999)