“Who is responsible for a 30% increase in the budget during the development process and should suffer losses?”
“Or for the fact that the planned and implemented features turned out to be unnecessary for users?”
“How quickly should errors be fixed, and the application restored if problems occur?”
In fact, there are no definite answers to these questions. It all depends on the agreement between the client and developers, and the chosen collaboration format. The chosen format defines the areas of responsibility of each party.
In an ideal world, the client’s expectations are managed by the developer. This is especially true if the clients are getting their first experience and do not know how the process is structured. In the real world, such issues can be resolved through conflicts. For example, if the customer believes that the support of the completed product is the responsibility of the developer, and the developer has to spend additional resources on it that were not included in the price fixed in the contract.
Agreed areas of responsibility help not only to avoid unnecessary disputes, but also to get a better result. When the client is in charge of deciding what goes into the product, it's important for them to recognize this responsibility and act accordingly. This might involve thoroughly understanding the users and their needs or even bringing in an additional specialist. Sometimes, clients may find themselves in a situation where contractors have diligently carried out their tasks, but the end product turns out to be unimpressive and uninteresting. The client might have assumed that the experts would express their concerns if something was amiss. However, it's important to note that assessing the product's marketability is not within the expertise of the development team. They may not be equipped to judge whether the client's management of the product is on the right track.
There are four most common formats on the market. Each format determines the distribution of responsibility and risks between the client and the contractor.
An opportunity for a client to fix the cost of development, terms, and a complete list of everything that should be done in the product in the contract.
The client should be prepared to carefully study the terms of reference, develop prototypes, and determine all requirements. This might involve a separate research phase, which can range from two months to as long as six months or more, depending on the project’s scope.
The client clearly understands what they want to get as a result, and the requirements for the product will not change in the process. Or the changes will be minor. The process of making changes will require time to research new requirements, develop prototypes, and conduct additional evaluation, which should be documented in an addendum to the contract.
The client is responsible for defining what needs to be done in the product. The company collects product requirements from the client or from sources provided by the client. The exception is when the marketing function (user and market research and defining the key value) is taken over by a contractor. But this is agreed upon separately.
Developers determine the composition of the team, the level of specialists, and choose methodologies for working on the project. Technical decisions also remain on the developers’ side.
The risks of meeting the conditions (compliance with the agreed budget, deadlines, and quality) are fully borne by the developer. If it turns out that some functions were underestimated in the process, the contractor bears the losses. Therefore, the price may include risks—a percentage of the total project cost determined by the company.
The project ends with the transfer of the product to the client. For example, by publishing applications. The client can agree on a warranty period during which the developers fix defects and errors free of charge, if any. The development of additional features and support is subject to a separate agreement.
The total number of hours required to develop a product multiplied by the billable hour.
Usually, an accurate estimate is provided after the research stage, when the technical task is clearly defined and prototypes or designs are developed.
This format gives the client more flexibility and influence over the development process. It does not require a lot of time to collect and process all the requirements. Often, the budget, timeline, and set of planned features are very conditional, or only one of the criteria is fixed.
The client has a general understanding of what the product should look like, but does not need to plan the development months in advance, wants to move gradually, and has the flexibility to make changes, for example, to abandon planned features and add new ones.
All parts (sprints) are worked out and planned gradually. The client receives intermediate results and decides what to do next.
Product decisions can be made jointly, or additional specialists can be added to the team. The client can influence the team composition, the level of the developers’ experience, and the development methodology.
The risks are divided in half. The developer can provide estimated time and cost, but will not suffer losses if they turn out to be higher than expected. On the other hand, the client may refuse to cooperate if the gap between the initial estimate and the actual costs is too large.
The project can end at any time, according to the client’s decision. The client and the developers can agree on the terms of cancellation. For example, the client should notify the development company one or two months in advance that they are suspending work.
The team composition and the involvement of each of its members are determined. For example, a developer can be engaged for a full month or for 80 hours during the month.
To determine the monthly budget, the hourly rate of a team member is multiplied by the number of hours they are expected to be involved in the project. It is calculated for each specialist and summed up for the team.
The client and the developer can agree on the approximate number of months to develop the product.
“Leasing” of a development team or individual developers.
The client already has a technical team, but there is a shortage of specialists or a need to expand the team quickly.
The client is in full control of the project and is fully responsible for product development, budget, timing, and quality.
The contractor is responsible for hiring people, training them, and providing working conditions, such as a workplace and equipment. Usually, the contractor pays for holidays and sick leave, but the dates are agreed with the client.
The project can end at any time, according to the client’s decision.
You are paid for the number of hours worked by each team member, according to the agreed rate (cost per hour).
Support service for running projects.
The client has a product that has gone through a phase of active development, requires reliable operation and the introduction of constant small improvements. Or the client needs to respond quickly and fix errors within a certain time frame.
A support agreement may include a basic set of services: project monitoring, making small improvements within the budget, regularly updating libraries, and switching to more modern technologies to prevent problems in the future.
If there is a request for larger changes that are not covered by the terms and conditions, they are calculated separately.
The client and the development company determine how the support will be implemented. For example, user requests go directly to the developers, who are responsible for their prioritization and implementation. Or the customer is responsible for processing requests and passes only the changes that need to be implemented to the developers.
The speed of response to bugs may be regulated. For example, for some products in the medical or government sector, reliable and uninterrupted operation is essential. Lives or safety may depend on it. Even if something happens at night, it needs to be fixed instantly.
The speed of response can also be governed by the impact of incidents (bugs). If the impact on the system is high, it should be fixed, for example, within an hour, if it is low, then within a day. The risks for meeting the specified conditions are fully borne by the developer. Penalties may be imposed if the response time and error correction time specified in the contract are not met.
Payment is charged on a monthly basis.
Each of the proposed formats is a guideline for determining areas of responsibility. It all depends on the context of the project and its needs. The main goal is to synchronize expectations and clearly understand who influences what and what they are responsible for. This is not only about the relationship between the client and the development team, but also about the result they get from cooperation.
Collaboration formats can change in the process of interaction. The first version of the product can be developed on a fixed estimate, and its development can be done on a Time & Material basis to gain more flexibility and implement changes faster. If the product is in the active development phase and requires only support and monitoring, you can change the format to a Services Level Agreement.