fixed price

project risks

managing risk

cost plus contracts

project risk management

fixed price analysis

Fixed Price Model: Why It Never Works Quite as You Expected

Fixed price contract is when one project party ends up being fooled by the party it itself is trying to fool.

One could argue that it's not like that, claiming that a fixed price contract is a great way to lower project risks by removing a pack of unknowns from the equation and hence pave a solid way for the project success.

And while one could indeed have a point in the world of small projects with a low degree of uncertainty, I'd respond that such projects are so scarce in the real software development world that they do not worth considering at all.

In other words, the fixed price doesn't work for the majority and there is almost no doubt that your project belongs there.

A bold statement that needs to be proven. Sure.

The Fixed Price Incentives Overview

First off, it'd be logical to examine the key advantages that a fixed price agreement has over the time-and-material model. There are 3 of them and the 1st one is pretty straightforward — predictability.

In whatever light you look at it, the fixed price is an attractive option primarily because everything is predetermined. You know how much money will be spent, how much time will be consumed, how much work will be done and what this work will be — it's just an excellent ground to plan and make further business moves.

Another thing that excites your customer's mind is that the fixed price model implies the minimum of liabilities from your side. The entirety of responsibilities for the project success is to be laid upon the team members' shoulders, which is great. If they fuck up anything, if the project objectives are not achieved or the promised is not delivered — they are to blame and be held accountable.

The third point is the age-old money saving. With the economic price of works established, the project team will waste not a single of your dollars while being more concentrated and productive. Otherwise, they fail and the consequences will come. Besides, since there is so much of what the developers are accountable for, it's really easy to carp and then make them do more within the same contract, i.e. force them to work for you for free.

That's the catalog of goodies that you, the client, expect from the fixed price-based cooperation. Now let's look at the list of advantages that the given cooperation model brings to your potential contractors.

And this one is not going to be long. Because there are none. Except for some terrific overcharge opportunities, of course.

More on that later.

Identified Risks. Not for Yourself Though.

With the three pillars underpinning the fixed price billing in the software development field established, let me switch to explaining why none of them is quite viable.


While it sounds so enticing to make a contract where all things are set and all actions are predefined, such an agreement is just not what you want when it comes to a software project.

I've partly covered it in this article, but, since so many mistakes tend to be done in this very area, I'd like to pay some extra attention to the issue.

If it's not a project under $10k and you're not a seasoned project manager plus a senior developer plus a veteran business analyst, no matter how great your planning is, things gonna change. The features you're planned for will become irrelevant, the market you've focused on will command for something you didn't predict and so on and so forth.

And when things start to change, you don't want your team indifferently quoting the terms of the contract and asking why would they care about the unexpected twists in your business path.

But that's precisely what is going to happen if the price is fixed. Or, you will need to pay extras along with signing a new contract every time you approach the team, which not only sort of ruins the idea of a fixed price project, but is also counterproductive and pretty awful for your personal experience.

As a result, all the project risk management efforts make no sense at all. Yes, in the end, you've got what you wanted and paid fair money for that, but what's the point if that is not what your business needs at that moment?


As I've already said… in a pub, that Friday night… software development is not about you dropping orders and the team following them aka soldiers. It's a constant flow of information in both directions, translating into the more or less equal shares of responsibilities and the distribution of potential risks. It's crucial for the overall project success that this balance is kept.

By trying to hang too much on the team, you're effectively ruining the synergy and no matter how that feels at the beginning, you'll be the only one regretting that in the end.

The negative effect of the team being overloaded with liabilities shows as a seamless shift of their focus, from "How do we make a great thing" to "How do we fulfill the contract and make that dumbass happy". And, judging from my own experience, I can say that it has a huge negative impact on the project.

Developers lose interest in what they are doing and the management starts to think about how to cut corners and stay inside the box that you've constructed. The worst thing though is that the fixed-price agreement prioritizes time over quality for the contractees — the less time they spend on your project, the more they can spend working on something different, making more money.

No need to explain that not a single piece of great software has ever been done that way.

Cost cutting

Buy nice or buy twice. This saying describes the difference between the T&M and the fixed price almost perfectly.

To start off, the people you're going to hire are not dumb. Well, if they are dumb, you won't succeed anyway, no matter what sort of agreement connects the two of your parties. The not-dumb project team tends to understand the risks associated with the fixed price contract and take steps to offset them. And there won't be any ingenious moves, there will be a straightforward overpricing, up to 200%.

Moreover, if they are experienced (again, nothing gonna work if they aren't), they will expect the typical "fixed price behavior" from your side, meaning that none of your sort-of-fair money saving tricks will have any significant effect.

In the end, the team tends to do more than expected because there is always something that they missed at the planning stage. However, while the amount of extra work is normally rated at 20–50%, the amount of extra money that you've already paid can be 80–100% and more.

Feel the difference?

When Fixed Price is a Thing

Fixed price is great when you need to buy a bottle of milk, primarily.

When you need to be acquiring something more complicated and expensive over an extended period of time, fixed price tends to be not the best option.

There are, however, 2 exceptions to this rule and I'd like to mention them.

The first one relates to the size/price/duration of the project — these have to be really small. If the work is not going to be particularly complicated or prolonged or expensive, you won't need much space for maneuvering, meaning that the word "fixed" in the contract description won't do much of a harm.

I'd set the bar somewhere at $10k and 150 hours of work. Below — the fixed price is acceptable. Above — it's not.

The second exception is about the complexity of works and your readiness to pay for them.

Let me put it this way: if the job is simple, you can hire newbies. If you hire newbies, you indeed can circumvent them using the fixed price contract, making them work more and more for the money they've already worked off.

In case you need a set of simple features that nonetheless tend to be expensive in the end and your project management plan is all about cutting the expenses a perfectly legal but not that ethical way, the fixed price may be the answer.

It's nothing personal, it's just business, right?

Just make sure it's not you the newbie paying twice the price, it's the team that is doing twice the work.

Or the fixed price model will never work quite as you expected.

Pavel Suprunov
June 4, 2019

Read more: