Improve Your Software Project Estimations

Accurate estimations 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 be delayed due to the over-estimation of the current project duration.

Under-estimation causes tighter deadlines.  It has been proven that adding more staff to help out, 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.

Read the Use Case: Independent Estimate/Supplier Proposal Review.  This is a more detailed study on the importance of accurate estimates.

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. Use the Productivity Data Query Tool to  generate estimates from the ISBSG repository for: software project effort, delivery rate, duration and speed of delivery.

isbsg resources

Resources available

Practical Software Project Estimation book – Accurately forecast the size, cost, and schedule of software projects. Get expert advice on generating accurate estimates, minimising risks, and planning and managing projects. Valuable appendices provide estimation equations, delivery rate tables, and the ISBSG Repository demographics.

The Project Estimation Report Pack contains 3 reports that provide valuable information that will assist you in planning your project.

  • Early Lifecycle Project Estimation
  • Project Duration by Size and Effort
  • Software Project Estimates – How Accurate Are They?

Estimation Questions

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.
      • Use ISBSG Reality Check tool to compare your project to industry.  This comes free with your Web Subscription.

Are my comparisons accurate?

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

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.