1. Fallacy 2: Processing work in large batches improves the economics of the development process.
1.1. A second cause of queues in product development is batch size.
1.2. The reduction of batch sizes is a critical principle of lean manufacturing.
1.3. “How to Determine Optimal Batch Size”
1.3.1. Changes in batch size affect two primary costs:
1.3.1.1. -the transaction cost -the holding cost.
1.3.2. raises holding costs and transaction costs decrease
1.3.3. The optimal batch size is the point where the total cost (combined holding and transaction cost) is lowest. When a company operates near this point, small deviations have little impact.
1.3.4. .
2. Fallacy 4: The sooner the project is started, the sooner it will be finished.
2.1. They tend to exploit any downtime by starting a new project.
2.2. Companies start more projects than they can vigorously pursue,
2.2.1. when the original schedule of a project doubled, the cost and schedule overruns increased by a factor of 16.
2.2.2. .
3. Fallacy 5: The more features we put into a product, the more customers will like it.
3.1. Product-development teams seem to believe that adding features creates value for customers and subtracting them destroys value.
3.1.1. This attitude explains why products are so complicated
3.2. Defining the problem
3.2.1. Articulating the problem that developers will try to solve is the most underrated part of the innovation process.
3.2.2. Teams develop a clear understanding of what their goals are and generate hypotheses that can be tested and refined through experiments.
3.3. Determining what to hide or omit.
3.3.1. Teams are often tempted to show off by producing brilliant technical solutions that amaze their peers and management.
3.3.2. best solutions solve a problem in the simplest way
3.4. Fallacy 4: The sooner the project is started, the sooner it will be finished.
3.5. .
4. Fallacy 1: High utilization of resources will improve performance.
4.1. Projects take longer when people are not working 100% of the time—and therefore, a busy development organization will be faster and more efficient than one that is not as good at utilizing its people.
4.2. High utilization has serious negative side effects, which managers underestimate reasons:
4.2.1. They don’t take into full account the intrinsic variability of development work.
4.2.2. They don’t understand how queues affect economic performance.
4.2.3. In product development, work-in-process inventory is predominantly invisible.
4.2.4. Change the management-control systems.
4.2.5. Selectively increase capacity.
4.2.6. Limit the number of active projects.
4.2.7. Make the work-in-process inventory easier to see.
4.2.8. .
5. Fallacy 3: Our development plan is great; we just need to stick to it.
5.1. we’ve never come across a single product-development project whose requirements remained stable throughout the design process.
5.2. new insights are generated daily and conditions are constantly changing.
5.3. Testing and experimentation reveal what does and doesn’t work, and initial assumptions about costs and value may be disproved.
5.4. .
6. Fallacy 6: We will be more successful if we get it right the first time.
6.1. Practical Guidelines for Overcoming Common Fallacies
6.1.1. 1. Make queues and information flows visible.
6.1.2. 2. Quantify the cost of delays and factor it into your decisions.
6.1.3. 3. Introduce resource slack where utilization is highest.
6.1.4. 4. Shift the focus of control systems from efficiency to response time.
6.1.5. 5. Reduce transaction costs to enable smaller batch sizes and faster feedback.
6.1.6. 6. Experiment with smaller batches; you can easily revert to large batches if this doesn’t work.
6.1.7. 7. Treat the development plan as a hypothesis that will evolve as new information becomes available.
6.1.8. 8. Start projects only when you are ready to make a full commitment.
6.1.9. 9. Aim for simplicity: Ask what features can be deleted, not just what can be added.
6.1.10. 10. Experiment early, rapidly, and frequently, with computer models and physical prototypes, in controlled and real-life customer environments.
6.1.11. 11. Emphasize overlapping and iterative—not linear—process designs.
6.1.12. 12. Focus on quick feedback instead of first-pass success.
6.2. “Strategies for Learning from Failure”
6.2.1. Failure can lead to embarrassment and expose gaps in knowledge, which can undermine individuals’ self-esteem and standing in an organization.
6.3. information technology
6.3.1. make great strides in developing better products in less time and at a lower cost.
6.3.2. .