TaskBreakdown

Software estimates are well known to be inaccurate. However, a large portion of the offset can be attributed to poor analysis rather than poor estimation skills. Most skilled developers will be able to get a good idea of how long a task will take given that it is well defined. A task that is well defined is a task for which there are no ambiguities remaining in the description and for which no new discoveries have to be made.

Performing the breakdown of the task includes performing the analysis and parts of the design. Details do not have to be resolved, but the different types of problems that will be encountered must be well understood. The design does not need to be detailed, but dependencies with other systems and the general approach that will be used for the final solution must be chosen.

The objective is to decompose the complete task into sub-items until each of them can be grasped completely. The risks inherent to each part must be identified. In a typical task, very few items contain risky elements. By performing a good breakdown, these risks can be identified and mitigated early in the development, leaving simple and incremental development for the later parts. Not all problems can be measured and expanded using a linear relationship, but by isolating those elements and providing contingency, the overall development effort is much easier to estimate.

To insure the breakdown is complete, it is recommended to use a checklist of commonly forgotten elements. Complex elements are easy to identify in a breakdown because they are difficult to measure. However, missing elements cannot be seen without external support.

Once produced, the breakdown can be used to prioritize the development effort and be used as a series of milestones to track progress. A task falling behind can be identified early on in the project when all the required milestones are defined.