What needs to be considered in estimating fixed-price projects ?

Jun 17, 2020
3 min read

What needs to be considered in estimating fixed-price projects ?

What needs to be considered in estimating fixed-price projects

Very often, startups want to implement projects for a fixed price as they have a limited budget in which they should deliver MVP for their investors. Outsource agencies, which surely want to increase their client base, are ready to help.

But very often this cooperation goes wrong, clients add more and more requirements, change them and on other side outsource agencies try to compensate for this additional work decreasing quality: skipping writing unit tests, skipping security and performance testing etc.

This article is about how to avoid such situations and build strong relationships between client and outsource agency. Below we listed a few tips on how to avoid misunderstanding and reduce the number of debates about project scope.

  1. Rule number one: never, never commit on unclear scope. Businesses like to talk on a high level, like “I want to have a possibility to create invoice reports”. This kind of requirement is very high level, and it doesn’t give a clear vision of what the input parameters would be, what the output would be, in which format the report should be presented etc. If you don’t clarify this, it will lead to a situation where the initial estimate is much less than this feature will really take. As a result, you will have to explain to the customer why your initial estimate was wrong, and very often it makes the client feel that you are trying to fix your mistake using his money. Moreover, take into consideration that fixed price projects are usually done with a new agency, so there is not enough trust between parties. To avoid this, it is essential to clarify every feature, every button and non technical requirement.
  2. Never rely on the estimate of one person, if that person would not be the only one developer on the project. Imagine the situation, that you asked one developer to estimate the project and put another one to work under the project. Of course their development speed, knowledge and experience are different. Consequently, development time will be different. The good practice is to use at least 2 different developers for estimating the same functionality. They should work being isolated from each other, so they do not influence each other’s conclusions. And then, finally, the person responsible for estimation should compare estimates and discuss items which do not match. It helps to avoid mistakes and situations where some important requirements get skipped.
  3. Don’t forget to include non development activities to estimate: team meetings, plannings, daily calls, server and CLI tools configuration, reporting and investigation activities. Those activities do not look very time-consuming, but for big projects it could be hundreds of hours.
  4. Put assumptions into the estimates. Very often clients have just a vague picture of how the product should look like at the end. As a result, they can’t provide detailed requirements. In such cases your estimates should contain requirements, for example, for reporting features. This estimate assumes a report that will take invoice period date as input parameter, and will display all invoicing items over the specified period. Also there would be an option to export it to pdf.” In such a case you explain to the customer that you are not ready to do any kind of report in specified time, or it’s not the average time that reports are taken for other projects. But it is a concrete report and if the client wants to change requirements for the report, you will have to discuss it.
  5. Try to visualize the project using wireframes. Investing in a UI/UX prototype is a brilliant idea, when requirements are too complex and not detailed enough. So you can ask the designer to display how he understands requirements and discuss it with the client. It will help to avoid rewriting code in the future. It is much easier to change the prototype than rewrite the code, related unit tests and retest features by QA.

Be safe and don’t lose money on fixed-price projects!

If you want to receive more information subscribe to us