Not only is a fixed bid project a bad idea, it’s actually a myth and doesn’t in fact exist.
Let me explain.
Let’s say you want to launch an MVP, build a new product, or upgrade an existing application. You have a vision and scope. You also have a budget in mind. And now, you set out to build and launch the product. You find a team to build your product and then you ask, “How much is this going to cost?”
You have two choices when it comes to paying for this project:
Fixed Bid: A fixed bid project fixes both scope and price at the beginning of the project. Sometimes, there is a target launch date.
Time and Materials: A time & materials project fixes an hourly, daily or weekly rate, and leaves scope unfixed. Sometimes, there is a target launch date. Sometimes there is a budget cap.
In reality, this is a dangerous myth. It's like “betting it all on black” (which has 37 to 1 odds). Sure, you might win, but likely you’re going to lose it all. In fact, 85% of fixed bid projects go over budget.
And do you know what happens when your fixed bid project goes over budget? All sorts of misalignment occurs. As the stakeholder, you don't want to pay another dime. You want your project delivered now with the full scope complete. However, the development team has to essentially finish the project on their own dime. Unfortunately, the majority of development teams that take fixed bid projects will then ‘rush’ to get your project done, because it’s no longer profitable for them.
This promptly leads to crappy work, or at the very least, less polished work. You and the team that’s creating your vision are totally and completely misaligned at this point. You want high quality work, they want quick work. This is true whether you have your in-house team build it or if you outsource the project. Bad things happen when stakeholders and development teams are misaligned.
Once you come to terms with the fact that a fixed bid project is a bad idea, the solution is to identify the one variable you do want to anchor around. There are three variables to any project: Money, Time, and Scope. Figure out which one you care most about, and set an anchor around that. And then, be at peace with the truth that the best chance of you achieving your anchor goal is by having some flexibility with the other two variables.
To learn more about how to get your contract to be aligned with this thinking so that your contract is truly Agile, check out I’m Agile But My Contract Isn’t.