Michael kennedy set-based decision making taming system complexity

Set-Based Decision Making

Taming System Complexity

Michael Kennedy
Founder – Targeted Convergence Corporation
michaelk@targetedconvergence.com

Copyright © 2011 Targeted Convergence Corporation
All Rights Reserved.

Theory Versus Practice

Theory - Is when everyone knows why, but
nothing functions.

Practice – Is when everything functions, but
nobody knows why.

German Soccer Coach


Theory Versus Practice

  In theory, phase gates systems should function well.
  In Practice, they don’t.

  In theory, knowledge management systems work.
  In Practice, they don’t.

  The Toyota Product Development system functions
very well.
  Theoretically, it is hard to define why.

If you can’t define why it works, how can you achieve it?


What is the State of Hardware
Product Development?
Here is what I see over and over:
  Schedules and detailed requirements are set early
  The system concept is set quickly
  This begins wide sets of planned tasks to meet
requirements (Phase-Gate Planning)
  Eventually the critical knowledge gaps emerge
  The loopbacks start and continue for the life of the
program

Consistent Results: project delays, cost overruns, 70% of
engineers firefighting, problems repeat on next projects


The Fundamental Problem

Made and unmade decisions in the
“Fuzzy Front End”
cause loopbacks!
Fuzzy Front-End

Concept Planning Design Validation Manufac Customer
Phase Phase Phase Phase -turing Usage


The Fuzzy Front-End, aka:

The Land of Little Scrutiny
 Start design early to finish on time.

 Choose fast and be specific.

Product and process decisions are made:
 Before customer needs are understood

 Before feasibility is proven

 Without knowing why past products
succeeded or failed


It Get’s Worse
Fuzzy Front-End

Concept Planning Design Validation Manufac- Customer
Phase Phase Phase Phase turing Usage

Fuzzy Front-End Knowledge doesn’t flow
between projects.
Concept Planning Design Validation Manufac- Customer


What challenge is product development trying to
solve?

Business Goals

Technical
Capability

Customer Interests

  Product development is about innovating a solution that:
  Achieves your business goals
  Satisfies your customers’ interests
  Fits within your technical capabilities

The goal is to find that sweet-spot.

Unfortunately, in the Fuzzy Front End,
we have a very fuzzy view of that sweet spot

Business Goals

Technical
? Capability

Customer Interests

Fuzzy Front-End
  We
have
unclear
visibility
to:

Concept Planning Design Prototype   Our
business
goals

Manufac- Customer
  Our
customers’
interests

  Our
technical
capabili8es

  So,
what
do
we
do?

  Tradi8onally:

we
GUESS!...


Here’s what’s going on

Fuzzy Success
Front Assured
Detailed
End
Design Does it work?

Ramp-up
Select one,
and hope it
works!
This Time Frame is Unstable

Detailed
Specs We call this point
based Design

Toyota is in a Different Paradigm
Traditional Toyota
Product Specific as possible Rough targets to start.
Specs Early as possible. Details evolve with the project.

Design
Made as early as possible. Delayed as long as possible.
Decisions

Testing Mostly after design, to fix. Mostly before design, to learn

Project
Administrative – to manage Technical – to manage knowledge
process compliance growth into products
Management
Innovation New product breakthroughs, but
New product concepts
Focus mostly subsystem platforms


The Toyota Philosophy

Product development is not about developing cars,

it is about developing knowledge about cars.

Great cars will emerge from the interaction.


At Toyota, Product Development looks like this

Focused Knowledge
Development across
projects
RAPID CYCLES OF LEARNING Design Phase Validation Phase Launch Phase
& CONVERGNCE

And the pull of
RAPID CYCLES OF LEARNING Design Phase Validationt Phase Launch Phase
& CONVERGNCE

the knowledge
into a cadence
of products

At Toyota, Product Development looks like this

Focused Knowledge
We call it Development across
Set-Based projects
Decision SET-BASED Design Phase Validation Phase Launch Phase
DESIGN
making

SET-BASED
DESIGN
Design Phase Validationt Phase Launch Phase
And the pull of
the knowledge
into a cadence
of products

Set-Based Design
looks like this:

Captured Knowledge for Future Use!
Both Successes & Failures

Fuzzy Front
End
Detailed Confirm it
Design Works Ramp-up

This Time Frame is Stable and Known


Set-Based Design
looks like this:

Captured Knowledge for Future Use!
Both Successes & Failures

Fuzzy Front
End
Detailed Confirm it
Design Works Ramp-up

