Planning

Preparation

• quality at the beginning (design)
• quality in the middle (construction)
• quality at the end (testing)
• Preparation is the goal of risk reduction.

Causes of Incomplete Preparation

• Lack of experience.
• Lack of self-restraint on the part of developers.
• Managers don’t understand.

Arguments for Planning

• The most common project risks in software development are poor requirements and poor project planning.

Appeal to Logic

• Avoids expensive, incorrect choices.
• From a management point of view, planning means determining the amount of time, number of people, and number of computers the project will need.
• From a technical point of view, planning means understanding what you want to build so that you don’t waste money building the wrong thing.

Appeal to Analogy

• When you build other things (e.g. a house), you need to plan before construction.
  • If you are planning a highly iterative project, you will need to identify the critical requirements and architectural elements that apply to each piece you’re constructing before you begin construction.
  • A builder who is building a housing development doesn’t need to know every detail of every house in the development before beginning construction on the first house.
• You don’t start decorating the Christmas tree until you’ve put it in the stand.
• You don’t start a fire until you’ve opened the flue. You don’t go on a long trip with an empty tank of gas.
• You don’t get dressed before you take a shower.
• You don’t put your shoes on before your socks.

Appeal to Data

• Studies over the last 25 years have proven conclusively that it pays to do things right the first time; unnecessary changes are expensive.
• Errors caught at the end of construction or after release are 10-100 times more expensive.
• On average debugging and associated reword takes ~50% of the time spend in a typical development cycle.