Improve Your Software Project Estimations

Accurate estimations ultimately determine the overall success of a software project. Effective project planning and management are difficult to achieve without this.

An over-estimation of project effort may cause: under-utilised resources and consequently, a cost blow-out. Future projects may have been delayed due to the over-estimation of project duration.

Under-estimation causes tighter deadlines. It has been proven that adding more staff to help out, along the way, only delays the project more. The rush to achieve project milestones can result in a loss of quality. Hence, more defects, when the project is implemented.

Use the Comparative Estimating Tool to generate estimates from the ISBSG repository of: software project effort, delivery rate, duration and speed of delivery. The compare to your estimates.

Common questions for estimating

The Early Lifestyle Software Estimation report shows you how to use your project’s size (in FP) to obtain an estimation of the effort required. It also shows you how to develop a chart of the upper and lower ends of the estimation by FP size. Estimate of duration is also included.

The more complete the functional requirements document is, then the more accurate your function point count will be. It is possible to estimate the FP count using the number of logical files. However, this assumes that your application has a standard mix input, outputs and data files.

How does my estimate compare to Industry?

If your team is embarking on a project with new methodology or less experienced resources, it is important to know that your estimate or productivity is not higher than the average productivity of equivalent projects.

Many times we are over-optimistic about what we can achieve. Knowing where you fit against industry data is a reality check. It can also help with justification of the estimate to management.

ISBSG project data reflect the best 25% of the industry. Measurement is integral to well structured development methods, hence produces better productivity. Also those who measure obtain more knowledge about what enables them to be more productive and improve over time.

Comparing to industry can be done in 4 ways.

Submit your productivity measurement to the ISBSG and you will receive a free Project Benchmark Report.

Purchase the ISBSG data and perform your own analysis on how you compare. This will enable you to filter the comparison set to exactly what you want.

Using the portal, refine your selection criteria to obtain the set of data for you to use as a comparison.

Is the industry a relevant factor in productivity. E.g. Military would certainly be relevant.

How old is the data? Methods might have changed considerably since that time.

Is the duration of the projects similar?

These are some of the filters that you would like to use when checking an estimate. Keep in mind that if you filter too much you may end up with a sample size that is not statistically valid.

How accurate is my size measure?

Projects using functional size estimation techniques produce the most accurate estimates. The report, Software Project Estimates – How Accurate Are They?, examines the accuracy of project estimations for 400+ projects from the ISBSG Repository. This report provides insight that can help make decisions on phased development if possible and how to minimize inaccuracies.

Do I have missing functionality in my size measure

It is common to uncover missing functionality midway through the project. This will then require change requests to include the functionality and an obvious discussion as to whether that functionality was inferred in the beginning.

One way to check is to cross-check the categories of functionality against the industry standards. This may show for example very low outputs against industry. This may be correct for that type of application but at least the difference is highlighted.

The example below shows that the project beingestimated has only 10% outputs against the industry data showing 22%. The question is then asked to make sure all the outputs have been identified.

Practical Software Project Estimation, Chapter 6

My initial estimate is too high. Should I buy a package instead?

This is often the first decision to make after the initial shock of the cost estimate. Assuming of course, that a package exists that almost does what you want, the question remains “Will it cost less and be faster?” The report, Package Customisation – What to Expect shows the difference in size, effort, duration, team size and productivity for the projects involving package customisation and those not.