Software Development: Avoiding Disasters

[bholus10]

Software Development: Avoiding Disasters

"Prediction is very difficult, especially about the future"

Horror stories abound with news of projects that result in software disasters. The statistics are frightening. Billions of dollars have been wasted on software projects with cost overruns, that finish late, do not meet user expectations, and are outdated before they commence.

This used to relate only to mainframe projects where the scope was large and the software complex. With the powerful Servers and PCs that are available today, large and sophisticated systems are being created.

With sophistication comes complexity – these projects are now just as prone to a software disaster as with a mainframe.

Estimating how long a software development project should take is not an exact science. It involves personal experience and guesswork. See the numerous articles on Kolmogorov and the "Large Limits to Software Estimation".

Management requirements

Management, quite rightly, require a definite timetable for development. They need to be able to determine the costs involved, and the resources that are needed

As the developer cannot provide any degree of certainty, all estimates need to be made conservatively. Allowance should be made for the inexact nature of software predictions. And this needs to be communicated to management.

It is not unknown for management to attempt to extract the most optimistic of estimated times. Worse still, the phrase "estimated completion date" will somehow be understood as a "definite completion date". A different approach is needed – one that is not open to misinterpretation.

Optimistic Estimations

Human beings are optimistic creatures. No matter how bleak reality is, there is always a bright side, a silver lining, a Pollyanna-esc view to be held.

This is especially true of software estimation. If all goes exactly as predicted, the project will come in on time. Unfortunately, 95% of the time, unanticipated problems will cause a delay.

"Oh, it’s just a few hours work" – frequently turns into several days’ hard labour. Who has not, ever, been guilty of this? The "few hours work" may have taken into account all the predictable factors.

But then there is the unpredictable – when a routine just will not work. Is it the network? Or a network card? Or a faulty network connection? Has the latest service pack been installed? Is the user doing something silly?

For a small task, the consequences of an underestimate may be trifling. But for a large project, when the very existence of a company is threatened, much more conservative estimates are needed.

What is required is a contingency factor to be applied to the initial "most reasonable" time estimate.

The contingency factor should, at a minimum, result in a 50% chance of the project completing on schedule. This means that half the time the project estimator will be a hero, and half the time a villain.

A more professional choice would be a contingency factor resulting in success 95% of the time. Of course the estimated completion time would be dramatically increased.

The Expanding Funnel of Doubt

The Contingency Factor must take into account the unpredictable
nature of complex projects.

Similar Threads:

• Sap software + installation tutorial
• Open Source vs.Closed Source Software: The Great Debate

[bholus10]

Software Development: Avoiding Disasters

"Prediction is very difficult, especially about the future"

Horror stories abound with news of projects that result in software disasters. The statistics are frightening. Billions of dollars have been wasted on software projects with cost overruns, that finish late, do not meet user expectations, and are outdated before they commence.

This used to relate only to mainframe projects where the scope was large and the software complex. With the powerful Servers and PCs that are available today, large and sophisticated systems are being created. With sophistication comes complexity – these projects are now just as prone to a software disaster as with a mainframe.

Estimating how long a software development project should take is not an exact science. It involves personal experience and guesswork. See the numerous articles on Kolmogorov and the "Large Limits to Software Estimation".

Management requirements

Management, quite rightly, require a definite timetable for development. They need to be able to determine the costs involved, and the resources that are needed

As the developer cannot provide any degree of certainty, all estimates need to be made conservatively. Allowance should be made for the inexact nature of software predictions. And this needs to be communicated to management.

It is not unknown for management to attempt to extract the most optimistic of estimated times. Worse still, the phrase "estimated completion date" will somehow be understood as a "definite completion date". A different approach is needed – one that is not open to misinterpretation.

Optimistic Estimations

Human beings are optimistic creatures. No matter how bleak reality is, there is always a bright side, a silver lining, a Pollyanna-esc view to be held.

This is especially true of software estimation. If all goes exactly as predicted, the project will come in on time. Unfortunately, 95% of the time, unanticipated problems will cause a delay.

"Oh, it’s just a few hours work" – frequently turns into several days’ hard labour. Who has not, ever, been guilty of this? The "few hours work" may have taken into account all the predictable factors.

But then there is the unpredictable – when a routine just will not work. Is it the network? Or a network card? Or a faulty network connection? Has the latest service pack been installed? Is the user doing something silly?

For a small task, the consequences of an underestimate may be trifling. But for a large project, when the very existence of a company is threatened, much more conservative estimates are needed.

What is required is a contingency factor to be applied to the initial "most reasonable" time estimate. The contingency factor should, at a minimum, result in a 50% chance of the project completing on schedule. This means that half the time the project estimator will be a hero, and half the time a villain.

A more professional choice would be a contingency factor resulting in success 95% of the time. Of course the estimated completion time would be dramatically increased.

The Expanding Funnel of Doubt

The Contingency Factor 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).

[bholus10]

Setting the Contingency Factor

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!

[OrbenBoben]

I prefer to use both the services of developers in cases where I need software from scratch, and ready-made solutions, for example, processmix.com/cases/regular-cross-sell-offer-calculation/. For working with lending, issuing additional loans, this is an excellent solution. This is an effective strategy to help retain customers by providing them with a variety of services.