Lean Product Development

1. Lean Product Development How to Use Risk Determination to Increase Velocity of Product Development 1

2. Lean Product Development Product Development is the lifeblood of an organization. Successful Future product and service offerings keep the customers coming back. We strive relentlessly, for products and services which delight our customers assuring loyalty and future success. With so much riding on product development and the ever increasing complexity of our products and services, how do we decrease the potential for failure and simultaneously, increase our velocity to market? 2

3. Lean Product Development Increased Velocity to market with a product or service,��that exceeds the customer�s expectations� some say is impossible. More time �not less� is required to assure reliability. The purpose of this discussion is to challenge the notion that speed and effectiveness are not compatible.� Taking less time to get a product in the marketplace is indeed practical and possible. 3

4. Lean Product Development Risk can play a critical role as a measure of progress and an indicator of future reliability and quality.� The measurement of risk as a substitute for actual failure has led teams to faster product/service introduction (10% + faster) with far fewer concerns than if driven by physical test failures of prototypes (60% less issues). Managing Risk in product development, as a primary indicator, keeps the teams focused and provides discipline in Design Reviews, Test Planning, Effective and least expensive Quality Controls at launch 4

5. Premise of Lean Product Development What is Lean Product Development? Lean PD is a term which describes the removal of wasteful steps that may exist within the PD process. Often, success of Lean PD has been translated into two measures Speed to market Improved Reliability 5

6. Premise for Lean Product Development Reliability and going fast are believed to be mutually exclusive and in reverse correlation to one another. And many times they can be. This is due to specific type of waste that exists in PD 6

7. What waste exists in PD? Waste comes in several basic forms Muda - Non productive or non value added Mura - Unevenness Muri - Over burdened 7

8. What waste exists in PD? Muri Is the specific waste that exists in Product Development Over-burdening (Muri) PD comes from two of the seven wastes Over processing Trying to do too much in a limited (typically reduced) time to market opportunity. In PD, a relationship exists between content change and time to market. Waiting Time is wasted between the time a failure is created from the point in time it is found. Too much emphasis on evidence before taking counter measures 8

9. Trying to do Too Much. Over processing 9

10. The Failure Factory Product Development is a Failure Factory Each click of a mouse in a CAD system, material selection, or process method selected brings with it the potential for failure. Failure is an act of the Design Engineer both product and process Failure must be avoided or controlled before the product can come in contact with the customer. But how many failures are there to find and prevent/control? This is the great unknown of Product Development 10

11. 11

12. Trying to Do Too Much The integral or area under the curve is determined by the quantity of change that is being managed in the PD process Small amount of change lowers the height of the curve Large amount of change creates a higher curve. The volume of the curve is also �unfortunately� unknown We do not know the number of failures that exist when we are creating value in new products or services To not acknowledge the amount of failure can often lead to: Issues at launch Reduced life of the product or service.

13. 13 Failure modes discovered late cause a lot of changes due to the inescapable need for counter-measures. If some counter-measures do not work, some failure modes will escape into the field.Failure modes discovered late cause a lot of changes due to the inescapable need for counter-measures. If some counter-measures do not work, some failure modes will escape into the field.

14. Managing Program Risk Program New or Changed Content is managed through the use of a Risk Model Risk Models separate the new content into several categories. Red- Primary Function and Impact on Safety Orange- Performance affecting Customer acceptance Yellow- Annoyance managed when highly likely Green- Low Risk which is optimized in PD 14

15. Managing Program Risk An established Standard Criteria for Program Risk Level is integral to Lean PD. A 70/30 Ratio is the greatest amount of risk that can be managed for velocity to market. 70 % Validated 30% New/Changed/Poor History/Environment Less is better but may not be avoidable. 15

16. Program Risk Guidelines Red Risk greater than or equal to 10% or total new or modified changes (including past failure) requires resource assessment. Personnel �Person Hours� Time to task �estimated� CAE or simulation capability and availability Distance in Collaboration �Co-Located� Difficulty to achieve � Design Risk Ranking� Time Estimate is established based on assessment. Orange Risk greater than 20 % alone or 30% accumulated with Red Risk requires resource assessment. Yellow Risk is managed as exceptions as experienced. 16

17. Risk Model Illustration

