One of the main problems in current ICT projects is to determine the economic value of project activities using mostly (or solely) the deliverables produced, considering such projects as something repeatable and applying the 'economies of scale' principles. But looking to the inside of those projects, most of them are “artisanal” projects, unique to a specific customer for a specific need and many variables should be taken into account in order to provide in an estimation the right 'quantity' to be produced (also in terms of outcomes), effort and costs (to be translated into a final price) considering all the activities in scope to such project, not only those strictly devoted to produce the project deliverables. This paper will discuss the current situation and a simple but effective solution to such issues using benchmarking and data management best practices, overcoming also bad outsourcing practices, called the 'ABC Model', providing an example with objective evidence.
Each economic market has its own rules and peculiarities and thus it’s difficult to apply the same,
exact rules, principles, and best practices to another kind of business. Even if what said seems to
be a ‘golden rule’, in ICT projects seems from many years that – whatever the kind of project,
context, technology applied, economic conditions according to the country where such project
will be realized, and more – there could be the possibility to apply ‘economies of scale’ to projects
different each other only because the final main deliverable is a software product. Moving from
the customers’ need of asking more objective ways to determine the amount of work (that’s effort,
no matter if measured by man-days or man-hours) instead of using only (or mostly) effort and
costs estimations by experience, the usage of measures was introduced in ICT Contract
Management before using Lines of Code (LOCs) and then Function Points (FPs – several ISO
standards currently active and available) as the ‘objective quantity’ that should have been used
for giving to those ‘units’ an economical value (e.g. [
__________________ Proceedings Acronym: IWSM Mensura 2023, September 14–15, 2023, Rome, Italy luigi.buglione@dxc.com (L. Buglione); © 2023 Copyright for this paper by its authors.
Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR Workshop Proceedings (CEUR-WS.org)
The starting point in IBM for asking in 1975 to Dr. Allan Albrecht to create what was named Function Point Analysis (FPA) in 1979 was to overcome some drawbacks when using Lines of Code (LOCs) from a technical and economic viewpoint. Till the ‘70s, LOCs were used as the main measure in ICT projects for ‘sizing’ a software, being a sort of quantitative unit of measure, but unfortunately not sizing the number of functionalities to produce, but only the number of executable LOCs for producing such functionalities. But they were easy to be counted. Thus, their “productivity paradox”, as stressed a few years later by Capers Jones, was that paradoxically the more the LOCs with an older technology/programming language, the more the effort and final price related to that software project but the better in terms of productivity (LOC/effort) and unit cost (LOC/monetary unit) that using a more modern technology/programming language that would reduce the overall effort and costs but would paradoxically increase the unit price and the unit cost, being less the formal number of LOCs.
That’s why Function Points (FPs) started to make a step beyond this issue, because they cancel
this paradox because the unit cost (FP/monetary unit) and the productivity (FP/effort) – being
the number of FPs the same even such functionalities were (approximately) implemented with
different technologies. This example was presented here [
But what at that time were not considered enough was a couple of things:
• FPs and LOCs are product measures, not measuring the whole project (that’s a larger
container that the products/outputs/deliverables, that can be more than the solely software
product, e.g. a user manual), as logically shown in [
Considering those couple of ‘issues’ mentioned before, what happened along time was that FP
(that’s simply a quantity) became a ‘price’ even if each software project – that’s original each time
–changed requirements and thus functionalities and the final deliverables and its inner, related
quality – cannot be considered as a sort of ‘repeatable product’ with a sort of ‘standard’ cost (for
the providers) and price (for the customer). The “price per FP” were including ALL the project
costs, not only the ones related to the deployment of FURs but also what related to non-functional
requirements (NFRs) and project-related activities (PRJ) plus all the fixed costs (e.g. travels,
licenses costs, etc.), simplifying too much the way to calculate project economics. In fact, as in
Figure 2, in a typical development project the most of the effort (A-type; FURs) is deployed by the
project roles costing less (e.g. analysts-programmers-testers), followed by the B-type effort
(NFRs) performed by professionals costing a bit more than the A-type ones (e.g. systemists, DBAs,
architects, …), with less working hours but costing more, till the C-type effort (PRJs) performed
again by professionals (e.g. project managers, service managers, measurement specialists, team
leaders, …) costing more than the previous two groups [
Again, the two more diffused FSM-based standard methods, IFPUG (ISO/IEC 20926) and
COSMIC (ISO/IEC 19761) were thought to be in a 1:1 relation applying their own unit of
measures, creating further confusion in the market among different units of measures expressing
different efforts and costs. Some sources would like to propose the “price per FP” as paid a lot of
USD/FP (e.g. [
Thus, the basic question is still: are we sure that a “price per FP” is the proper way to continue to follow for pricing ICT contracts? The question is very relevant because several companies – no matter is customers or providers – are concretely thinking that contractual issues would be related to measures and not to the (bad) way measures were (and are still) applied to contracts…functional product measures cannot size the entire project scope and daily costs cannot be the same in different countries for any type of software…development and maintenance and enhancement projects have different productivity levels…thus which could be a possible general solution valid for ALL projects, not only in the ICT domain?
As said, a project plan is based on an affordable effort and duration estimated based on a solid measurement program. Paying a project by the expected amount of ‘units’ – where each project is new and not the exact copy for another previous one – cannot be the solution. The solution, from our viewpoint and experience, as in Figure 3 can be expressed by the “ABC Model”, that’s simply a way to “come back to the future”, with a 4-step flow proposing a series of yet existing techniques and criteria but in an organized and logical way. Note: “ABC” is not an acronym bit a title for expressing a simple, basic but effective way to manage estimations citing the three first letters of the alphabet.
The Q→T→C (Quantity → Time → Cost) logical flow from the “ABC Schema” moves from the
quantification of user requirements (UR) into measures by the three streams (A-FUR, B-NFR,
CPRJ) that – divided by the proper nominal productivity value(s) – will drive to derive the final
project effort. The whole project effort, after creating the project plan and schedule, will drive to
the right calculation of costs, margins, and final prices according to the real project schedule and
the other project constraints to be considered for the specific case [
→ →
Figure 4: The Q T C flow: from UR to T (Time) and from T (Time) to C (Costs/Prices)
When applying the steps from the “ABC Model”, here some assumptions:
• Step #1 – Determine the type of project/activity/context…:
o Project Phase: Development [
Step#4 – Determine the appropriate costs, margins and revenues (by context): o Price/FP: 100 EUR/FP
Note: the example is using values referred to IFPUG FPA v4.3.1, since currently the FSM
method mostly used in Italy in Public Administration contracts and Euros (€) as the related
currency. But the same exercise can be done with any other FSM method, using its own
productivity/PDR specific data and other currencies. To present the three hypotheses to be
compared, let’s assume the 2023 daily team mix costs for COBOL [
The first hypothesis is to use only FPs as the solely cost driver.
The difference per m-d would reveal a negative difference for a COBOL implementation, while an extra-cost for a PowerBI/PowerApps. Note that productivities cannot be assumed always but must be set up using organizations’ historical data. Assuming a ‘standard’ productivity level, whatever the technology/PLs applied would lead to potentially large over/underestimates.
Second hypothesis, as typically applied in many ICT contracts, is about the application of payments by a standard, average daily rate for the whole team mix, no matter the distribution of effort by requirement types, as in Figure 2:
The difference per m-d in this case would be reduced, in both cases with negative values, but with smaller variabilities than in Hp1. The overall price for COBOL seems to be very high for a high number of man-days. Here the attention point would be to better explore the effort distribution by requirement types (and related FTEs), as in Hp3.
4.2.3. Hp3 - Cost driver: m-d (balanced daily rates using the ABC schema) Last hypothesis uses a distribution of effort (and related daily costs) balanced by the ABC requirement types:
This last scenario, considering the context (country, economical parameters, business sector, etc.) seems to be the best one, using one or more UoMs as the input for determining efforts and costs and not directly ‘quantities’ as the main drivers, not being such kind of projects ‘repeatableat-all’, thus applying a sort of ‘economy of scale’ mechanism.
As said in the FP arena, FPs are a sort of “square meters”, but they cannot have a ‘standard cost/price’…it’d be like to affirm that the cost/square meter for a floor would be the same when choosing between different materials (e.g. marble, tiles, parquet, …). In our analogy, the materials are the ICT project technologies, and they strongly impact on the final project efforts and costs.
Another variable to mention – of course – is the expected duration for the project and many other variables related to the project entity, not the product and not again only about its functional side. Even if the price per FP would be very high (e.g. 1000+ €/FP) in order to satisfy the economic side, the effort related to NFRs and PRJ related requirements (the B/C types in the ABC schema) would represent a significant effort making difficult to accomplish established deadlines. Finally, professionals dealing with some old fashion/legacy PLs can/could cost per day more than more modern and productive PLs and it could create a further paradox when paying a project “per FP” and not “per m/d”.
Thus, why still using a “price per FP” and not – “coming back to the future” a price/m-day (or
price per m/hrs) derived from a proper usage of measures and related historical productivities
for a certain software domain that will drive to the right effort approximation to be used for
planning and scheduling the project? Of course, the daily team cost should be applied according
to the place where it will be worked (e.g. India, Brasil, etc.), not looking to other countries’
economies and daily tariffs.
5. Conclusions and Next Steps
“You cannot control what you cannot measure” is a well-known motto by Tom Demarco [
The drivers on which betting more for improving good contract management practice will be:
• proper and continual project data gathering that will assure updated productivity data over
time (not assuming external, uncontrolled data), as asked also by the ISO 15939 measurement
process [
According to the ITIL4 glossary [
Technology; Partners & Suppliers; Value Streams & Processes). “Everything should be made as simple as possible, but not simpler” (Albert Einstein)
123 Schema