Intro

Many software executives and product managers find themselves in a position where they just don’t have the resources to complete a project in-house and decide to partner with a remote software development team. This might be to launch an MVP, develop a new product, or perhaps just build out a new feature set within your existing codebase.

Next you have to answer the biggest question in working with an external software development team: whether to use a fixed-bid, or an hourly rate (a.k.a “Time and Materials”) contract.

As you can tell by the title of this article, I am skeptical of fixed-bid software projects. Too often, implementing fixed-bid projects creates tension between the dev team and the client, and neither side ends up happy. Why does this happen? Why are fixed-bid software projects notoriously challenging for remote software teams?

Fixed bid is a term used to describe the situation when a client pays a fixed price for a fixed scope of work. Why does this model so often cause the relationship between a developer and a client to inevitably end up in at least one side (and usually both sides) not being happy with the co-operation?

This article will shed light on fixed-bid software development, why it’s so challenging, and what to do about it.

What is a Fixed-Bid Contract?

A “fixed-bid”, or “fixed-priced” contract is defined as an agreement to provide specific software services to the client, for a specific price. The price is set at the beginning of the engagement and does not change during the development of the product.

The main advantages of the fixed-bid projects can include:

• Cost certainty. Clients like the idea of fixed-bid projects because the client knows exactly how much they are paying.
• Simplicity. For remote dev teams, the responsibility for maintenance and upkeep of the product remains with the client.
• Budgeting. Clients know what they’re paying and can allocate resources to the dev team and other projects and needs.

This type of contract is quite appealing to clients due to perceived financial certainty. Clients often assume a fixed-bid also means a specific time frame and precise scope of work is guaranteed. However, this is rarely the case. In the end, the experience of the fixed-price software project often turns out to be painful for both sides.

Expectation vs Reality

In any software project there are three variables: budget, time frame, and scope. For some clients, fixed-bid software projects are enticing because they believe all three variables are fixed and guaranteed.

And yes, sometimes that can happen. In a perfect world, feature sets are well defined, dev teams don’t encounter any tech-debt or unforeseen problems, and clients never change their desired scope. Sometimes, everything really does go smoothly, and everyone walks away happy.

Unfortunately, this is not always the case. In reality, software development is complex. Features change, APIs don’t work, client timeframes shift. It’s inevitable. In reality, the three variables in software development are ever-changing. So fixed-bid software projects are not always a good solution. However there are cases when it works.

Reality dictates that you can really only ‘fix’ two of the three variables. Understanding this allows fixed-bid to work in some scenarios. Below is a detailed breakdown of when to use three common types of fixed-bid projects, and how to go about them.

“Fixed Time” and “Fixed Budget”

In this scenario the desirable features should be estimated right from the start.  This ensures the dev team can operate as efficiently as possible. The team can work in a methodical and logical order to maximize efficiency. Often this seems like the ideal way to structure a contract.

However, the more common outcome is that after the development team starts work, the client discovers new features that he wants to add to the project.

Unfortunately, continuously updating the product’s features and adding new elements that were previously out of score, affects the established timeframe, and the budget. It is natural for a client to change scope, but logically, it means the timeframe and budget will change.

So, if the client wants to adjust scope frequently, they cannot rightfully expect a fixed budget and timeframe. Otherwise you’re asking the dev team to work more hours and produce more value, at an unfair price.

This type of contract really only works when the client has a very specific, and well defined set of work, with little to no variability in scope.

“Fixed Time” and “Fixed Features”

For a dev company to have a fixed timeframe and a fixed feature-set, the client must be willing to cover any amount of costs incurred by the dev team to get the project completed.

In this case, the most successful offer for both sides is to follow the hourly-paid contract, in other words, a Time and Material project. To pay hourly will allow the dev team to work on the most pressing assignments while getting paid appropriately for changes in scope (both increases and decreases).  Thus, hourly payment guarantees that both the client and the dev company are mutually incentivized to operate in an efficient and cooperative manner.

This type of contract can prove difficult however. While it typically works well, this model can require that the dev team have many extra developers available to help meet deadlines. This can be a challenge for the dev teams project managers, and can lead to unforeseen costs by clients.

“Fixed Budget” and “Fixed Features”

This case suggests a clear assessment from the client as well as the development company. The relation between the fixed budget and the product’s features might influence the time frame, and when the product can be released. The dev team can provide feature estimations, and the client can feel safe due to the fixed budget.

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. Clients can get frustrated at time delays, even though they are getting the stability of a fixed price.   

You Don’t Know What You Don’t Know

In software development, it can be very challenging to know what features are necessary, and which are unimportant at the beginning of a project.

It is quite common for clients to assume that what he wants is exactly what the market and users need. However, it might turn out that some features may be challenging technically, with little market value. This can lead to developers burning time and money on a feature that wasn’t properly scoped by the client.  Other times some features are so popular, they need to be expanded to build the product’s success. Both cases create challenges for clients and developers when a fixed-bid contract is used. 

In software development, the spectrum of potential issues is almost infinite, especially when it comes to creating a complex application. In such conditions, every, even the most experienced developer, will be prone to making errors and the estimate will be inaccurate.

Simply put, things change. Feature sets change, budgets can be increased, and new business development opportunities may change which features need to be delivered first. In order to maximize long-term success, software development needs to be approached with flexibility.