Software Development
The Contingency Allowance
Westheimer's Rule
To estimate the time it makes to do a task, estimate the time you think it should
take,
multiply by two, and change the unit of measure to the next highest unit.
Thus we allocate two days for a one-hour task.
It was pointed out on the previous page, that it is not possible for the developer
to provide any certainty in an estimation.
To demonstrate, let us take a simple, but realistic example. The development time
for a small project is estimated to be 6 hours. It has reasonably taken into account
all development factors in providing the required software functionality (inputs,
outputs, function points, user requirements, etc, etc).
This is the likely outcome for such a project:
|
On time
|
5%
|
0%
|
|
1 hour late
|
10%
|
17%
|
|
2 hours late
|
20%
|
33%
|
|
3 hours late
|
40%
|
50%
|
|
4 hours late
|
20%
|
67%
|
|
5 hours late
|
5%
|
83%
|
Optimistic Estimations
These figures highlight the problem of estimation. The initial estimated complete
date is based on a wildly optimistic view. The task has only a 5% chance of being
completed by estimated completion date. I would not bet my life (or my career) on
such an estimate.
The Expanding Funnel of Doubt
A Contingency Allowance must be applied to the initial estimate, to stand any chance
of being achieved. The Contingency Allowance must take into account the unpredictable
nature of complex projects.
The chart demonstrates that the more complex the project, the more the funnel of
doubt expands. In other words, the completion date becomes less and less predictable.
Depending upon the complexity of the project, completion times (in red) range from
2 to 6 times longer than the estimated time (in blue).
Setting the Contingency Allowance
The estimation of the contingency factor is completely subjective. The contingency
factor depends upon the complexity and maturity of the technology, the quality and
experience of the team, the resources available, and the firmness of the requirements.
In my experience, a contingency factor of 4 should be used, for an enthusiastic
team but with little experience, and user requirements in a state of flux. Using
this contingency factor, the projects under my control came in, on time, with hardly
a day to spare!
Management can then be supplied with a range of estimated completion dates, calculated
with:
- No contingency factor. There will be a 5% chance of completion by the estimated
date.
- Half the contingency factor. There will be a 50% chance of completion by the estimated
date.
- The full contingency factor. There will be a 95% chance of completion by the estimated
date.
The various completion dates will highlight the imprecise nature of the estimation.
Cost Benefit Analysis
The automation must provide benefits at least equal to the estimated development
costs. If, after allowing for the full contingency factor, the project cannot be
cost justified, the project scope should be re-examined. It is then back to the
drawing board, and a less ambitious project designed. Determine what tasks are really
essential and affordable. Large projects should be broken down into smaller, independent
projects. And then start the estimation process again.
The result will be a project with a greater chance of success, and a shorter completion
time. No villains, only heroes!
|