Success This Time Frame is Stable and Known
Detailed
Assured
Specs

Set-Based Thinking
looks like this:

What are These?
  Are they System concepts only?
  Are they subsystem variations?
  Or, are they something else?


Toyota has taught the answer to that question

Tradeoff and limit curves are the visual
representation of basic product and
process physics and economics

They are the Toyota’s engineer’s primary tool to: Safe
region
  Understand
  Communicate and negotiate between
specialties and functions
  Train new engineers
  Record knowledge
  Negotiate and communicate between
customer and supplier
Infeasible
  Conduct design reviews
  Communicate between developers and
managers
  Design quality into the product


Introducing Limit & Tradeoff Curves

Tradeoff and limit curves are the visual
representation of basic product and
process physics and economics

They are the Toyota’s engineer’s primary tool to: Safe
region
  Understand
  Communicate and negotiate between
specialties and functions
  Train new engineers
“The most important thing I learned
  Record knowledge

at Toyota was their dependence onInfeasible
  Negotiate and communicate between
customer and supplier and the
power of limit and tradeoff curves”
  Conduct design reviews
  Communicate between developers and
managers
Dr. Allen Ward
  Design quality into the product


Generalizing and Visualizing the Knowledge

Muffler: goal is to minimize both noise and
back pressure

Existing Product
Noise level

Did you learn
anything for
Prototype 2 future design?
Prototype 1
Was that best
trade-off
Back pressure for customer?


back pressure
Noise level

Prototype 2
Prototype 1

Back pressure


back pressure
So, all you
really learned
was that one
trade-off point!
Noise level

Is the lesson that you can’t get
more quiet than this?

Or something in between?

Or is the lesson that the smallest backpressure is this?

Back pressure


back pressure
The Toyota Way:
Multiple prototypes
are built and tested
Noise level

to failure
Safe
region This is Set-Based
Thinking!

Infeasible Don’t capture
points,
Back pressure capture sets!

Set-Based Decision-Making is optimizing tradeoffs
between Customer Interests using Set-Based
Knowledge from others
Existing Product

Noise level
Detailed
Design

Infeasible
Set-Based Back pressure
Decision- Set-Based
Making Knowledge
Solution
Project Team
sets
Mfg cost

Making decisions without
understanding the impact Existing
Product Production
on customers is the major Support
cause of loopbacks Back pressure


Set-Based makes your Knowledge concrete such
that…

  … it can flow between
areas of expertise Existing Product

Noise level
(collaboration). Detailed
Design
  … it can flow between
projects (reuse). Infeasible

  … it can be continuously Back pressure
Set-Based
Knowledge
improved. Solution
  … it can make visible sets

what needs to be Mfg cost

learned to further
converge. Existing
Product Production
Support
Back pressure


Set-Based Knowledge Flow

K K Knowledge is created
How Set-Based from product VS #2 and
Supports Knowledge K K is added to the golden
arrow along with
Flow K K Knowledge from VS #1

Set-Based Phase Design Validation Customer
Mfg.
Phase Phase Usage

K K PRODUCT #2 Value Stream
P
Some previous Knowledge is used
K K in the next product value stream

A
Continuous Improvement thru D
K K
Set-Based Problem Solving

C
K = Re-useable Knowledge,
Mfg. Curves, Guidelines, etc.
Phase Phase Usage
Both previous successes as well as
failures provide knowledge for
future use!
PRODUCT #1 Value Copyright © 2011 Targeted Convergence Corporation
Stream All Rights Reserved.

This was the learning: robust, approved

Then they learn
some more

Then they standardize
for Set-Based reuse


The Limit Curves provide the knowledge foundation

CGx vs. Launch Conditions


The knowledge is also the Basis for
Innovation

By removing the
technical restrictions

We need to
move the wall

Then setting the
new standards

Some Questions to Ponder

Mfg.
Phase Phase Usage

Is Set-Based Design a Version of Agile?
- Both are rapid cycles of learning
- Both build out the system as you learn

Why does pure hardware development not use Agile?

Is Agile a Version of Set-Based Design?

How about embedded software?

Michael kennedy set-based decision making taming system complexity

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (14)

Similaire à Michael kennedy set-based decision making taming system complexity

Similaire à Michael kennedy set-based decision making taming system complexity (20)

Plus de AGILEMinds

Plus de AGILEMinds (20)

Dernier

Dernier (20)

Michael kennedy set-based decision making taming system complexity