we share our experience of working according to these business models

Short description

The article explains why a software development company moved from fixed-price to time-based payment models. The main reasons for the transition were the desire of customers for more flexibility and transparency in the development pipeline, as well as the ability to monitor and control the progress of projects. Fixed-cost contracts did not allow quick responses to changes or give clients the opportunity to monitor work, whereas time-based contracts enable flexibility, quicker adjustments to tasks, transparency, and full control. The article concludes by noting that clients could financially benefit from switching to hourly payment rather than paying for risks involved in fixed-cost contracts.

we share our experience of working according to these business models

In this article, I will tell you why our company decided to migrate from fixed-price payment to time-based payment, and how it became more interesting for our customers. Along with this, we will understand the advantages and disadvantages of each model, and how we have built our business processes in order to minimize the risks of customers as much as possible.

(Spoiler: The main reasons for the transition from fixed-cost contracts to hourly contracts were the desire of customers to obtain more flexibility in the development pipeline, as well as maximum transparency and the ability to monitor and control the progress of the project).

How we worked on fixed cost contracts

At the dawn of our business, we worked on fixed-price contracts. In general, we have a name that speaks, which does not require special decoding. Obviously, in this pricing model, the cost of the project is calculated in advance and fixed in the software development contract.

At that time, we were just starting to dive into the world of IT business and were doing quite standardized things. Therefore, working with fixed price contracts was an ideal solution:

  • Our Customers clearly understood what the project budget is

  • It was the result in the form of a ready-made site with certain functionality that was important to the customers, and they were not interested in the internal kitchen of iterations

However, already in the projects of creating product designers for marketplaces, both we and our customers began to notice the shortcomings of this business model.

In particular, the cases of variability of decisions became more frequent, but the model did not allow a quick response to changes in the project. Flexibility was practically absent.

For example, if the Customer needed to add a new function to an already agreed project, then it was necessary to prepare an additional agreement to the contract, waste time waiting for the Customer’s lawyers to check it and, finally, to sign this agreement. Of course, if possible, we tried not to waste this time in vain and waiting for additional verification. agreements, worked diligently with the functionality that was originally stated in the technical task. However, not everything can be done in parallel. And yes, there were situations when the task of adding a function arrived at the end of the project, when there were practically no parallel tasks left.

Things were worse when it was necessary to make a replacement for internal functionality or an interface, and at the same time, the initial and new tasks differed in the complexity of their implementation. Accordingly, it was necessary to recalculate the project. And explain to the customer why the cost increased when replacing one task with another. (The fact is that it seems that the phrase “fixed price” should mean a guarantee of the absence of any changes in the cost of the project. Therefore, naturally, it is psychologically uncomfortable to learn that, replacing one function with another, it is necessary to pay extra. A situation arises as in the anecdote : we found the spoons, but the sediment still remained.)

And, finally, as the projects that we took on for development grew larger and more complex, the Customers began to show interest in the possibility of monitoring the project, gaining control over the process of work on the project.

Unfortunately, working with contracts with a fixed cost did not provide the Customers with the desired opportunities.

Paying for actual time spent: how we work now

We have gradually moved away from fixed-price contracts and fully into time-based contracts. At the same time, as it was mentioned earlier, this was not a revolutionary decision, but the existing practice was caused, first of all, by our desire to adhere to the interests of the Customers.

As the name implies, a time-based contract means the performance of work on an hourly basis. Working under contracts with hourly payment, we managed to provide the following to the Clients.

Flexibility regarding the possibility of making changes to the project.

Now it has become possible to quickly, in a matter of minutes, remove any task from the list of works or, which is a frequently encountered option, add a new task. This can be related to the expansion of the planned functionality and the addition of a new function to the project, as well as the modification of already created functionality.

This business model fits perfectly into the agile approach implemented in our company, with its sprints, numerous iterations and briefings:

  • Tasks were outlined

  • Prioritized tasks for the current week

  • And focused on their performance

Meanwhile, the Customer always has the opportunity to add tasks to the backlog for the future and even to make some adjustments to the current sprint (although such cases are extremely rare – since planning for a week is one of the most optimal in terms of accuracy).

Transparency and full control.

Of course, when paying for time actually worked, it is very important for the Customer to ensure maximum transparency and the possibility of cost planning. In our company, we solved this issue as follows:

  1. We prescribe the maximum number of man-hours per week in the contract

  2. We implement the practice of time tracking and daily reports

The presence of a clause in the contract about the maximum number of man-hours per week gives the Customer the opportunity to determine the ceiling of monthly costs for the project.

With daily reports, Clients can not only see how much time was spent today working on their project, but also what tasks were completed, what steps were taken, etc. That is, to all the advantages of transparency, the opportunity for customers to keep their finger on the pulse is added.

In addition, for all projects, we have a practice of weekly calls, during which the Customer can give feedback, clarify the point of interest, without prejudice to the overall progress of the project.

Well, instead of a conclusion, it should be noted that with large projects, it is not uncommon for the Customer to win financially by rejecting work at a fixed cost and switching to hourly payment. At a minimum, as a result of the fact that he does not have to pay for the risks involved in the calculation of the project on the basis of a fixed cost 😉.

Related posts