As a web development studio (as well as marketing, design and even video production studio), we operate upon software development contracts. It is necessary to take all the peculiarities of different software development models into account to identify and neutralize whatever risks may arise.
The right type of contract helps both sides minimize risks and achieve proper results. In this article, we’ll take a look at different price formation methods applicable to either custom software development or projects in any other field — from web design and CRM implementation to establishing a sales department.
These types are “Fixed Price,” “Time And Materials” and subscription contract.
Any of the following models of software development can be implemented based on a framework agreement (with appropriately modified applications).
Outline
Fixed Price Contracts
A Fixed Price contract determines the price of a certain amount of work, regardless of the actual cost of implementation. It can provide financial incentives for achieving specific project goals. There are several variations:
- Fixed Price Incentive Fee contract (FPIF) — a customer pays a contractor a set amount (as defined by the contract), regardless of the actual costs. If individual performance criteria met, the customer pays a premium that both parties agree upon in the contract.
- Firm-Fixed-Price contract (FFP) — the cost and scope of work are determined before the work starts and after that do not change.
- A fixed-price contract with a possible price adjustment is convenient if the works extend for a long time and conditions eventually change.
FP is used for standard projects with clear solutions and detailed requirements. The result requirements detailed in a separate technical assignment. The deadlines and costs in such contracts are fixed.
Advantages for the customer: stated requirements clearly define the customer’s budget.
Risks for the customer: changes to the product requirements in the process of its development can be complex in particular and make things more complicated in general. Such conditions do not suit the development of non-standard software and sophisticated systems.
- Each innovation needs to be further coordinated. The contractor won’t be pleased (and has a full right not to be) receiving news about new features to implement. Eventually, when consent is found, it is necessary to update existing documents or create additional ones.
- Choosing Fixed Price as a strategy for eliminating the financial risks of the client leads to even higher risks. The client lacks some development flexibility under such terms and uncertainties receiving a product of little to no interest to his target audience.
- The contractor includes possible risks into the costs as a precautionary measure
As a measure of risks reduction make sure the contract meets the following conditions:
- A step-by-step acceptance procedure stated in a contract (contractor’s payment should also split accordingly);
- A technical task is as detailed as possible: areas of work and competence designated for all parties involved (the contractor, the customer and the third parties if present).
It allows a customer to state new conditions and gives a contractor a choice to either continue or leave the project, reducing costs.
Advantages for the contractor – present if a ready-made solution that does not require significant refinement is available.
Risks for the contractor – payment denial upon completion or excess of actual costs over the price of the project. If the result doesn’t meet the requirements of the technical assignment, the customer may refuse to accept it — even if the customer only subjectively “thinks” the conditions are not met. Customers may use this option to reduce their expenditure one way or another.
The report documentation should be provided at the end of each stage. It is strongly advisable to formalize the stage-by-stage acceptance by signing a bilateral act for maximum guarantees. However, a unilateral electronic report is also acceptable and must be reviewed by the customer within a specified timeframe. It is crucial to describe the procedure of acceptance and its legal consequences in the contract.
The implementation of the project may take longer due to circumstances that depend on either party.
Time & Materials: TM contracts
This type is well suited for projects where the amount of work cannot be sufficiently determined in advance, and the project is split into separate tasks. The assignments executed within short periods. In this case, the customer relies on the professional level of the contractor and reimburses the contractor all actual costs according to fixed prices stipulated in the contract.
FP (FFP) or TM contracts are the most commonly used. They are entirely different, and each one has its advantages and disadvantages. Let’s take a look at the most significant points here:
- Risks of compensation. Any fixed price contract should consider all the risks that may occur during the execution of the project.
Risks may or may not occur, but the customer always pays that extra just in case. The value of the compensatory payment calculated according to the probability of risk occurrence. The formula looks something like this: [likelihood of risk occurrence] * [costs of dealing with the risk if it occurs].
For example: in a $50,000 project there is only one risk with a 20% probability of occurrence. If the risk “happens,” the price of the project increases by $10,000, so the cost of risk is $2000. Regardless of risk occurrence, the customer pays $ 52,000 for the project. Under the terms of the TM contract, the customer pays as much as the project’s implementation costs: $50,000 if things go smooth or $60,000 if the risk occurs.
- Scope of work provision. Under the terms of the TM contract, the customer pays for the actual time spent by the contractor. The scope of work can be provided to the contractor gradually, step by step. In doing so, the customer is responsible for the final result. In FP contracts, the scope of work evaluated before the contract is signed and can not subsequently be changed. The change in the scope of work under the FP contract leads to the termination of the current agreement, payment for the job done and the signing of a new contract for a new scope of work.
Sometimes customers want an accurate assessment of works of a long-term project to plan their budget. Any realistic assessment requires a clear vision of the result of the project and a detailed description of the product: scope of work, documentation, specifications with images of the future product.
Creating a detailed description of the product is difficult, but an accurate cost estimation of work is impossible without it. The less detailed product description is, the less precise estimation you get. An estimation is possible if assumptions supplement the lack of details and a financial risk compensation implied in case the premises are erroneous. The more assumptions, the more potential risks there are; thus the higher becomes the cost.
There is also one more thing to consider. If the customer spends several weeks/months on detailed product descriptions, but competitors don’t, the development process is bound to lag behind the competitors. The product is going to hit the market later because competitors used the approaching wave method: they split the project into phases, and parts of the description were provided gradually as needed.
GRIN tech suggests customers take the path of creating MVP (Minimum Viable Product) instead of working on detailed technical assignments and documentation.
The work split into phases and each phase has a fixed price stated in the contract. The customer provides the scope of work for the next phase based on the results achieved in the previous period.
Aspects of Time and Material contracts
I want to focus on a non-obvious aspect of the TM contract that can sometimes muddle customers.
With the TM contract, the development process of the product is transparent. The customer sees the process as is (with all the bugs emerging) and determines the goals and content of each version. The number of unfixed bugs inevitably increases from version to version, if the customer concentrates on the implementation of additional functionality and does not want to spend time on fixing bugs.
As a result of such an approach, the effectiveness of QA dramatically declines because there is going to be too many bugs after several months. Thus the development of new features becomes slower and slower, and the customer is getting nervous while looking for causes of problems and trying to figure out who is guilty. Bugs are the reason for the slowdown, and the developers are eventually to blame.
The position of the customer is clear: new features determine the grade of the product. The more features, the more persuasive the statements about the product can be, the more striking the advertising booklets and slogans are.
You can’t attract consumers by talking about how many bugs you fixed. However, the number of bugs also determines the quality of the product.
According to the customer, developers should provide their code without bugs. Those are the customer’s expectations of the quality of the developer’s work on the TM project. The customer expects the quality of the result similar to the one on the FP project. But the code written for the FP project passes a quality control and the subsequent bug fixing process before the customer sees the final product. The customer does not tell the developer what specific bugs to fix and does not even know that there were any bugs. The customer receives the outcome of the required quality. On the TM project the customer sees flaws and decides which bugs to fix, and since the elimination of bugs does not increase the value of the product (as the customer sees it), they may accumulate over time. When bugs reach a critical mass, the development stops and the project may be seized.
It is necessary to make sure the customer understands that from the very start to avoid the collapse. The customer should know that there are phases of creation, testing, and correction that are necessary.
Ignoring any of these phases leads to the collapse of the project. It is also necessary to reach an agreement that all known bugs must be eliminated in each version of the product.
The quality of each version of the product under the TM contract should be identical to the quality of the version released under the FP contract. Keep in mind that if you use SCRUM methodology to work, not every sprint can lead to the version release. For example, the first few sprints may be designed to add new features, and only the last ones reserved to bug fixing an initial release.
This approach allows using the advantages of the TM contract (the quick start and the ease of adjustments to market requirements) and the FP contract (the release of bug fixes versions, which can potentially be a shippable product).
Advantages for the customer: involvement of a professional team or individual specialists in certain areas of work. The product requirements are flexible and may be changed. Customers pay only for the actual work.
Risks for the customer: at the stage of early customer-contractor interaction, the total cost of works may exceed expectations.
Risk reduction: detail job prices of individual specialists in the appendix to the contract. Clarify the conditions under which a new task set, including its preliminary assessment by the contractor.
Advantages for the contractor: full payment for the time spent on the task.
Risks for the contractor: tasks not fixed in the form of separate technical tasks, specifications or annexes to the contract (due to short-term contract period). Tasks set and received using e-mail or project management systems.
Risk reduction: it is necessary to supplement the contract with the section on electronic document management using a simple electronic signature. That will remove a lot of customer’s questions regarding the content of the task, the result, and adequate billing.
Software development subscription contract
The contract is used to hire a professional team or a specialist to solve the non-specific tasks of the customer on a long-term basis. It assumes a high level of trust to the contractor.
A subscription contract is often used within a group of companies when allocating an IT infrastructure or a development team to a separate organization to optimize taxation or business processes.
Advantages for the customer: the possibility of setting any tasks within the competence of the contractor, a rapid change in the requirements, all while maintaining a fixed price.
In the group of companies, the subscription contract is used to receive benefits from insurance premiums from the developer’s payroll fund.
The risks for the customer: incomplete contractor’s workload and, as a consequence, overpayment in comparison to the T&M scheme.
The principal risks of the use of a subscription contract for optimization within the holding group are:
1) the extreme simplicity of the agreement, as evidence of a feigned deal.
2) incomplete and untimely recording of works performed under the contract.
Remember that if the terms of the contract do not fit the regular business practice of relations between independent parties it may indicate the pretense of the transaction to obtain unreasonable tax benefits. The analysis of the documentation can report the same issue.
A way to reduce risk: design a contract with the possibility of revising the fee based on the results of several accounting periods. A simplified revision procedure can be implemented based on contractor’s notifications over a specified period.
Make sure that all the works are thoroughly detailed in reports to eliminate tax risks.
Advantages for the contractor: the contractor provided with stable financing throughout the contract.
Risks for the contractor: the excessive amount of actual work not covered on top of the agreed subscription fee.
Risk reduction: put a limit on the amount of work performed for a monthly fee. If the limit exceeds, extra payment should be conducted. The payment should either be fixed in a contract beforehand or agreed upon according to the specifics and the amount of additional work.
Conclusion on what software development contract type to chose
There is no straightforward answer on which contract to use.
The fact that FP projects are inaccessible to customers until fully implemented assumes clients’ complete confidence in their view of the product. At the same time, TM contracts make the development process transparent, efficient and manageable. And if customers notice weak points a deviation from the original plan is possible to save time, money and avoid the erroneous approach.
However, sometimes a non-optimal product may be acceptable as a result, unlike the risk to go over the budget limit. Therefore you should consider all components when choosing a type of contract: budget, time and final result.