FP & TM Agreements: The Perks & Pitfalls

If you are planning to do remote software development, then you must have thought about which engagement model to use. We get asked this question a lot, and as you have heard before… the answer is, it depends. In this article we’d like to present you a detailed description of FP & TM Agreements, their perks & pitfalls:

1. Fixed-price (FP) Agreement

– is identified by the price for the determined workload, despite the actual cost of work performed.scope of work.

Such type of Agreement might cover financial benefits for a certain tasks achievement of the project. Fixed-price Agreement is divided into:

1. FP Agreement with incentive fee (FPIF) – Fixed-price agreement where the Customer pays a specified bonus for the achievement of a particular criteria.
2. FP Agreement with fixed price – I know, it sounds a little bit grotesque, but such type of Agreement deserves a fuller explanation: when the Customer choses FP Agreement, he bears in mind that according to such contract the work load shall be determined before work start & afterwards shall not be subjected to any changes.
3. FP Agreement with a provision for possible price adjustment – quite comfortable in cases of terms stretch, during which any changes might occur.

2. Time & Materials (TM) Agreement

– is a mixed type of Agreement, according to which the Customer reimburse the Contractor all actual costs. The Customer pays for the time spent on the development by the hour rate.

From all existing diversity of agreements, TM & FP are the most popular ones. They both have their perks & pifalls. So let’s have a closer look at them:

1. Risk Coverage:
   Fixed price Agreement covers risks that might arise during project performance. Risks might or might not occur, but the Customer shall always pay for them. The cost of risks is calculated from their probability to appear on the cost of their realization. For example, there’s one risk in performance of the project, with a cost of 50.000$. Its probability to occur is little – around 20%, but in case of its occurrence, the cost of the project will raise on 10.000$, i.e. the risk cost equals 2000$. Irrespective of the risk occurrence, the Customer pays for the project 52.000$. In case of TM agreement the Customer pays as much as the project performance will cost, i.e. without risk -50.000$ & in case of it occurrence– 60.000$.
2. Project Scope Assignment:
   Since the Customer pays for the actual consumed time in case of TM Agreement, he can provide the content of the work gradually, as work progresses. Provided that, he is the person who takes responsibility for the final result.

When performing the project on the FP basis, the volume of performed works is provided and evaluated prior to the signing of the contract and afterwards can not be changed. Changes in the volume of works at FP Agreement leads to termination of the current contract, payment of performed works and to signing of a new contract for the new scope of work.

The peculiarities of TM Agreement

I’d like to draw your attention to the non-obvious feature of TM contract that might resulted in customer’s confusion.
Under TM agreement, the process of development is transparent: the customer sees the development process as it is, sees all the bugs appeared, defines the objectives and content of each version of the product.

If the customer doesn’t want to spend time on the elimination of bugs and focuses on adding functionality, the number of bugs increases from version to version. After a few months of such development, there’re so many bugs that the effectiveness of QA fails, so that the developers have to create new functionality basing on existing bugs functionality. The development of new functionalities goes slower and slower thus resulting the customer’s getting nervous and looking for the causes of problems. The reason for slow development – bugs. Who creates them? The developers. The cause and the offender are found.

On the customer’s opinion, the developers should present the code without bugs. I.e. the customer expects the quality of the developers’ work on TM project to be the same as on FP project. In this case, the customer ignores the fact that in FP project, the created code undergoes the quality control & the following fixing of all found bugs before presenting it to the customer.
On FP project all bugs without any exception are fixed & only after that the customer sees the result. The customer doesn’t point the bugs that a developer should fix. He even doesn’t know whether they be. The customer is granted with the final product of the required quality.

On TM project the customer sees the bugs & decides which of them should be fixed. As far as bug fixing doesn’t add value to the product, they have a tendency to pile up. When the number of bugs becomes critical, the development process stops & the project might be closed.
To avoid project crash, one should make sure that the customer understands that under TM project he sees the project, which includes the phases of creation, testing & fixing. Disregard of one of these phases, after all, would lead to the project failure.

Conclusion

So, which agreement should we choose: TM or FP? There’s no absolute answer. The closedness of the project from the moment of order placement till its final performance presupposes the dead certainty of the customer in the rectitude of his vision on the product.

Meanwhile, TM Agreement allows making the development process clear, effective & driven. And if the Customer notes the weak spots in the project, he can deviate from the ground-plan & do not waste time & money on performance of wrong approach.
However, some non-optimality of the product is allowed in contrast to the risk of missing the budget.
That’s why, while choosing between the types of agreements, one should keep in mind all the components – budget, time, final result.