Types of software development contracts

As a web development studio (as well as a 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 in order 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 on the basis of a framework agreement (with appropriately modified applications).

software development contracts

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:

  1. 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 certain performance criteria are met, the customer pays premium that both parties agree upon in the contract.
  2. Firm-Fixed-Price contract (FFP) — the cost and scope of work are determined before the work starts and thereafter do not change.
  3. 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 end result requirements are detailed in a separate technical assignment. The deadlines and costs in such contracts are fixed.

Advantages for the customer: stated requirements clearly define 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 complex systems.

  • Each innovation needs to be further coordinated. The contractor won’t be very happy (and has a full right not to be) receiving news about new features to implement. Eventually, when a 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 greater risks. The client lacks some development flexibility under such terms and risks 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:

  1. A step-by-step acceptance procedure is stated in a contract (contractor’s payment should also be split accordingly);
  2. A technical task is as detailed as possible: areas of work and competence are designated for all parties involved (the contractor, the customer and the third parties if present).

It allows a customer to state new conditions and give 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 technical assignment, the customer may refuse to accept it — even if the customer only subjectively “thinks” the requirements 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, an electronic unilateral report is also acceptable and must be reviewed by the customer within a certain timeframe. It is very important 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 can not be sufficiently determined in advance and the project is split into separate tasks. The assignments are executed within short periods of time. 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 completely different in nature and each one has its advantages and disadvantages. Let’s take a look at the most significant points here:

  1. Risks 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 compensatory payment is calculated according to the probability of risk occurrence. The formula looks something like this: [probability 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 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 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.

  1. Scope of work provision. Under the terms of TM contract the customer pays for 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 is 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 contract, payment for the work 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 accurate 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 a laborious work, but an accurate estimate of the cost of work can not be provided without it. The less detailed the product, the less accurate estimates you get. An estimation is possible if lack of details is supplemented by assumptions and a monetary risk compensation is considered in case the assumptions 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 a detailed product description, 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 assignment and documentation.

The work is 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 phase.

Aspects of Time and Material contracts

I want to focus on a non-obvious aspect of the TM contract that can sometimes befuddle 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 approach the effectiveness of QA declines dramatically 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 of the slowdown and the developers are eventually to blame.

Basically, 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 have been 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 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 product of the required quality. On the TM project the customer sees bugs 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 in order to avoid the collapse.The customer should understand 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 are reserved to bugfixing and initial release.

This approach allows to use the advantages of the TM contract (the quick start and the ease of adjustments to market requirements) and the FP contract (the release of bugfixed 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 can be set, including its preliminary assessment by the contractor.

Advantages for the contractor: full payment for the time actually spent on the task.

Risks for the contactor: tasks are not fixed in the form of separate technical tasks, specifications or annexes to the contract (due to short-term contract period). Tasks are 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. This 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 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 T&M scheme.

The main risks of use of a subscription contract for optimization within the holding group are:

1) the excessive simplicity of the contract, 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 ordinary business practice of relations between independent parties it may indicate the pretense of the transaction in order to obtain unreasonable tax benefits. The analysis of the documentation can indicate 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 certain period.

Make sure that all the works are thoroughly detailed in reports to eliminate tax risks.

Advantages for the contractor: the contractor is provided with stable financing over the period of the contract.

Risks for the contractor: the excessive amount of actual work is 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, an 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 works.

Conclusion on what software development contract type to chose

There is no unequivocal answer on which contract to choose.

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.