Why we refuse fixed bid engagements

By Vagmi on 20 Dec 2016

A lot of clients ask us why we do not take up fixed bid projects. Many often think it is because we do not want to commit ourselves to a project but that cannot be farther from the truth. We care about our clients and our engagement and that is why we say no to fixed bid projects.

Usually clients put significant effort into authoring an RFP and send it out to multiple consultancies or agencies. They usually require information about the price, the number of consultants with the relevant skill sets on the team and prior work that they have done. Any business transaction involves risk for the parties involved. RFP seems like a good idea to reduce risk as the price of the solution is decided before hand and it is up to the developer or the consulting agency from that point on.

Except that this logic is fallacious. The most important piece in the RFP is the scope of the work. The business makes money selling a product or a solution and the consultancy makes money selling time. Even if the consultancy engages in a fixed bid contract, the main cost driver for the consultancy is time spent on the project. So in the process of finalizing a fixed bid contract, the consultancy and the business will attempt to nail down the scope in excruciating detail. This ends up being a lose-lose proposition. Organizations both big and small have been moving away from such a process and are considering a more agile process. US government in their well articulated digital services playbook encourages organizations to structure contracts that support the flexibility to adjust feature prioritization as the project evolves and have frequent deliverables to validate the solution with its users. If, the business and the consultancy agree early on what needs to be built without user feedback they end up building a solution that does not fit the market need. This is a bigger risk than a failed delivery.

Even with a fixed bid engagement, a business can never be sure that the project will not go over budget. If a consultancy rushes through development to finish off the points in the RFP without properly engineering the solution, they may still satisfy the contract but the cost of making incremental changes to software becomes exponentially higher.

Software development is also very unique when it comes to estimation. In the open source world, anything that can be automated has been automated. So estimates to the repeatable portions are almost zero. They would usually involve getting a library. So the value that a business provides solely relies on the known unknown (the problem that the business is trying to solve) and the unknown unknowns (how do these subsystems work together) problems. Estimates do not work for any task that involves more than a day or two. If we are to chart out the dependency graphs between the software components and take into account that they are all moving targets with an independent velocities of change, it makes it very hard to estimate in advance what it takes to build a given solution. That does not mean that there can be no planning. We can have a discovery session before the project kickoff to ensure we have product wire frames, broad goals and approximate timelines. Usually a technology architect, product manager and a designer are a part of this exercise to ensure that the goals of the product are very clear and the team agrees on the paths they can take to achieve it. There will usually be more than one way to get to the solution with different tradeoffs. Taking the RFP based fixed bid approach may not get you the appropriate solution.

From a perspective of a product owner the value of a solution is in the problem being solved. We can ship a minimum viable solution for one part of the system while we can focus the engineering efforts on the part of the system that would act as the differentiator that solves the biggest pain for the user segment. Over time we can improve other aspects of the system making them more robust. As with any other form of process improvements law of diminishing returns also applies to software engineering.

Software solution once deployed requires far more maintenance than other forms of assets. The underlying platforms are constantly upgraded and there are security patches and improvements constantly. Also upgrading early avoids technical debt in the system as some of the future components you might want to use might have dependencies on newer versions of the underlying platform. Case in point, many ruby gems stopped supporting versions 1.8 as soon as 2.0 was released. Also, when XCode 8.2 was released, it completely dropped support for Swift 2.x which was released just over a year.

In conclusion, the RFP process is a Kobayashi Maru of software development. It sets up the engagement in a lose-lose scenario for both the clients and the consultants. Instead of comparing bids, we recommend that our clients look at our previous work or engage with us on a paid short term assignment (1-2 weeks) to evaluate us.

comments powered by Disqus