The business of software and the fixed bid quote
Clients believe a fixed-bid contract controls their costs. True, but it could also mean you’ve tied yourself to a contract that prevents you from getting the solution you really want. Is it worth it to pay less for a product that is not exactly what you envisioned?
In custom programming, with the fixed bid contract, the agreed upon fee covers the entire project and will not change as long as the requirements don’t change. On the other hand, in the Time and Materials contract, the scope of the project, along with an hourly rate is agreed upon, but the final cost of the project depends on how long it takes and the additional expenses incurred. Both the Fixed bid and the Time and Materials agreement involve estimates. Estimates help both parties settle on a price and duration the project will take. All big projects that involve some risk will have a range of the estimate. There will be a high estimate and a low estimate. The greater the risk in the technical ability to actually do the project or the stability of the requirements of the project the greater the range will be between the low and high estimates.
From the client’s point of view, the fixed bid feels like a no-brainer. What with the predictable installment payments made possible by the concrete budgeting, making everything much more straightforward. It also gives the impression of costing a lot less since there’s no chance any complications further along the road can increase the cost of software development. And you know you’re getting whatever is defined in the contract. This is a reassuring feeling, and it can make budget approval far easier, and you’ve pushed most of the risk onto the provider because if the project goes over budget, then the provider will have to pay from his pocket.
From the developer’s perspective, time & materials contract is the more friendly option since it allows the flexibility needed to focus on building the best software rather than figuring out how to battle a budgetary brick wall. With a fixed bid estimate the main worry is scope creep when the requirements expand into new areas. As a provider, you want the best for the product, but too many new requirements will break the budget.
Why we are conditioned to go for the “Fixed Bid.”
In our routine lives, we have always got the ‘Fixed Bid.’ When we walk into a hospital with certain symptoms, we are diagnosed and given a price for the treatment and medication. If you have a common cold, it shouldn’t take more than a tonic to fix. Most diseases follow a certain rulebook that requires certain medication and consumes a specific amount of a doctor’s time. So we merely take the hours required times the billable rate of the doctor and we get our price. The requirements and the results are understood for the job going in.
Same goes for building a new road, repairing old equipment or getting your car fixed. These jobs have been done enough times before and to predict what the outcome should be. Now, if we ask the road builder to build an extra bypass lane, then we pay more because we have asked for something more than was promised initially. In all these situations, we believe we are paying a fixed bid amount, but in reality, we are paying under the ‘Time and Materials’ contract because the process is so predictable. The risk in these situations between the high estimate and the low estimate is very small, so is the risk of requirements changing.
How does building software differ?
Building software is a dynamic process. This is what gave birth to methodologies like Agile and Scrum, to make the process of building software more efficient. Building software is a process riddled with daily, or even hourly, changes. It might not be possible to create certain features as originally intended. Or the client might even want to embrace a new direction because of the changes in the market.
A successful software project runs with small iterations so that the stakeholders can actively prioritize and manage the requirements of the project. It is impossible to entirely capture all the requirements for any complex software project up front. Of course, the team leads, architects, and stakeholders gather a certain number of requirements and artifacts to do estimates and to veer the software team in the right direction. However, to base a binding contract based on those initial requirements is places a lot of risk on both parties.
The truth about Fixed bid quotes
Fixed bid estimates has a long history with software contracts, but we need to recognize the risks associated with this form of contract. With a Fixed Bid contract, it can get hard to keep the crucial items prioritized because the client wants to get all of it done in a certain allocated budget. Whereas, with the time & materials agreement, one can hit the ground running and change the requirements on the fly. This method lends itself to a more Agile project structure. A project run under this contract has an inherent quality that says to prioritize the most important items first with each iteration.
From a client’s side, you risk not being able to change the requirements of the project. What if the market changes and you need to add a feature not agreed upon in the contract? What if a costly feature in the contract is hindering the completion of other features, and you want to drop that feature? You may not be able to contractually drop that unnecessary requirement. Or you might not even have the visibility into how the development process is going, to know that a requirement should be dropped.
From a service provider’s side, we all believe we can do it faster than the project allows for because we’re working with a framework we really understand, which we can just tweak a little and get it done. See, we’re all optimists here. Otherwise, we’d never get into programming. And fixed bids are tricky, and most software developers underestimate the time it will take to complete a project. With a fixed bid you are setting yourself up for confrontation from the start. With this sort of contract, it is in the service provider’s interest to do as little as possible and in the client’s interest to push for as much as possible within the budget. Add to it the problems every customer has enunciating their requirements, and you have a recipe for disaster.
Learning to give the right bids is the responsibility of the contractor. We start by telling you the least you are going to have to spend so that we can gauge whether you have an idea of the minimum amount of work required to accomplish the task. If you aren’t willing to spend the minimum, it’s not worth it to write a requirements specification. However, in a way its good that it’s not possible to specify everything up front. When as a client you attempt to lock everything down with great control, the whole process becomes rigid, turning developers into production line assemblers.
It all comes down to this. You need to trust your developer. It’s understandable that you are hesitant to hand over your wallet to a developer who might pack on extra hours and questionable added expenses just to pad the final bill. If this is your concern, you should be more focused on finding a developer you have faith in, rather than worrying about which contract to embrace.
CognitiveClouds: №1 SaaS Development Company in India