What’s wrong with fixed price contracts?

When presenting the agile approach to audiences new to the ideas, one comment is by far the most common. It is: “How can we do this, we have to work with fixed scope, fixed price contracts?”

We will cover this question in a three part newsletter, here is the first part “What’s wrong with fixed price contracts?”:

When practicing agile software development, the focus is on delivering customer value every month, sometimes even more often than that. Every iteration we do completely develop a few of the highest priority features. At the end of the iteration, ideally, the feature is finished and already deployed at the customer site. No work remains and the feature is actually done when we call it done. The customer knows exactly what the status is and may be able to start profiting from the partly finished system very early. The team benefits since it can forget about the previously developed features and move on at full speed to do new tasks. We also embrace change by allowing allow our customers to change priorities and add and remove requirements at any time as they wish. As long as we did not start working a feature already we allow this at no cost, no fuss. This is currently the most efficient and proven method to develop software known.

So, how does this relate to contracts? Traditional thinking is that by specifying and controlling scope you can protect yourself so that the other part will not take advantage of you. Trying to fix and control scope leads to some severe unexpected consequences though:

  • Trying to limit scope, actually makes scope grow. Customers tend to put everything they can think of in their fixed scope requirements specifications. Then they put some more stuff in, just in case. They know that if they do not get every possible feature into the requirement specification, the supplier will try to squeeze out lots of money for changes later. Thus, on average 64% of the features in the requirements specification are things that will be seldom or never used. I.e. compared to a project focused on delivering value, trying to fix and control scope has more than doubled the project cost by wasting time on documenting and developing features of no value.
  • Another thing that buyers try to do by using fixed price contracts is to transfer the risk to the seller. For this the buyer has to pay a premium. But who owns the risk really? If the project fails to deliver, the buyer usually is the one that will be in trouble anyway. So, in practice the buyer is always the one owning the risk. Even if there is a fixed price contract with penalties for delays etc, this is usually of little value if a system needed for the customers business is not delivered.
  • Another aspect with fixed price contracts is that controlling scope and managing change takes a lot of resources. According to “Dyer, Collaborative Advantage, 91-96”, these types of costs dominate most vendor-supplier relationships.
  • Fixed price contracts are often awarded to the lowest bidder. Bidders know this and make bids that barely break even. The profitability of the project is then saved by charging big sums for changes. On average, 35% of all requirements change during a project, so this is a safe strategy from the seller’s point of view. The problem with the strategy is that it fights change and puts strain on the buyer-seller relationship. Change is legitimate and there are numerous reasons why change will always be needed. Without change, optimal value will not be produced. Yet, fixed price contracts makes changes hard and thus it does not create the best possible customer value for the money invested. The reason behind this problem is that the contract type does not align the goals of the seller and buyer. Thus it creates a non-productive, inefficient, climate for cooperation between companies.

So, perhaps you agree by now that fixed price contracts are pretty useless tools if you care at all about getting giving your customers value for their money? Or perhaps you don’t care about value being delivered to your customers? In that case you better hope that all your competition feels the same. All it takes it that one of them starts delivering value, and then your offerings may not be that attractive anymore.

In the next part of this newsletter we will talk about how to turn fixed price contracts into something workable and mutually profitable by using agile development. So stay tuned, and maybe wasting time by arguing over contracts can soon be history…

– Henrik

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s