VB Programing support Access Database Microsoft Office VB.Net & SQL Server nev@NevVB.com.au Sydney, Australia (02) 9453-0456 Contact Details 28/01/2012
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:
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.
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).
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 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:
The various completion dates will highlight the imprecise nature of the estimation.
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!