Seeking value by Michael Ballé at the European Lean IT Summit 2012

Copyright © Institut Lean France 2012

22 & 23 November, 2012
Paris, France

Seeking Value

By Michael Ballé


Seeking Value

Michael Ballé


Lean thinking

1. Value
2. The value stream
3. Flow
4. Pull
5. Perfection


Value in IT

• Information Systems are increasingly
expensive

• Legacy makes IS inflexible and costly to change

• Project overruns reach “black swan” potential

• Users still never happy


Value

Value = Function / Cost


Those pesky customers

What they say they want
≠
What they’re ready to pay for


Because they don’t know themselves

How I feel about the product right now

Was I right to purchase it?


Function (action) ≠ Feature (tool)


Understanding value

• What does the FULL
product/service do for
the customer?

• What do customers
VALUE about the
product (or DISLIKE)

• At what cost?


Critical To Customer Performance

• What do customers
value?

• How do we express this
in technical
parameters?


CTCs change!

• Through the product’s life course

• As customers learn to use it

• As the usage environment changes


The value challenge

FUNCTION FEATURE
PERFORMANCE PERFORMANCE

Constantly check Translate this
Critical To Customer into product
functions are in line features
with customer within Target
behaviour Cost


To make products, first make people
1. Follow the customers

2. Make choices

3. Teach teamwork

4. Set-up a design factory

5. Learn to learn


1. Follow the customers


User complaints

• User complaints are users
taking the time to educate
us about what they value

• Every complaint matters –
no Pareto thinking

• Go to the gemba, ask why?
Understand what prompted
the user to complain: how
did the product/service get
between the user and what
he/she wanted?


Product takt time

• Pick a tempo

• Commit to a product release at that beat NO
MATTER WHAT

• Only put validated innovations into the proposed
product

• Learn from customers’ reaction (BUY/NOT BUY)


Test user values

Customer Value Confirmation Confirmed Conclusion
type hypothesis method Y/N On CTC

Rephrase Critical To Customers


2. Make choices


Chief Engineer: single point
accountability
• Who is going to capture
Critical To Customer

• Express this into technical
parameters

• Be the last arbiter of technical
choices, in relation to CTC

• Make sure the project keeps
on track in terms of schedule,
innovation and costs


Customer segment

• Choose a segment

• Specific enough to
differentiate the offering

• Large enough to make a
profit

• Segment according to
usage, draw out a user
model


Frame a concept

• What job(s) should the
product do for the users?

• Find the “yet”
contradiction

• Zero compromise on the
“yet”

• Specify targets on the
performance radar chart


Deploy the concept at module level

• List new ideas, involve suppliers

• Test against standards and fundamentals

• Test against concept & user models

• Evaluate impact on whole product

• Make choices


Pivot

• How do we know we get
it right/get it wrong?

• When do we need to
pivot? What are clear
markers to distinguish
pivot from mission creep?

• What are the tripwires?


3. Teach teamwork


Team clarity

• Chief engineer as team
leader

• Clear in/out frontier – no
part timers, incentives to
stay to the end

• Oobeya (war room)

• One member of the team
coordinates suppliers


Solve sticky problems BEFORE
development
• Bring the team together by solving tricky
problems before developing the product

• Try alternative solutions, build models,
prototypes, simulations

• Involve all the technical chain (testers, suppliers,
etc.) in evaluating alternate solutions

• Let the team build their own internal rules


Lean design strategy

Concept Development Redevelopment

Lead-time


4. Set up a design factory


Detailed planning

• Once key problems have a solution & architecture
is clear

• VERY detailed planning, module-based

• Plan for interfaces and interactions

• Draw a detailed Value Stream Map involving
every actor involved


Work with standards

• Typical problems /
typical solutions

• Seek standard ways of
doing things – starting
with easy things, such
as names, addresses,
etc.

• Write checklists


Test the testing culture

• The test drives the code:
easy to say, hard to do

• Are engineers trained to:
– Understand they’re in
charge of their own quality
– Know HOW to test

• How automated are
testing tools?


Readiness to go live

• Assess schedule against “go live”

• Overreact to open problems – find resources or
outside expertise quickly

• Resist calls to increase scope – drop features that
are not CTC and not ready

• See and solve teamwork problems early


5. Learn to learn


Self-reflection activities

Date Problem Cause Countermeasure Status

•Learning events during the project:
Teardowns
Code cleanup
Code reviews


Teach and improve standards

• Dojos: one-on-one
training

• Suggestions

• Experiments

• Constant improvement
of checklits


Check against performance targets

• Go to users quickly

• Rough and ready builds or prototypes

• The code is the gemba


To make things, first make people

Experience

Passion

Open mind


22 & 23 November, 2012
Paris, France

More Lean IT videos and presentations on
www.lean-it-summit.com

Seeking value by Michael Ballé at the European Lean IT Summit 2012

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Seeking value by Michael Ballé at the European Lean IT Summit 2012

Similaire à Seeking value by Michael Ballé at the European Lean IT Summit 2012 (20)

Plus de Institut Lean France

Plus de Institut Lean France (20)

Dernier

Dernier (20)

Seeking value by Michael Ballé at the European Lean IT Summit 2012