Quality-One Lee D Dawson 248 280 4800 Lean Product

1
Lean Product Development
Quality-One Lee D Dawson 248 280 4800

• How to Use Risk Determination to Increase
  Velocity of Product Development

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?

3
Lean Product Development

• Increased Velocity to market with a product or
  service, that exceeds the customers
  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.

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

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

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

7
What waste exists in PD?

• Waste comes in several basic forms
• Muda - Non productive or non value added
• Mura - Unevenness
• Muri - Over burdened

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

9
Trying to do Too Much.

• Over processing

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

11
T1
T2
T3
T4
T5
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
Program Risk
T1
T2
T3
T5
T4
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

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.

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.

17
Risk Model Illustration
Primary New Function / Safety
30 Max Requirement/ or specifications Change
Performance/Satisfaction
Business/Control Risk
Minor Risk
70 validated Standard Work
18
QFD (Quality Function Deployment) is a great risk
tool
Define Level of Program Risk
Design Risk QFD Matrix

• Red Risk
• Technical Risk Assessment
• Due Diligence
• Design Reviews
• Orange Risk
• Technical Risk Assessment
• Design Reviews
• Yellow Risk
• Kaizen projects as needed
• Green Risk
• Manage as exception only

Supplied Product Risk Assessment
Design Risk
Manuf. Technology
Supplier Risk
History
Process Capability
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

20
Excess Time for Counter Measures.

• Waiting

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

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)

23
T1
T2
T3
T4
T5
24
2 Failure Mode Discovery (3 Counter Measure
adopted)
1 Failure Mode Creation
Risk Discovery and mitigation drives the curve to
the left achieving lower cost and speed
Number of counter-measures
Number of failures found
time minimized
0
T2
T1
T3
T4
T5
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
Dow NPI
T1
T2
T3
T4
Latitude to take counter-measures
Time
Qualitative QRR
Quantitative MRR
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
Product Quality Plan
32
Product Quality Plan

• 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
• DVPR
• Test Protocols
• System Engineering Cascade

33
1.0 Plan Define the Project
HVPD Product Development
-New Requirements
As Required 1.2 Business/Market Plan 1.3
Product/Process Bench Data
-Wants/Needs/Desires
1.0 Planning
Regulations Input
1.1 QFD Requirements Specifications 1.7 Design
Goals

Develop Concept Designs
1.11 Preliminary List of Special Characteristics
1.1 FMA
1.10 Preliminary Process Flow
Quality History
T1
2.0 Design Develop
3.0 Process Design Develop
2.2 DFA/ M
Robust
2.6 Product 2.7 Design
3.3 Process Flow
DF
(x)
3.5 Characteristics
2.11 Special Characteristics
2.1 DFMEA
Path
1

2
Matrix
2.0 Product Design Development
3.0 Process Design Development

• Special Characteristics
• Error/Mistake Proof Collaboration
• Improved Statistical Capability

DVPR
2.1 DFMEA
3.6 PFMEA
Path 3
T2
-
Test Development
3.7 Pre Launch Control Plans
2.6 Engineering Drawing. Design Tooling Drawing
T3
4.1 Production Trial Run
4.7 Production Control Plan
4.0 Product Process Validation
4.0 Product Process Validation
4.3 Preliminary Process/Capability Studies
Process Instructions
T4
34
Requirements Targets
Product Specifications
Systems / Sub-Systems / Components BOM
Phase Progression
Subsystem/parts
Interface analysis Geometry Boundary
Diagram/Interface Matrix
Design Requirements
System Tolerance Stacks Proposed RSS
Design Product Specifications NEM/NES//NDS New
Program targets Past history
Component Tolerance Stack-up
System DFMEA
Sub-System DFMEA
Fault Tree Analysis
Cascade
Component DFMEA
35
Process Operations and surrogate variation per
CPPD
System DFMEA
Sub-System DFMEA
Component DFMEA
Fault Tree Analysis
High Priority Process Operations
Tolerances refined
Select Datums and Geometry for Special /Key
Features Spec Char Initiated (Risk Based)
Refined Tolerance stack and GDT Locked
Spec Char Collaboration
SC and KF From all DFMEA and FTA And SC and
KF from Stock
Cascade of Special and Key Characteristics
Release design
Special Controls
Process FMEA
Control Plan
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

37
(No Transcript)
38
DR Inputs -Reliability Tools -DFMEAs -PFMEAs -Te
st Failures -Process Failures
Design Review / Risk Mitigation
T1.00
Pareto By Risk
ROY Chart
Action Matrix

• Time / Date
• Name / Responsibility
• Risk Level

Sort Matrix for Design Review
T2.00
Design Review
Glide Path
Design Review
Yes
Pareto By Risk
Risk Mitigated?
ROY Chart
Update
No
Reassign Responsible / New Action

• New Action
• New Date

Pareto By Risk
T3.00
ROY Chart
Update Action Matrix
Rev. Date 4/12/10
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

40
(No Transcript)
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

42
Product Quality Plan

• Risk Mitigation Examples

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

• Causes should be limited to design BOM,
  Interfaces and Noises (ION)
• Causes at component level analysis should be
  identified as part or system characteristic (a
  feature that can be controlled at process)
• There is usually more than one cause of failure
  for each failure mode
• Causes must be identified for a failure mode, not
  an individual effect
• Insulation material too thick
• Inside cup sized incorrectly
• Insufficient insulation

46
Remember the ION Principle when developing DFMEA

• Inside
• Outside
• Noise

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

48
Milwaukee Specific Example of a Boundary Diagram
Handle Bars
Wiring Harness
Clearance
Vibration
Skin
Electrical Console
Valve
Clearance
Filler Neck
Seat
Vibration
Filler Cap
Frame
Fuel Gage
Vibration
Baffle / Filter
Fuel Line
Bracket
Filtered Fluid
Decal
Interface -Physical -Energy Transfer -Matl
Transfer -Data Transfer
DFMEA Boundary
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.

ION for Design FMEA 6M for Process FMEA
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

51
Error Proof Zone
Zone One
Statistical Capability/ Low Cost Error Proofing
Zone Two
Control Strategy
Zone Three
Zone Four
Rev. Date 4/12/10
52
Cascade of Risk to Root Cause

• Risk Determined during DFMEA drives three
  additional activities in PD
• DVPR (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

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

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.

56
Quality-One Legacy MatrixCore Competencies
Assembly
Fabrication
Painting
Welding
57
Q-1 Legacy MatrixAssembly

• Technology Blocks
• Obtain
• Recognize
• Handle Transport
• Prepare
• Position
• Attach
• Torque
• Connect
• Press
• Remove
• Route Connect
• Fill Fluids
• Validate

58
Q-1 Legacy MatrixFabrication

• Technology Blocks
• Obtain
• Recognize
• Handle Transport
• Prepare
• Position
• Form
• Press
• Remove

59
Q-1 Legacy MatrixPaint

• Technology Blocks
• Obtain
• Recognize
• Handle Transport
• Prepare
• Position
• Paint
• Remove
• Fill Fluids
• Inspect

60
Q-1 Legacy MatrixWelding

• Technology Blocks
• Obtain
• Recognize
• Handle Transport
• Prepare
• Position
• Weld
• Remove

61
Q-1 Legacy MatrixFailure Modes / Causes
Causes
Failure Modes
62
Q-1 Legacy MatrixFailure Modes / Type 2 Controls
Type 2 Controls
Failure Modes
63
Q-1 Legacy MatrixType 1 Controls / Causes
Causes
Type 1 Controls
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.