Estimating with FPA
Estimating is the process of predicting the most realistic use of effort required to develop or maintain software based on uncertain and/or incomplete input. Typically, effort estimates are over-optimistic and there is a strong over-confidence in their accuracy.
A way to cope with this is to use FPA as basis of the estimating process. As FPA is an ISO certified size standard, uncertainty is reduced and this supports the estimating process to become more reliable. However, be aware that the estimating process involves a lot more than just performing a function point count.
There are two possibilities to use FPA for estimating:
- The organization knows and uses its own historic productivity rates, or
- The organization uses the relevant mean productivity rate of its industry segment (the benchmark).
Below we explain both in more detail.
Historic productivity rate
When using FPA in the estimating process the historic productivity rates of the organization are very useful. The productivity rate or project delivery rate is defined as follows:
“the number of development hours needed on an average to realize one function point”.
These productivity rates are based upon experiences in earlier, completed projects. This has the huge advantage that the estimated budget for a project is based on the actual performance of the organization in similar projects in the past.
This is the way it works in a nutshell:
- Calculate the functional size of the project in numbers of function points;
- Determine the expected project productivity rate:
- Determine the standard productivity rate for the development environment;
- Determine the expected project productivity rate based on special circumstances;
- Multiply the number of function points by the expected project productivity rate.
The result provides a first basis for the project budget;
- One should add hours for activities that are not included in the standard productivity rate.
See the Four steps of estimating using FPA for the details of this method.
An simple elaborated example is given in Example of estimating using FPA.
How to estimate with FPA if the productivity rate is not available
Sometimes the organizations productivity rate is not available. This will be the case if an organization starts using FPA. In that case there is not yet any history of the productivity rate of its projects. The same applies in cases of outsourcing when the organization receives a proposal from a supplier. Often the suppliers productivity rate is unknown.
In both cases it is advisable to start with using industry benchmarks. However, Nesma advises to start recording your own or the suppliers historic productivity rate a.s.a.p., because that is more reliable than the industry benchmarks.
Devils triangle: Estimating is more than calculating hours
Estimating hours and cost is not the whole story. One should not forget the quality of the product to be delivered, and the scheduled duration of the work. A well-known visualization of the factors that impact a software project estimate is the ‘project triangle’:
Within this triangle there are four core metrics: size of the product, cost of the product, delivery time and product quality at delivery.
All these core metrics influence each other. Therefore there is no such thing as just one good outcome for an estimation. That is the reason the ‘project triangle’ is also called the ‘devils triangle’. This has a large impact on the estimate. Different sets of assumed values of the core metrics will result in different outcomes for the projects duration, quality and cost.
There will be a great number of scenarios for the execution of a project.
However, this is an opportunity rather than a problem. Read more at the page Devils Triangle.
The devils triangle is the main reason that tooling is recommended to be used when estimating.
The efficiency and reliability of the estimating process can be significantly improved by using estimating tools that have been designed specifically to support the estimating process.
Estimating tools also facilitate the creation of “what if” scenarios. These scenarios are used to optimize a project. In the different scenarios different values of the core metrics are applied. Comparison of the scenarios results in the optimum choice, aligned with the priorities of the customer.
A further advantage of such tools is that they usually also provide easy access to benchmark data. This helps to judge the estimating outcome on validity and competitiveness.
The picture below gives an example of such scenarios.
The most well-known tools are (in alphabetical order):
- Galorath SEER Estimating tool
- ISBSG Estimating tool
- METRICS QUEST Estimation tooling
- PRICE TruePlanning framework
- QSM SLIM Estimating tool.
See the sites of their suppliers for more information.
Basis of Estimate
An estimate should be a correct prediction for the needed budget of a project, especially in case of outsourcing of projects to external providers.
When outsourcing, a client needs assurance that the suppliers estimate is fair and sufficient for the job. Also, surprises during the execution of the project should be prevented as much as possible. Therefore the estimate must pay explicit attention to this subject.
To this end Nesma has created a document that describes the content of a well written estimate: the Basis of Estimate (BOE).
Main purpose of the BOE: when used by both client and suppler organizations it provides a mutually understood common standard to write an estimate.
The BOE has also been presented to the AACE International’s Total Cost Management (TCM) Framework. AACE International has accepted it and included it as recommended practice.
AACE International identifies the BOE as a required component of an IT cost estimate.
By this the BOE has now been recognized as a worldwide standard for estimation.
The BOE can be found here.
More on the content of the BOE can he found in the page Basis of Estimate.