Fixed-price project is a term used to describe a project where a client pays a fixed price for a predefined scope of work. With this model, the delivery of final product is ensured within a specific timeframe and clients pay a mutually agreed fixed price for the execution of a project. This can be appealing for many clients because of the perceived financial stability. However, fixed-price projects still have some drawbacks for incomplete work, quality problems, or late completion. Therefore, fixed-price software projects may end up being a painful experience for both sides. Agile methods, on the other hand, help to minimize or at least manage some of those risks as an engineering firm.
When going with fixed-price projects, the following problems may arise:
1. No Flexibility
One thing about a fixed-price project is that it only works when the client has a very defined and detailed set of work, with little to no variability in scope of work. If clients bid for developing a software for which the requirements are either not clearly defined or constantly changing over time, then the bid will also change, and therefore will not be fixed-price anymore. The reality is things can always change, especially in software development and agile methodologies. Feature sets change, budgets can variate and new business or social trends may affect which features need to be delivered first. In software development, it is a big challenge to identify what features are necessary or which are important when a project is not yet implemented. In many cases, some features may be technically challenging but it turns out these features bring very little market value. This can lead to engineering team spending much effort in building features that were not properly scoped by the client at the beginning. In other cases, some features may become popular during the development process and need to be expanded. Both cases can create huge challenges for clients and engineers when a fixed-contract is used.
Just as in waterfall, estimation of an entire project is highly inaccurate because it is made at the point where both sides have the least knowledge — before the project even starts. Just as with other fixed price work, pad estimates may come into play, perhaps doubling them to ensure that inevitable estimation errors had been covered. As mentioned above, fixed-price projects limit to very little to no flexibility. Therefore, updating the product’s features and adding new elements that were previously out of score will affect the established budget. (Read more: Reliable Estimates Using Agile)
The main challenge of fixed-price projects is that both client and engineering team must have the answers to all potential questions before the development starts. Usually these answers are gathered in a long document containing precise development specifications. For that reason, it takes a lot of time and effort to prepare all necessary documents before stepping into the project. It also takes a long time for engineering team to read and process the documents. Due to this long preparation stage, the work progress will be slowed down to some degree.
This can be an advantage or a disadvantage depending on your point of view. With limited supervision required, clients have more time to focus on their business. However, this may also cause disappointment of clients at the very end of the project. After signing the contract and determining all requirements, clients can only get access to the final result when the project completes. That means clients won’t be able to follow and control every progress made in the project. As mentioned above, things can always change during the project and lack of communication as in fixed-price projects will possibly lead to “No, this is not what I asked for” after a year-long project. (Also read: The Importance of Communication in Agile Software Development)
With fixed-price projects, the software provider is limited by the objectives and price set by clients at the beginning of the project. The engineering team will mainly focus on developing the product without exceeding the budget. As a result, they could decide to use lower-grades components to develop the product, just not to overrun the established price. Therefore, the quality of the product may be affected.
To sum up,
Don’t rush when thinking about a pricing model for your project. Take your time. Think carefully. It’s up to you to decide which strategy fits your ideas best. However, we hope this article will come in handy for you. If your project is a short-term project and all the details are clear to define, you can consider going with fixed-price approach. However, time & materials strategy is a good compromise in any other case. (Read this as well: Waterfall vs Agile: Which one is more suitable for your project?)