Fixed Price Contracts: A False Sense of Security?


Business handshakeMany customers prefer fixed price contracts. It makes them feel secure. They know what they will get, when they will get it, and how much it will cost. Or do they?

Pitching contractors against each other on a fixed price may seem like a good idea, but what effects does this have on bids, the project, and – consequently – the final result?

Saying no to a contract is difficult, especially for a small company. Estimated times and costs may therefore be questioned internally. The persons responsible for the estimates feel pressured to adjust them.

Eventually, the only thing left to change is quality: all other variables are locked in a fixed price contract.Project Triangle: How cost, time and scope relates to quality

Project Triangle: Only two things/sides can be changed without affecting quality

Probably the contractor doesn’t influence quality deliberately. Quality is, however, very difficult to measure. The project may deliver according to specs, passing all acceptance tests. Years later, however, when new features or integrations are required, technical debt may become a big issue.

Preconditions for a Fixed Price Contract

For a fixed price to even be legitimate, the following must be true:

  • Adequate requirement specifications.
  • A well defined change request process.
  • A thorough risk analysis. (This is true for all projects, but especially so for fixed price contracts.)
  • Agreed acceptance criteria: well-defined acceptance tests.
  • Working with a well-known technology in a proven environment.

If these preconditions aren’t fulfilled, the contractor should think twice before settling for a fixed price contract.

The nature of software development means you are always – more or less – working in a volatile environment. Of course, contractors compensate for this when bidding for a fixed price by introducing safety buffers.

Customer Risks

Pushing too hard for a knockdown price have implications. The customer faces at least three apparent risks:

  • Degraded quality
  • The project runs late
  • Collaboration suffers

Quality is controlled by the requirement specification and acceptance criteria. This only works to a certain degree. It is impossible to cover all aspects of quality through these mechanisms alone.

The quality of a project is affected in many ways. It can be difficult to spot exactly when and why quality degenerates. Some things that may be overlooked when on a tight schedule, that eventually affects quality, are:

  • Code is not refactored
  • Code is not commented
  • Insufficient tests

Contract regulations, requirement specifications, and so on, ultimately affects collaboration. The atmosphere becomes competitive and the parties start to blame each other instead of solving problems together. The customer becomes detached and hands over all responsibility to the contractor.


In my experience the customer and contractor both lose out on a fixed price contract. Obviously the contractor takes a big risk. While it might seem like the customer has nothing to lose, to get the most value out of the investment, it is better to choose another contract form.

As a customer, if you are not 100% sure there won’t be any changes, a fixed price can be a costly affair. Not only will you have to pay for any changes. There is also an overhead in terms of administration and contract negotiation. You also draw attention away from producing a high quality product maximizing business value.

1 comment: