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

PERFORMANCE

Constantly check Critical To Customer functions are in line

with customer behaviour

FEATURE

PERFORMANCE

Translate this into product

features within Target

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 type

Value hypothesis

Confirmation method

Confirmed Y/N

Conclusion 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

Technology

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