Why function points for IT budget estimates routinely fail
Forecasting time and costs for software development projects is often disturbingly difficult for senior management. Presently, there are several attempts to provide better cost control of software development projects, out of which function point analysis is probably the method most widely used and accepted. Function point analysis is an elegant approach insofar that it is standardized and independent from the technology used. However, function point analysis does not provide a final budget estimate. So, what kind of answer do you get with a function point analysis?
What is the point of using function points?
Function points have been around for quite some time. The method was defined and made public in 1979 by IBM’s Allan Albrecht.. The idea of conducting a function point analysis is to measure the size of a software development project from a user’s perspective. Another objective is to provide a standardized method that can be used irrespective of the technologies or tools employed in the software development project.
Function points can be used internally to allocate resources to development projects or when software applications are purchased from external companies.
What do you measure when you calculate function points?
A function point analysis measures the functional size of a software system, that is, the amount or size of the functions it provides to the user. The functional requirements are categorized into five types, simply explained as:
- External input: process data or control information that comes from outside of the software system, for example business information.
- External output: data that is sent outside of the software system or application, for example reports or files.
- External inquiries: a combination of input and output to retrieve data.
- Internal logical file: inter-related data or control information within the software system, for example customer data.
- External interface file: inter-related data outside of the software system that is used for reference purposes.
Once all the functions are identified and categorized, what is called “unadjusted function points” can be calculated. However, the number of function points must also be adjusted for complexity. This means all functions are classified as simple, average, or complex to calculate the final number of function points.
If I want to conduct a function point estimation, where do I start?
IFPUG, the International Function Point Users Group, maintains the so-called Counting Practices Manual (CPM) that defines the ISO certified industry standard for function point analysis. IFPUG is a non-profit, member-based organization with the purpose of promoting the use of function points for better management of software development.
IFPUG has a certification program for formally recognizing professionals capable of conducting function point estimations. In other words, if you want to conduct a function point estimation for investment purposes, you can hire an external consultant to do the function point estimation for you. Or, if you want to start using function points on a regular basis, for example for resource allocation internally, you can employ people who are trained in function point estimation.
What a function point analysis does not measure
While all this appears sound and well for sizing a software development project, senior management is still left with two fundamental questions that a function point analysis does not really answer: when is project finished? And: how much will it cost? The whole idea with a function point estimation for most senior managers is to get a clear overview of project development time and costs and this is where things start to get complicated.
Whether you hire external consultants for conducting a function point analysis or have this type of competence internally in your organization, a function point estimation is only a step on the road to a sound budget estimate.
No standard price for function points
Once you know the size of a software development project you would think it would be fairly easy to estimate the time and budget necessary to complete it. However, this is far from being the case.
For example, there is no standard price for a function point. The value, or cost, of a function point depends on what you have ordered or planned. For instance, are you hiring a company to only do the coding part of the software development or are you also paying them to analyze system requirements before coding? Will the company supply you with user manuals? Or will you have to create them?
IT consulting agencies do not provide function point price lists as this is proprietary information and varies substantially from one project to another. There are associations like ISBSG that provide benchmarking data for IT projects, however, there is a huge variability in the number of hours spent per function point in the data provided by ISBSG. In fact, the number of hours spent per function point in one project can be several times bigger or smaller than the number of hours of another project, especially if you compare system development projects of different sizes and types and in different industries. Using external benchmarks is thus not a very exact method, to say the least, to get an idea of the budget and time that must be spent on a new software development project.
If function points are used internally, you can apply the function point estimations and costs of previous projects to get an idea of the resources that must be spent on your new project. However, the number of hours spent per function point may vary significantly internally too, especially for different types of projects.
Using historical data could lead you wrong
Another limitation of using historical data from previous projects is that software development is fast-paced and disruptive. Only a few years back, websites were not even optimized for mobile phones. The non-continuous characteristics of IT development means that experiences from previous software development projects of a similar type and size may not be relevant today. Mean reversion bias is yet a typical mistake when estimating IT development, i.e. the tendency to believe that things will even out over time to an “average” level.
IT efficiency, or delivery capacity, is left out of the equation
An underlying obstacle with all the above-mentioned dilemmas in estimating costs and development time of a software project is that function points do not measure the efficiency, or delivery capacity, of the IT team or organization. Without knowing the delivery capacity, it is not really possible to make viable estimates of costs and development time.
Furthermore, the delivery capacity is highly dependent on people. How productive are your IT professionals? The difference between an average IT professional and an IT top performer is, by conservative estimates, about 20 times and this results in a huge spread in productivity. On top of that, add a complex, bureaucratic environment and poor organization of these IT professionals, and your budget estimate may be a far cry from what you will end up paying. Whereas function point analysis is a solid method for estimating the size of a software development project, it is still far from being able to provide solid budget estimate.
Download a chapter for free
In the book Nucleon, Jeppe Hedaa introduces the first formula to measure the factors that hold back an organization’s IT performance, along with the most impactful areas for improvement.
The Black Box of IT with Archbishop of Canterbury, Justin Welby and Jeppe Hedaa – Culture in Organisations
Other than conducting Harry and Meghan’s wedding… What does the Archbishop of Canterbury, Justin Welby, have to say about culture in a multinational organisation? For organisational culture experts: This is an interesting alternative perspective, looking at the...
Team Size in Army Special Forces - The Black Box of IT: What can IT learn from elite soldiers? Watch this interesting conversation with Jørgen Høll, retired Major General and former Commander of the Danish Special Operations. Jørgen Høll and Jeppe Hedaa talk about...
Agile Implementations - The Black Box og IT: A Corona-distance interview with author of Nucleon, Jeppe Hedaa and mBank COO, Krzysztof Dabrowski covering expected productivity gains, investments needed, cultural readiness, implementation time, learning curves,...