A list of problems with traditional planning (which I have actually experienced more or less)...what the heck is planning? - III

The purpose of planning is to iteratively arrive at an optimized answer to the ultimate new product development question of what should be built. That is, what capabilities should the product exhibit, in what timeframe, and with which and how many resources? 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. As support of this, consider that nearly two-thirds of projects significantly overrun their cost estimates (Lederer 1992), 64% of the features included in products are rarely or never used (Standish 2002) and the average project exceeds its schedule by 100% (Standish 2001).

Most causes are as follows;

1. Planning by activity, rather than feature.

2. Multitasking more than one can handle.

3. Features, not by priority.

4. Ignoring uncertainty.

5. Estimates turn into commitments.

After going through this list of problems with traditional approaches to planning, it’s no wonder that so many projects are disappointing. Activity-based planning distracts our attention from features, which are the true unit of customer value. A variety of problems then lead to the likelihood of delivering late against a schedule derived from an activity-based plan. 

With good intentions, project team members view multitasking as a possible cure but are eventually forced even further behind schedule because of the hidden costs of multitasking. 

When the project schedule runs out of time, features are inevitably dropped. Because features are developed in the order deemed most efficient by the developers, the dropped features are not necessarily those with the lowest value to users. 

Ignoring uncertainty about exactly what users will eventually want can lead to completing a project on schedule but without including important capabilties that were identified after the plan was created. When we also ignore uncertainty about how the product will be developed it leads to missed activities in the project plan. This, in turn, increases the likelihood that the project will be late, that features will be dropped at the end, or that inappropriate quality tradeoffs may be made. 

Many organizations confuse estimates with commitments. As soon as a team expresses an estimate they are forced to commit to it.