Is a fixed price project actually worth the price for the project owner?

Most software development companies are aware that a fixed price contract is bad for them. However, the clients or project owners have a completely different perception about it and most of them believe that fixed bid contracts are good for them. This however does not hold true in the real scenario. This post explains the reason why.

Here are a few questions that will give you an idea as to why preferring an agile approach in managing requirements, releases, and changes in a project is any day better as compared to fixing everything in the beginning.

Are the estimates fair enough?

Development of software is an innovative and creative approach, especially when a new one is made from scratch. It is not really possible to exactly provide the time needed or the price for each feature or the complete software as a whole. The main reason for the same is that the fixed price quote is given based on the information available just at the start of the project. Unknown complexities that arise during the course of the development phase are still unknown. The fixed price estimates are provided by most software developers keeping a fair margin of the unknown. Now think about it again. If a margin for the unknown is kept while bidding for a project, this implies that the estimates are never fair. Each software developer knows that there is a risk involved in estimating and the same is compensated for by overestimating. So when you are actually going in for a fixed price project, you are actually paying for a guess plus some margins to safeguard the developer. Now, where does the clients’ interest, i.e. your interest go?

Do fixed price contracts actually reduce client’s risk or give you a false sense of security?

It may seem that a fixed price contract is less risky for a client but it is actually not the case. To make it simpler, let’s take an example. Say, if you choose a software development company to work on your project for $10,000, it is more likely that the actual cost would be either $7,500 or $12,500. If it is $7,500, you lose the extra $2,500 paid to the developer or the features in your software that could have been there in the given price. On the other hand, if the actual cost is $12,500, you get a low quality product, as the developer will try to take every possible means to lower the cost of the project that will indirectly affect the quality of output. By every possible means, we mean the software development company might resort to quick hacks for problem solving in place of appropriate solutions; cutting testing to the maximum extent possible; hiring cheaper resources for the project in place of experienced developers, etc. All of this impacts the output in a negative way and in turn enhance the updating and maintenance costs. To put an icing on top f it, if the deadlines are also fixed along with the project price, the development company now has a larger incentive to resort to these means and meet the deadlines. This is in reality the main reason why several software projects fail or have disappointed clients.

You would like to build the best possible product or the one you documented at the inception?

If you fix the price of the project with the developer, the developer in turn requires you to limit the scope of the project as well. This means that you as a client have to provide everything needed upfront in the cost fixed. This again has its own downside. Why? You are tempted to include some nice to have features in the initial scope, which means that you are paying for development of those features which you might never use. On the other side of the sea, you miss out on certain features which are important but they do not strike you until you see things in action. So, you lose on both ends in a fixed bid contract.

We at Miracle follow a completely agile approach for projects. We lay more focus on fixing quality and release dates rather than the price for the complete project in advance. Small iterations are usually priced fair and the same are fixed in the beginning of each cycle. We understand that flexibility is the need of the development projects and going agile is the best solution. This is one of the main reasons, our clients are happy and view a long term association with us as at the end of the project, they get a product and not just the files of the code that they have nothing to benefit from.