Improve Your Software Project Estimations

Accurate estimations determine the overall success of a software project. They are essential for effective project planning and management.

Over-estimation of project effort may cause: under-utilised resources and a consequent cost blow-out. Future projects may be delayed due to the over-estimation of the current project duration.

Under-estimation causes tighter deadlines.  It has been proven that adding more resources 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.

How are more accurate estimations achieved?

It is a common practice to have at least one, or preferably two, cross-checks for your project estimates.

Complete Functional Requirements documentation is required for accurate estimations.  Management of scope changes is important to ensure estimate changes are well-controlled.

ISBSG can help you to cross-check your estimates. See our Resources section below.

isbsg resources

Resources available

  • The ISBSG Report Subscription includes 3 reports that contain valuable information that will assist you in planning your project.  They are:
    – Early Lifecycle Project Estimation
    – Project Duration by Size and Effort
    – Software Project Estimates – How Accurate Are They?
  • Find out more about Report Subscription

Estimation Questions

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.  An estimation of duration is also included. For more details, see Report Subscriptions.

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.

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 2 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.

Questions to consider when selecting projects to compare against:

  • What phases of effort have been included?
  • It is a similar team size?
  • Is the language similar in terms of effort in usage and expertise?
  • What methodology has been used for development?
  • 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 can use when checking an estimate.  Keep in mind that if you filter too much you may end up with a sample size that is too small and not statistically valid.

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.  See Report Subscriptions for more details.

It is possible to uncover missing functionality midway through the project.  This would 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 being estimated has only 10% outputs against the industry data showing 22%.  The question is then asked – have all outputs have been identified?

Practical Software Project Estimation, Chapter 6

Practical Software Project Estimation, Chapter 6

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 that do/don’t have package customisation.  For more details see Report Subscriptions.

isbsg estimating