Neville
Silverman

Visual Basic Programmer
Microsoft Access Database Programmer

Custom Built Software 
Sydney, Australia
Phone Australia
(02) 9453-0456

Software Development: Estimating The Contingency Allowance

It always takes longer Junior Programmer

Estimating The Contingency Allowance< It was pointed out on the previous page, that it is not possible for the Visual Basic analyst 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:

The result
Occurring
Underestimate
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 Project 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.

Estimates: 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 allowance is completely subjective. The contingency allowance depends upon the complexity and maturity of the technology, the quality and experience of the Visual Basic 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 allowance. There will be a 5% chance of completion by the estimated date.
  • Half the contingency allowance. There will be a 50% chance of completion by the estimated date.
  • The full contingency allowance. There will be a 95% chance of completion by the estimated date.

The various completion dates will highlight the imprecise nature of the estimation.

Software Cost Benefit Analysis

The automation must provide benefits at least equal to the estimated development costs. If, after allowing for the full contingency allowance, 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!