Getting all the way

A common planning strategy is to determine pace by looking at the total amount of work required and divide it by the amount of time available. This has some merit for work that is an aggregate of identical and independent small tasks. If you need to walk four kilometers in one hour it’s a pretty good strategy to make sure that in the first quarter you have walked one kilometer, and to sustain that pace. With the addition of some small margin of error this is frequently used for many tasks.

When the goal we want to achieve is of even slightly more complex nature and the individual work items have dependencies to each other and require specific competence or new technology to be applied this strategy frequently fails. It is very easy to underestimate the complexity of the most difficult parts and see the completion of less complex tasks as early indicators of good progress. A chart displaying that fifty percent of the tasks are completed at half of the time available means nothing if those were tasks of lower complexity that required significantly less effort.

This planning fallacy is very frequently the case of repeated failures to complete software projects. If we completed eighty percent of the project in eight months we only have two more months to go right? Two months later still ten percent remains. So the previous ten percent took two months instead of one, but surely we could finish the remaining ten percent in another two months? Wrong! The remaining ten percent could take any amount of time, worst case they could even be impossible with the current technology or competence available. This is similar to planning to climb Mount Everest by using half the time available to hike to the first base camp (half the height of the peak) and then assume that you can hike the second half as easily and quickly.

Although there are few generic strategies available to solve this problem one obvious way is to identify the most complex and time consuming tasks first and start with them as soon as dependencies for them are completed. This will at least not leave those tasks for last and provide earlier information on how to solve them. Another strategy that might at least open up for some honest discussion is to be able to spot when this poor method is applied to the wrong type of problems, to at least be aware of the potential risk.

Sadly I see this error in way too many and far too important endeavours of incredibly complex nature.