Here, we will answer the following questions:
- What are the main characteristics of an efficient abacus?
- What are the common pitfalls to avoid?
What are the main characteristics of an efficient abacus?
Correlation with the effort:
It is the first mandatory characteristic. If the abacus does not correlate with the effort, how can one deduce the cost of each component? The correlation must be established. Needless to say it is the case of standard abacuses (IFPUG, COSMIC, etc.). Nonetheless, some purchaser-or-supplier abacuses are not related with the effort. In-house abacuses often rely on the judgment of an expert and poor correlations are pretty common.
If the abacus generates a far-fetched amount of effort for some works, the loss would either be for the purchaser or the supplier. That situation could deteriorate the relationship.
Function over technique:
A company who outsources the development and maintenance of applications will inevitably experience a loss in development skills. In that case, how can one negotiate the supplier’s price quotations if the abacus components are technical components. In other words, those components are closely related to software developments.
Furthermore, if the component is too technical, the supplier might be tempted to deliver unnecessary technical components. For instance, if the abacus relies on the delivered number of lines of code, the supplier may be tempted to deliver more lines than required.
It is therefore recommended to rely on a functional abacus which consists in calculating the functional size of the user order, independently from the coding dimension. For instance, we will mention inputs, outputs, reports with different complexity levels.
Simplicity and documentation:
The number of components must me downsized. The more numerous the components, the more difficult the understanding of the abacus and the monitoring of the quotes.
All the discussed cases will broaden the abacus documentation.
You should avoid to increase the number of components.
It is recommended to choose a standard abacus relying on Function Points. There are several abacuses such as IFPUG (International Function Point User Group), COSMIC (Common Software Measurement International Consortium), SiFP (Simple Function Point), NESMA, etc. They are already defined, the defects have been corrected by the users. They are ready to be use.
Those standard abacuses offer several advantages. They have been validated by numerous instances, are used worldwide and are documented in several languages. Independent experts are available, as well as benchmarking data. Furthermore, those standards are correlated with the effort.
The quality of an abacus relies on its clarity. It must not be ambiguous. If some ambiguities persist concerning the components or the application cases, never-ending discussions may occur between the client and the supplier. The cost of the quotation and its monitoring will be higher than expected. The client/supplier relationship may suffer from the situation.
When a case remains unclear, it is recommended to rely on a external and independent person whose expertise is proven. But it is difficult to find an expert who is available. You can first raise questions on a forum gathering several experts.
Automation (if possible):
The automation of the sizing process will prevent discussions and controls thanks to an independent mechanism. That is the best solution, but the process may only be automated in some cases, provided the quality of the documentation allows it.
What are the common pitfalls to avoid?
“In-house” abacus vs. standard abacus:
If the abacus comes from one or another stakeholder, the relation may me biased since the one who knows best the abacus is better prepared to for the negotiation. The stakeholder who did not provide the abacus can appoint an expert who will be trained to offset that imbalance.
If a stakeholder offers to use his abacus, you better make sure the latter is correlated with the effort.
If the abacus is too technical (e.i. too close to the coding), the risk is two-folded.
- The client loses little by little its expertise in terms of software development, but he will still have to discuss the technical aspects with actual experts. The supplier will benefit from the mismatch between skills.
- It is then more difficult to control price quotations and the client will have a hard time negotiating them.
Make sure that the granularity of the component detection is clear. In other words, what is the elementary process level we will refer to to count the abacus components? If the granularity is poorly defined, there might be a risk of fractalization. In other words, the inappropriate decomposition of the elementary process in sub-processes reveals a multitude of abacus components and thus causes the explosion of labor cost.
The price quotations must be self-explanatory. In other words, the extract of the client order that explains the detection of one or several abacus components must appear in the quote. The references of the extract must be mentioned (page, paragraph).
That traceability is mandatory if you want to simplify or automate the control of price quotations.
Increase in productivity clause:
If the outsourcing contract covers several years, the supplier will get acquainted with the context and the applications during the first year and will become more efficient over the following years. That is the reason why contracts mention the increase in productivity phenomenon.
Be careful not to mistake the increase in productivity (to produce more for the same price or the same amount for less) with a trade discount. Indeed, you can benefit from a trade discount of about 10%. But if the productivity decreased by 10% because experienced developers were replaced with beginners, you will not save any money. Even worse, the deliverable may be less qualitative and will fall behind.
On the contrary, it is impossible to increase the productivity by 10% with beginning developers.
It is then essential to negotiate the increase in productivity clause based on the volume that is delivered, not on a trade discount without an increase in productivity.
The quality of the contract abacus will define the nature of the client/supplier relationship. The relationship will suffer from a poorly defined abacus.
The component count phase may be difficult, especially if the requirements are vague or changing. By avoiding the pitfalls mentioned above, the outsourcing contract will be more stable, long-lasting and pacified.