The Impact of Compensation Models on Value for Money of Development Services

How to make sure you get the maximum value for money from your development service provider.

When software development is not one of your core competencies, when you consider building your own development team to be a costly and risky endeavor, or when you are struggling to find qualified software engineers on the job market, you may consider hiring an external development service provider for your software project. External service providers build new software applications from scratch, help you modernize existing applications, increase the efficiency of your DevOps processes or strengthen your existing development organization with additional manpower.

If you decide to work with an external service provider, you as the customer must agree on a compensation model together with the potential supplier. The compensation model and the corresponding contract define what the supplier will deliver to you and at what price. At first glance, this seems like a trivial challenge. But anyone who has been involved in IT or development projects knows that this is not a simple challenge. In practice, the costs can explode or the quality of the result leaves much to be desired. This in turn leads to disagreement between customer and supplier regarding the compensation for the service.

The choice of the compensation model and its conditions have a direct impact on the profitability and the chances of success of your software project. As a customer, you most likely want the highest possible quality at the lowest possible total cost—i.e. the best possible value for money. For development and engineering services, this means that you, as the customer, must ensure that the supplier can deliver the expected results in the best possible quality and that he can offer you the best and fairest possible price.

In this article, we compare different compensation models and show what impact these models have on the value for money and the total cost of ownership of a software project. We compare the two established compensation models

• compensation at a fixed price with
• compensation by time and material.

We also propose a third compensation model based on agile software development that combines the advantages of the two established compensation models and overcomes their disadvantages:

• a sprint-based compensation model.

Compensation at a Fixed Price Conveys a Deceptive Sense of Cost Certainty

Purchasing the development of a software solution at a fixed price may seem obvious from the customer's point of view, because it promises supposed cost security and a guaranteed result. In practice, however, this is illusory. Under Swiss law, compensation at a fixed price is represented in a so-called contract for work and services (Art. 363 ff. OR). The customer describes in detail what is to be delivered by the supplier (legally "the work"). The supplier states the fixed price at which he can deliver the software. In practice, it is not possible to specify all the requirements for a software solution precisely enough in advance. Usually, important requirements are forgotten or circumstances and user needs change during the project. Disagreements about the compensation of changed or new requirements between customer and supplier are therefore inevitable.

With a fixed price compensation model, the customer tends to pay a fixed price that is too high and should expect additional expenses during the course of the project. Because it is difficult for the supplier to accurately estimate the total cost of an entire development project, the supplier includes a certain safety margin. That is, the customer pays not only for the development service, but also an extra for the risk of an incorrect estimation of effort. In addition, the customer pays for unexpected costs for unspecified or new requirements that arise during the course of the project. Generally, so-called "change requests" are not included in the fixed price and are charged additionally.

Compensation by Time and Material Turns a Development Project into a Bottomless Pit

When the customer purchases software development by time and material, he has maximum flexibility with respect to the scope of development, but hardly any chance of estimating the total costs. In Swiss law, compensation by time and material is defined by the term “agency contract" (Art. 394 et seq. OR). In this case, the supplier only owes the client an activity in accordance with applicable duties of care and to the best of his knowledge and belief. The customer pays for time worked (e.g. hours or days) and material used. The supplier usually makes an estimate of how much time it will take to develop a software solution, but is not obligated to honor that estimate.

With a compensation model based on time and material the customer pays for the inefficiency of developers and in addition bears the entire risk of success. Productivity varies widely, especially among software developers. A number of studies since the 1960s proclaim the "10x" factor in the productivity of programmers—that is, a 10-fold difference in what a developer can accomplish in a certain unit of time. So, whether a paid hour of work produces effectively usable results is therefore not guaranteed. In addition, payment by time and material sets the wrong incentives for the supplier. If it takes him longer to complete a task, he can charge more. In a case of hardship, the supplier can insist on payment after the time worked, without having achieved anything. The customer therefore bears the risk of success in full.

A Sprint-based Compensation Model Reduces Project Risk while still Allowing Flexibility

With a sprint-based compensation model, the customer pays a fixed price per sprint agreed upon before the project. In agile software development, a sprint is a fixed period of time—usually two weeks—in which certain work results must be delivered. The customer and the supplier jointly define the deliverables and their acceptance criteria before each sprint. The supplier guarantees the fulfillment of the defined deliverables per sprint. In case of non-fulfillment or partial fulfillment, the customer does not pay or only partially pays for the sprint.

The financial risk is manageable for both the customer and the supplier. The customer has a guarantee that he gets measurable and tangible results for his money and does not just pay for hours worked that lead to nothing. Both the customer and the supplier can define the deliverables and their acceptance criteria with sufficient precision for the time horizon of a sprint. The supplier can reliably estimate which results he can realistically achieve within the upcoming two weeks and can promise them with confidence and without unnecessary safety margins. For the supplier, the financial risk of overestimating and not being able to deliver the results promised is limited to the price of the sprint.

With the sprint-based compensation model, the customer retains the flexibility to adjust the development course if it turns out that the initially defined requirements have changed. As with compensation by time and material, the development activities that are expected to add the most value can be prioritized. However, the value for money becomes much more visible because the fixed price per sprint can be put against tangible work results. In addition, the mindset of the supplier changes from "deliver hours" to "deliver results".

Equally Important as the Compensation Model is a Trustful Relationship between Customer and Supplier.

Agile development and a sprint-based compensation model help to reduce the risk in development and innovation projects. However, development and innovation projects are and remain characterized by uncertainty. A sprint-based compensation model does nothing to change this. There are no guarantees for project success, even if this is often desired by managers with questions such as "How long will it take and what will it cost overall?" Instead of creating long-term plans and budgets that end up being discarded, we should focus on generating maximum value with a fixed budget—the fixed price per sprint—each time. And that is exactly what is achieved with a sprint-based compensation model.

The right compensation model and the corresponding contract that reflects such a model support a functioning cooperation between customer and supplier. Equally important, however, is a business relationship based on trust and a shared vision. After all, this is what ultimately motivates all parties involved to develop and operate usable and valuable software solutions—solutions that are loved by users.

At EMBRIO.tech, we put the sprint-based compensation model into practice and created a tailored contract framework to ensure maximum value for money and promote transparency and trust. In doing so, we made sure that the contract is fair for both parties, compatible with applicable Swiss law and does not increase the administrative effort during the project, so that we can focus on the essentials—creating compelling software solutions.