Book Review Part 2: The Principles of Product Development FLOW: Second Generation Lean Product Development by Donald G. Reinertsen

In a previous blog article, I mentioned how I was getting back to my programming roots and reading The Principles of Product Development FLOW: Second Generation Lean Product Development by Donald G. Reinertsen. My plan is to review each chapter. I have already posted my review of Chapter 1. Here is my review of Chapter 2, "The Economic View."

The second chapter calls out 21 principles to get at the heart of the matter which is to make decisions regarding software development based on how it impacts the profitability of the company.

1. Take actions on software development projects by quantifying and comparing the cost of taking them versus the cost of not taking them.

2. Since it is impossible to change just one thing at a time, perform sensitivity analyses to quantify how changing one aspect of a software development project affects the other aspects of the project.

3. If you can only quantify one aspect on a software development project, quantify the cost of delay associated with each action on the project.

4. When measuring any aspect of a software development project, be sure to quantify in terms of value to the customer instead of value to the organization.

5. Measure progress on the software development project instead of the activity (or inactivity) of the project members.

6. Most aspects of software development projects have "U-curve" characteristics, so it is not necessary to reach the optimal (i.e., best) for any aspect as substantial improvement is typically sufficient.

7. When managing any project, decisively reaching even imperfect answers improves decision making.

8. Contrary to the Pareto principle that suggests that 80% of a project's leverage lies in 20% of the project's decisions, correctly managing the numerous small decisions (the 80%) can make a significant difference.

9. Evaluation of a project's economics is an ongoing process that should occur on a continuous basis.

10. Opportunities vanish swiftly so economic choices are more valuable when made quickly.

11. When faced with a decision that appears to only have bad alternatives, break the alternatives down into greater detail so hidden benefits of the alternatives come to light. Use those benefits to pick an alternative.

12. Allow software developers to make their own tradeoffs up to a predetermined threshold. After that, escalate decision-making to the next level of management which has a higher threshold. The threshold process can be applied to all levels within an organization.

13. Establish a set of decision-making rules for a project so that decision making can be aligned yet spread out among those who are directly responsible for the software development.

14. Instead of project managers doling out resources based on first to ask or a requestor's persuasive capabilities, use a supply/demand model so that project members who reap the benefits also bear the costs.

15. Rather than front-load all decisions on a project or delay every decision as long as possible, determine the economic impact of each decision and use that information to determine its optimal timing.

16. When making content versus schedule trade-offs, be sure to determine the marginal (i.e., added) cost, not the total cost, of adding a new feature to a project versus the marginal benefit.

17. Consider money to be spent in decision-making instead of money already spent.

18. The cost of determining whether or not to take an action on a project should not exceed the cost of actually performing the action.

19. The cost associated with creating project alternatives should not exceed the cost of not taking the project action.

20. A high probability of failure does not mean bad economics.

21. When reviewing project actions with upper levels of management, it is possible to speak in financial terms since this methodology proposes that everything is quantified in customer value.

Back in the day, AutoCAD R13 was not our finest release. The project was over budget, slow, consumed too much memory, and full of bugs. The product was improved through a series of correction releases. For AutoCAD R14, we were determined for history not to repeat itself. During the project, when anyone ever asked "When will AutoCAD R14 release?", instead of supplying a date, the correct answer was "When it's ready." So despite what this book professes about managing projects based on profitability, AutoCAD R14 was all about quality.

Economic principles are alive in the lab.