Why Traditional Planning Fails in Software Development
The purpose of planning is to arrive iteratively at an optimized answer to the ultimate new product development question of what should be developed. That is, what capabilities should the product exhibit, in what timeframe, and with which and how many resources?
Planning supports all of these objectives by reducing uncertainty about what the product should be, by supporting better decision making, by establishing trust, and by conveying information.
Unfortunately, the traditional ways in which we plan projects often let us down. In answering the combined scope/schedule/resources question for a new product, our traditional planning processes do not always lead to very satisfactory answers and products.
Here are some interesting facts concerning planning.
1. Nearly two-thirds of projects significantly overrun their cost estimates.
2. Sixty-four percent of the features included in products are rarely or never used.
3. The average project exceeds its schedule by 100%.
A critical problem with traditional approaches to planning is that they focus on the completion of activities rather than on the delivery of features. A traditionally managed project’s Gantt chart or work breakdown structure identifies the activities that will be performed. This becomes how we measure the progress of the team. A first problem with activity-based planning is that customers get no value from the completion of activities. Features are the unit of customer value. Planning should be at the level of features, not activities.
A second problem occurs after a traditional schedule has been created and is being reviewed. When we review a schedule showing activities, we do so looking for forgotten activities rather than for missing features.