19. Expected Results Defining total amount of Risk permitted in a program allows for detailed resource planning based on time and available personnel Keeping the risk at 30% accumulated: New Content Changes/Modification to current product and or process Past History of Failure Can reduce by 10% the time to Market 19

20. Excess Time for Counter Measures. Waiting 20

21. Excess Time for Counter Measures Failure modes discovered late in PD Result in late changes due to the inescapable need for counter-measures when failure is found �Every Failure Will Be Found�. Based on when counter-measures are determined, there may be insufficient time to verify and validate. If some counter-measures do not work, some failure modes will escape into the field. This leads to customer dissatisfaction and warranty 21

22. Excess Time for Counter Measures Finding Failure early translates to the measurement of risk and subsequent mitigation. Looking for Risk in PD involves using: Computer Aided Engineering (CAE) and Simulation Technology Reliability by Design/Quality Planning Tools Qualitative Quantitative Formal Technical Design Review (DRBFM) Systems Engineering Test Strategies (V Model) 22

23. 23

24. 24

25. What is Risk? Risk is the defined as the likelihood of an objectionable event. Hazard/Failure or Fault Severity Likelihood or Failure Occurrence/ Failure Rate/ Likelihood How well we measure risk, is determined by: The legacy information available or what is known. The tools and techniques utilized to discover risk. Level of unknown New/Modified etc...

26. Lean PD and Risk In Lean Product Development (PD), risk is the substitute for failure. Risk is treated exactly the same as failure. When risk is great enough, mitigation is required. When risk is measured objectively, Actions (counter measures) can be taken to mitigate the risk, prior to introduction of the product. A risk based Design Review process is an integral part of a successful Lean Product Development process.

27. Address Failure Modes Early

28. Types of Risk Each unique PD project brings with it new and inherent risk. Reliability and Quality Tools are selected based on the potential risk that is potentially present: Intentional Incidental Intentional risk exists when change is introduced within the design Materials Geometry Interfaces

29. Risk Model Risk Models for each selected reliability/quality planning tool are utilized to drive actions as far forward in PD as possible. Lower cost counter measures Easier to implement counter measures Avoid failure discovery at testing or in the hands of the customer Design Reviews (DRBFM concept) integrate risk actions. Reliability growth is measured with risk until test results demonstrate quantitative reliability growth

30. Product Quality Plan Incidental risk exists when new environments and change occurs outside of the design. Environments Duty cycle/customer usage profile Degradation conditions Tools are selected based on the potential risk that is likely to be present. A Product Development Reliability/Quality Plan is developed by a core team for the PD project.

31. DESIGN FMEA - GENERAL MODULE 2 Notes:DESIGN FMEA - GENERAL MODULE 2 Notes:

32. Reliability/Quality plan including qualitative and quantitative techniques are aligned to the Lean PD process. Map each requirement against each subsystem and assure written specifications are present. Derived from transfer function. Reliability matrix method Align qualitative tools (QRR) to requirements Tool qualification (Quality of Event) Accumulate probabilities (probable PPM) Map quantitative tests (MRR) against requirements DVP&R Test Protocols System Engineering Cascade Product Quality Plan

34. 34

35. 35

36. Design Review Based on Failure Each risk which is discovered requires mitigation. Risks are carried over to the design review for specific details and review of the results. Decisions are made as to the credibility of the risk and the successfulness of the mitigating counter measure. Risks are tracked against a target Glideslope chart. Risk levels at each stage of Lean PD are assessed at Project Gateways (T1, T2, T3 etc�) Progress against Targets allows for quick action to get back on the Glideslope 36

39. Risk Tracking Reliability growth is based on qualitative methods (Risk Measurement) Design Review criteria for each tool/method outcome. Red= Primary/New Function/Critical/Safety Orange= Significant/Performance Yellow= Controls Strategy/Kaizen/As Experienced Tools aligned to (T gateways), accumulate/stack Reds, Oranges, and Yellows Risks that have been successfully mitigated permit program to move into final product certification and delivery

41. Results A Product Quality Plan deployed against the potential risk separates the Vital Few from the Trivial Many possible things that can go wrong Keeps the Team Focused The methods/tools and techniques selected in the PD specific Product Quality Plan, push actions based on Risk not actual failure at prototype or in the testing stages. Fewer changes occur post design release (Up to 60% less when compared to previous programs of similar size) Tools Linkage provides next inputs from derived outputs Not a checklist to show we did it, instead measuring actual actions against risk 41

