Software development companies are often reluctant to enter into fixed bid contracts where the price of the final product is not related to the time and resources spent on delivering it.

However, not all clients realize that such a model can also carry specific risks for them, too.

In the fixed bid model, the process of negotiating a software development project begins with the Request for Proposal prepared by the client.

The RfP contains a description of the client’s vision of the future product and the goals it should achieve. The client circulates the RfP among the companies and freelancers who start bidding. The client then analyzes the bids they receive and chooses the provider offering the best price.

Since recently, software developers tend to avoid such relationship model.

According to the US Government, structuring contracts should ensure:

  • frequent deliverables, not multi-month milestones
  • the flexibility to adjust feature prioritization as the project evolves.

The model of RfP and subsequent bidding created a basis for comparing the prices by different providers, estimating the time required to complete the project and minimize the eventual risks.

However, unlike other industries, software development seems to be governed by different principles for which the fixed bid approach is far from optimal.

 

Price Comparison

Of course, clients should be able to see the price offered by each contractor before they select the one they wish to cooperate with.

At the same time, during bidding, the client and the developer should agree on the scope of work to be done under the contract.

In other industries, for example, furniture manufacture, the woodworker creates the piece according to the drawing prepared by the furniture designer. The drawing shows in detail how the piece of furniture is to be produced. Furniture has been built for centuries, and usually, the client knows and understands what they want to receive.

At the same time, furniture manufacturers can estimate the cost and time required to produce the item.

However, if the ready furniture needs to be modified, this can lead to very high additional costs.

Thus, upfront design and planning are essential.

In software development, the goals the client is seeking to achieve are not that clear from the beginning.

In many cases, the client wants to create a new, unique solution using new technology.

At the same time, a delivered software product can be modified at low cost, if needed.

Therefore, if a software development project starts with negotiating the final result, such negotiations cannot forecast the way the product is accepted by the end users.

If the developer works according to the RfP, they will only build the product described there instead of the most optimal outcome possible.

So, to guarantee the best result, the clients should analyze the development company’s or freelancer’s portfolio rather than comparing their price bids.

Asking for references and looking for online reviews by previous clients can also help to understand the quality of the developer’s work.

Also, the clients can compare the project price according to the units of time required to do the job, rather than units of work.

 

Project estimation

Project estimation process in software development also has its peculiarities. On the one hand, repeated tasks can be automated reducing their estimations almost to zero. On the other hand, new tasks are difficult to estimate upfront, because too many factors are unknown.

Only after the task is accomplished, the time and cost it required can be evaluated.

A software development product estimate can be more accurate if the focus is shifted to the ultimate result; the project should achieve rather than individual features.

When the desired result is known, the developer can create the simplest and the most straightforward solution allowing to achieve that result.

Also, the client can contact the development company just to design, prototype and outline the product, and in this case, the investment is going to be much lower.

 

Client’s risks

Any business transaction involves a certain risk.

To reduce risk to the minimum, both parties agree on the scope of work beforehand.

Otherwise, the final cost may be higher than the client expected and planned.

The fixed bid model was intended to prevent such risks.

Indeed, a fixed bid may reduce possible risks for the client, which is the reason clients prefer it so much.

Clients believe that as soon as their RfP and final price have been discussed and agreed upon, everything is settled.

Any deviations from the initial agreement automatically become the developer’s responsibility.

At the same time, a software product developed in very tight conditions as to the time and resources may prove to be more expensive in future maintenance and update.

Eventually, the client’s costs may be even higher than initially planned, which was exactly what the client wanted to avoid.

There is no way to guarantee that a project will never exceed its budget.

To minimize the risks, the client should choose a development company that can work on the project in the most cost-effective manner without sacrificing quality.

The client should choose the company able to deliver the simplest product performing the defined goal. This may reduce maintenance costs in the future.

 

Conclusion

Many clients prefer fixed bids thinking that such contracts involve lower risks.

However, developers are reluctant to enter into such agreements.

Sometimes, a development company may come up with a wild guess amount in an attempt to agree with the client. This may be not an excellent service, as while the client insists on knowing the price upfront, this is not the best solution for them.

Clients looking for a company or contractor to develop a software product should think twice before engaging a developer prepared to make bad decisions with the sole purpose of winning the contract.

The recommended way is choosing the developers they can trust.

The client can decide that a developer can be trusted by reviewing their references and portfolio, discussing the project result rather than individual features, agreeing to build the product by increments, requesting prototypes and approving the smallest scope capable of achieving the result.

Only in a trusting relationship, the client will work together with developers and can be sure that their product will be top quality.

Back to Playbook