Visual Basic Programming Enter a Keyword

Visual Basic Programmer

Access Database
SQL Server Database
MS Word Programming
Website Design

Email: nev@romtech.com.au
Website:     nev.romtech.com.au
Phone: (02) 9453-0456



Skip Navigation Links
Home
All about meExpand All about me
Programming SkillsExpand Programming Skills
Articles of InterestExpand Articles of Interest
Client ProjectsExpand Client Projects
Guest Book

Email for more information

For
Visual Basic Software
Microsoft Office Software
Access Database design
Click
nev@romtech.com.au

Or
Phone Sydney
(02) 9453-0456



Build Date 4/03/2010

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.

Software Development: Safety First 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:

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 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!