42. Product Quality Plan Risk Mitigation Examples 42

43. FMEA Failure Modes/Cause Mechanisms Failure Modes are initially based on requirements and specifications Full Partial (Too Little/Too Much) Intermittent Unintentional Causes are: Part/component specific Geometry Physical properties Chemistry

44. FMEA Failure Modes/Cause Mechanisms Causes are: Interface and Interaction Physical Energy transfer Material transfer Data transfer Noise Factors Stresses, customer/installer misuse, environments, degradation, sensitivity to variation Follow the �ION� technique

45. 45

46. Remember the ION Principle when developing DFMEA Inside Outside Noise 46

47. Origin of causes in Design FMEA Causes from the Boundary Diagram Components inside the boundary Design Mistakes Interfaces with other Systems Causes from P (Parameter)-Diagram (Design FMEA) Noise factors Causes from past history (Failure Mode Avoidance FMA) Warranty Rejects Internal COQ (Cost of Quality) New Causes not yet considered 47

49. Fishbone Ishakawa Diagram Brainstorm all causes of failure mode at one time. Similar to a Fishbone / Cause-and-Effect diagram. Enter onto the form as brainstormed. 49

50. DFMEA Cause Best Practice is ION Follow the ION principle Inside (the boundary) Components and details about the design Outside (the boundary) Interfaces of the 4 types Physical Energy Material exchange Data transfer Noise Environments User and duty cycles Degradation and sensitivity to variation NEW Causes not covered by ION 50

52. Cascade of Risk to Root Cause Risk Determined during DFMEA drives three additional activities in PD DVP&R (Design Verification Plan and Reporting) test modification Design Actions to reduce risk Special Characteristics Development for CPPD (Collaborative Product Process Design) and Process FMEA The use of these linked tools allows for more detailed risk assessment and therefore closing in on potential Root Causes of potential failure And the process story board continues until All Red Risk Most Orange Risks Mitigated to a level of comfort for the team/program Yellow risk as determined to be as necessary

53. Standard Work Validated Processes, Constructions, Materials 53

54. Development of Standard Work As we learn and validate the processes and approaches we use, standardizing the Legacy has added benefits for PD Velocity Increased Product Development speed comes from avoiding developing a successful something over again. An Example where time is spent, but not always with great benefit is FMEA 54

55. Development of Standard Work A Lean Approach to FMEA provides the team with a set of known Failure Modes, Causes, and Verification methods to pick from. Never do the same FMEA twice Never do the Same Ishakawa Diagram twice Once you have a validated process, construction, or material stay with it until market pressure requires change Change brings risk of Failure Use of Legacy increases speed FMEA development time reduced by 70%. 55

56. Quality-One Legacy MatrixCore Competencies

57. Q-1 Legacy MatrixAssembly

58. Q-1 Legacy MatrixFabrication

59. Q-1 Legacy MatrixPaint

60. Q-1 Legacy MatrixWelding

61. Q-1 Legacy MatrixFailure Modes / Causes

62. Q-1 Legacy MatrixFailure Modes / Type 2 Controls

63. Q-1 Legacy MatrixType 1 Controls / Causes

64. Summary Recognizing the waste (Muri) in the Product Development Process can drive a plan to make the PD process Lean Risks should be measured at Program Level and at the Technical Level Program Risk Level Activity Limiting New Content/Modifications and Past Failures to 30% or less improves Velocity performance of PD Speed can increase 10% with 30% new content and faster for less Change Technical Risk Level Activity Creating a Reliability Plan to discover Failure Modes early in PD measures Risks, permits team to mitigate risk instead of wait for costly failure. Reliability and Quality Tools, when linked do not slow PD, rather they increase the velocity to Market

65. Summary Proper use of Legacy Capture and Lessons Learned drives the development of Standard Work Validated Standard Work is the Anti-Risk assessment: Re-Using Validated Processes, Constructions, and Materials reduces risk Less FMEA Less Testing Less Validation Proven Capability PD Velocity is increased using Legacy and Standard Work by applying what is already known Never Re-Learn the same information

66. Summary Every program is plagued with the thought of how much performance improvement of the product or process is necessary before launch. With everything there must be balance: Remember the rule: �The Enemy of the Good is the Better� It is generally true that a good product that makes it to market quickly is better than a Better product taking significantly more time to develop and launch.