We are often asked by customers to propose a suitable contract for their project. There are a lot of issues to be taken into account when selecting a suitable contract. Let’s consider contract definitions to see the differences.
1. Fixed-price (FP) contract
An agreement fixing project price for the known project scope. The actual project price does not have any matter. This type of contract may include some bonuses for achieving particular project goals. Read here “How to estimate the cost of fixed-price projects”. There are several types of FP contracts, let’s list some of them:
a. Fixed-price contract with incentive firm (FPIF) is an agreement that sets the project price for known project scope without taking into account the actual work price. Also, the performer gets predefined bonuses for achieving particular goals.
b. Firm Fixed price contract (FFP) is meant when customers say “fixed bid contract”. According to this contract, the project price is defined for known project scope before any work has started. The price can not be changed during project execution.
c. Fixed price contract with the possibility to change prices is used for long term contracts when project conditions are changeable.
2. Time&Materials (TM) contract
An agreement to compensate performer’s expenses in accordance with the defined rate. In IT area the customer pays for total development time according to an hourly rate.
The most popular are FP (FFP) or TM contracts. They are completely different and each one has pros and cons. Let’s consider them:
1. Risk reimbursement: The FP contract price includes all known risks that can happen during project performance. Actually, these risks may happen or may not. Still the customer always pays for them. For instance, the price of the project with just one risk is 50.000$. The possibility of the risk is 20% and if the risk arises, then the total price will increase by 10.000$. So risk price is 2.000$, which means the FP contract price will be 52.000$ regardless risk occurrence. At the same time, under TM contract the customer will pay only for real project work. It means if the risk arises, then the total sum will be 60.000$ but if it does not, then 50.000$.
2. Providing project scope. Under TM contract the customer pays for actually executed work so the project scope can be provided during project execution. Whereas the performers do not have the whole project scope they do not see project goals clearly. In this case customers are in charge of the achievement of project goals while performers are in charge of the execution of the given piece of project scope. Under FP contract the customer provides all project scope before the contract is signed. The project scope is unchangeable. The original scope can be changed by termination of the current contract, payment of the work done and signing a new contract for the new scope of work.
Business likes planning and obligations so usually customers need an accurate project estimate. Any accurate estimate requires detailed product description, project scope, documentation, specification including screenshots of the future product. It is time consuming to produce that kind of documents but it must be done to have an accurate project estimate. The better description you have, the more accurate estimate is. If the given description is insufficient or something is not clarified, then the missing information will be made up by the performer which may lead to additional risks. So, the more guesses there are, the higher price is.
Also, it is necessary to take into account the fact that if the customer spends several weeks/months producing the detailed description when their competitors do not do this then the development of the customer’s product will have a lag of several weeks/months. So, the product will be launched later because the competitors used a rolling wave development approach providing the detailed description when requested.
Long term development can be split into phases in order to set each phase as an independent FP project. In this case the detailed description is given per phase.
TM Contract Features
I would like to draw your attention to the unobvious TM contract characteristics that can be confusing for customers.
Development process under TM contract is transparent, customers observe the whole development process as is. They observe all the arising bugs, define goals and scope of each product version. If the customer’s new features are more important than the product stable version, then bug fixing is postponed. That means every following version has more new bugs than the previous one. In some months the number of bugs will lead to a decrease in QA efficiency and the developers will create new features based on the bugs of the current functionality. Instead of bug fixing they will be trying to find workaround solutions needed to implement the new features. The development of the new features will be going slower and slower and finally, the customer will look for the causes of the problems. They will definitely understand the development process is slow due to the bugs created by the developers. So everything will be clear.
Actually, the customer’s way of thinking is clear, new features define a product grade. So the more features the product has, the better the grade it has. As a result, the more efficient advertising campaign can be realized. The number of bugs defines quality. The fewer bugs – the better the quality. But the customer can not use the number of fixed bugs during the advertising campaign. The number of the fixed bugs is not important for consumers. About the cost of bugs read here.
Customers think developers must create outcome (source code) without bugs. So customers expect to get quality of development process under TM contract similar to deliverables under FP contract. Nevertheless, the main difference between contracts is ignored. Under FP contract developer’s outcomes go through QA control with following bug fixing until all bugs are fixed. Customers do not indicate which bugs have to be fixed as they know nothing about these bugs. The deliverable provided to the customer is bug-free. Under TM contract customers observe all the arising bugs and point which of them must be fixed now and which ones in the future. Whereas bug fixing does not affect product value, the number of unfixed bugs will be increasing until development process gets slower. In this situation the project can be terminated with the customer making claims.
To avoid project termination under TM contract the development team must be sure that the customer understands all steps of development process. Among others they include: direct development, QA control (testing) and bug fixing. Ignoring QA control and bug fixing leads to the project termination eventually. It is necessary for the developers and customers to have an agreement to push out each product version bug-free. The quality of each product version developed under TM contract must be equal to the quality of the product developed under FP contract. If development process is Scrum inspired, then several sprints can add new features and the last one is stabilization and it is aimed at bug fixing. After that the new product version is ready to be pushed out. So this approach to development process involves the pros of TM contract: fast start and easy scope changing according to the new market requirements. And also, it involves the pros of FP contract: deploying potentially shippable product.
Summing up, there is no obvious answer, which type of contract is better. The closed nature of FP contract (from date of signing to date of project completion) requires customer’s confidence in product vision. In contrast, TM contract makes development process transparent, more efficient and manageable. If during project execution the customer discovers some trouble spots of the product, then the initial development plans can be changed to avoid spending money and time to implement a wrong development approach. But sometimes the budget is more important than the risks of not getting the best deliverable. So, when selecting a better contract, you need to think about project elements – budget, time, deliverables.
Latest posts by Vitaly Hornik (see all)
- Scrum Master Games, or What Your Scrum Coach Didn’t Tell You - April 8, 2016
- FP vs TM Contract. Which One Is Better? - April 9, 2015
- Project Scope Management in IT Projects - August 12, 2014