Lean Methods Breakout Groups

Presentations from those who have had success implementing lean concepts in product development can be very inspiring, but how do you get it done at your organization? A significant take-away from this summit will result from your participation in breakout groups focused on one specific lean method that you are interested in learning more about how other industries/companies are working towards implementation. As a participant, you will be asked to select two breakout group topics and come prepared to discuss the questions listed below each topic you select.

In the Lean Methods Breakout Groups you will assemble with 8 – 10 of your peers to collectively determine implementation barriers, estimate the potential value (to your company) of successful implementation of specific lean concepts and create action plans and new approaches for moving forward with this opportunity. To encourage cross-learning on all topics, each breakout group will report back their findings to the conference as a whole.

Please review the proposed topics below and when you register for the event, please identify your breakout group topic selections. If you would like to propose an additional breakout group topic, please contact Tracey Kimball at 781.891.8080 ext 214 or email her at [email protected].

Breakout Groups:

• Quantifying the Cost of Delay

• Controlling Queues

• Batch Size Reduction

• Managing Variability

• Accelerating Feedback

• Achieving Cadence

• Promoting Flexibility

Quantifying the Cost-of-Delay

Any systematic approach to Lean Product Development requires quantifying the cost of development process queues. The primary cost of these queues is the time they add to the critical path of project. Therefore, calculating credible costs-of-delay is essential making good economic decisions about queues. It is also critical to influence management and organizational attitudes. This subgroup will focus on exchanging ideas on the calculation and use of cost-of-delay.

1. How much success have you had using cost-of-delay estimates to influence management decisions?

2. How long have you been doing this?

3. Who has been involved in doing these calculations?

4. What have been the biggest sources of errors?

5. How much effort did it take the first time?

6. How much effort did it take after the method became mature?

7. How do you disseminate this information to the entire team?

8. What benefits have you gotten from this information?

9. How would you change your approach if you had to do it again?

10. What do you consider to be the greatest challenges in using this tool?

Controlling Queues

Large queues in product development raise cycle time, increase risk, raise overhead, and increase variability. Reducing queues is central to obtaining the benefits of lean product development. Unfortunately many product developers have a poor understanding of the location and cost of queues in their processes. This group will examine how they were able find queues, to communicate the problem to others, to justify interventions to reduce queues, and to carry out these interventions.

1. Which queues did you decide to attack?

2. How and why did you choose these queues?

3. How did you estimate the size of these queues?

4. How did you estimate the cost of these queues?

5. What interventions did you consider to reduce the queue size?

6. Which ones did you eventually choose?

7. What advantages did you gain from having smaller queues?

8. Were there any disadvantages?

9. What was the hardest part of reducing queues?

10. What advice would you give other product developers trying to do the same thing?

11. How would you change your approach if you had to do it again?

Batch Size Reduction

One the fastest way to improve flow is to reduce batch size. Batch size reduction directly reduces inventory levels and also reduces variability in flows. But, when batch sizes are reduced the fixed transaction cost per batch must be paid more often. This means we must make a tradeoff between the disadvantage of higher transaction costs and advantage of faster cycle times. Most product developers overestimate their transaction costs and underestimate the diseconomies of large batch sizes. This group will examine the economic tradeoffs and organizational challenges or reducing product development batch size.

1. In which areas have you had the greatest success at reducing batch sizes?

2. What benefits did you experience in: cycle time, quality, cost?

3. Were any of these benefits larger than expected?

4. Were there any unanticipated costs?

5. What did you do to reduce the fixed transaction costs per batch?

6. Were there any psychological advantages to having smaller batch sizes?

7. Which areas do you consider to be high potential for further batch size reduction?

8. Have you had to make any changes in your product architecture to make smaller batch sizes feasible?

9. What advice would you give other product developers trying to do the same thing?

10. How would you change your approach if you had to do it again?

Managing Variability

Standard product development doctrine focuses on reducing the frequency of problems. We seek to achieve Six Sigma defect levels (3.4 ppm) by getting engineers to "do it right the first time". Yet, innovative designs require trying new ideas, and this causes variability. Lean developers can reduce the cost of this variability without reducing defect levels if they reduce the consequences of defects. This can be done by truncating unproductive paths very quickly. This group will examine methods of sustaining innovation while still controlling the economic damage done by variability.

1. In which areas of your system is innovation essential for differentiation?

2. How do you focus innovation on these areas?

3. How do you accelerate learning in these areas?

4. How do you prevent disruptive innovation in other areas of the design?

5. How do you architecturally decouple critical areas from the remainder of the system?

6. To what extent have you been able to help your organization understand the difference between good and bad variability?

7. What has been the most effective way to communicate this concept?

8. How do encourage engineers to achieve optimal failure rates when trying new ideas?

9. What have you learned about the need for variability in your process?

10. What advice would you give other product developers trying to do the same thing?

11. How would you change your approach if you had to do it again?

Accelerating Feedback

Rapid feedback is even more crucial in product development than it is in manufacturing because product development has higher inherent variability. Furthermore, this variability adds economic value. This group will examine techniques to accelerate feedback in product development?

1. Which feedback loops are most critical to the success of your development process?

2. Which of these did you decide to speed up?

3. How much improvement did you achieve?

4. What benefits did you gain from faster feedback?

5. Did you experience any disadvantages with faster feedback?

6. How did you deal with the lower signal to noise ratio of fast feedback?

7. What advice would you give other product developers trying to do the same thing?

8. How would you change your approach if you had to do it again?

Achieving Cadence

Most development processes are paced by increments of scope rather than the fixed time increments of cadence. This causes uncertainty in the arrival times of work to downstream processes, which increases queueing problems. In contrast, paced processes with a regular cadence creates economies of synchronization. This group will examine examples of cadence in product development.

1. In what areas do you use a regular cadence to pace the flow of process deliverable?

2. Have you always done it this way?

3. If not, what advantages and disadvantages have you seen using a time-based cadence?

4. Are there any specific areas in which you have lowered cost with cadence?

5. Have you made any changes in your product architecture to exploit cadence?

6. When do you change the cadence during the development process?

7. What areas are you interested in applying cadence to?

8. What advice would you give other product developers trying to use cadence?

9. How would you change your approach if you had to do it again?

Promoting Flexibility

Organizations focused on efficiency often create specialized resources that are incapable responding quickly to change. Yet, it is hard to justify capabilities that are not fully utilized. In this group we will explore successes practitioners have had in creating flexibility in people, processes, and resources. This group will examine methods to increase flexibility in the development process and resources.

1. How do you signal to workers that flexibility is valued?

2. How do you systematically broaden the skill sets of your staff?

3. Have you made progress aligning your compensation system and your need for flexibility?

4. What have you done to increase the flexibility of your process flows?

5. In which areas have you found it most economical to make resources flexible?

6. Where have you been able to use external resources as surge capacity for internal resources?

7. What amount of flexibility did you find sufficient for normal variation?

8. Do you have a deliberate escalation process for abnormal variations?

9. What advice would you give other product developers trying to create a more flexible organization?

10. How would you change your approach if you had to do it again?