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.
At the heart of modern IT departments are specialized teams that combine different competencies which solve the company's projects. But how do you organize the most effective teams? Over the years, there have been many suggestions for the perfect model, but there...
The Black Box of IT with Thomas Nehring, Peter Debracy and Jeppe Hedaa – Decommissioning Legacy Systems
Decommissioning Legacy Systems - The Black Box of IT: A candid conversation with Executive Advisor Thomas Nehring and Principal Decommissioning Consultant Peter Debracy. Part 4 of my short series on opening the Black Box of Complex Systems...
Estimation - The Black Box of IT: A candid conversation with Christine Green, one of this worlds most experienced Estimation specialists, about how we can predict time and costs precisely in IT projects. Part 3 of my short series on opening the Black Box of Complex...