Fixed price, fixed scope is broken contracting

Over the past week I came to realize that fixed prices, fixed scope contracts are broken. I am not sure who came up with the concept, but I sense a larger dynamic at play. Let’s explore what’s causing so much trouble around fixed price, and fixed scope contracts.

One of the last activities in a previous job was to work on a tender offer for one of our potential clients. The tender surrounded around a company whose major shareholder was the government in an Eastern country. The country had two different calendars: the Gregorian, and the Sambat calendar. The former one should be well-known. The latter one is based upon moon phases where a committee gets together to decide which upcoming months will have 28 or 32 days.

Since the client worked under the laws of the government, they had one requirement in their tender documents. All input and output dates should support both calendars. For outputs that meant to list both, the Gregorian calendar date, as well as the Sambat one. For inputs we would need to figure out how to separate the data by either the Gregorian calendar, or the Sambat one.

While working through the documents, I sensed a large risk for this requirement. Needless to say that few developers (and architects) ever think about supporting a different calendar implementation. Our system also dealt with three different programming languages. Since all of them had interfaces to the outside world, all of them needed to deal with these conversions. For the Java component it took me two days to find a working implementation – up to the year 2040. Our system supported dates up to the year 2200 internally.

Of course, this was one tiny piece of requirement. The client was rightly asking for that implementation. After having thought of it for a couple of days, I decided to pad my estimate, and put down a note about the upcoming effort – knowing that I won’t be with the company any more to implement. (I already had quitted my job at the point of time – for other reasons.)

What happened? The tender application asked for a fixed price, fixed scope contract. Needless to say there were about 10 documents with 100 to 500 pages, listing several such requirements. There was a large batch of requirements thrown at us. The project would take a couple of years to implement fully. We were asked to tell our sales department whether our software product already supported some of the requirements, and where the risks lie to determine the final price that we could bid on this.

Overall the tender application took several weeks at a point in time where we had a shallow understanding about the requirements. Also pricing in these situations is merely one factor. There are always political reasons involved as well. I did not track whether my former employer actually won the bid. What I know is that I was sub-optimizing. I was sub-optimizing because we were at the bidder side. I had a shallow understanding of the underlying calendar system. I needed to trust the third-party implementation. Maybe our requirements analysis would come to a different conclusion when working on it. All we needed was give out a price tag for the final bid.

Of course, there are competitors. In order to win such a bid, you need to keep their pricing in mind. Maybe you have a second channel into the organization, and know how to trick the system – thereby neglecting all the information that you can get from your staff. But these more political reasons come with a price. You are probably giving out a system that is costing you more to implement in first place.

What usually happens with contracts like these is that the bidder does not want to deal with all the risk and losses on their own. So, they put a clause in there that makes changes to the initial scope more costly. Thereby the bidder can still earn some amount of money.

Queueing theory taught me that the larger the batch sizes, the more likely there will be changes. So, on a systemic level, if you receive a huge tender application, there will be more changes attached to it. So, underbidding a competitor comes with a risk, unless you recognize that you can charge more for change requests. Since the likelihood of change requests with a large batch of requirements like the ones found in tender applications raises, as a bidder you can dramatically reduce your implementation risk by bidding on large tenders – with high costs for change requests.

For the customer, the more expensive such change requests become, the more likely the customer will ask for more detailed requirements, put more staff in the tender, and thereby increase the batch size. Since he becomes disappointed by the amount of change requests with these large batches, he will try the next time to get down more detailed requirements, thereby increasing the batch size even further – only to be disappointed even more.

Notice that there is a vicious cycle involved in this game. The bidder is sub-optimizing for his costs. The customer is sub-optimizing for more value. In the worst case this is a lose-lose game. A terrible idea for the whole industry.

But how can we fix this? I think we need to recognize where fixed price, fixed scope contracts come from. My imagination about this is that customers want to have insurance about their budgets. Thus, the origins for fixed price, fixed scope contracts probably lie in the underlying budget constructs that are widespread in the industry.

If we want to solve the situation, we need to work on two frontiers. First of all, a tender shouldn’t cause a bidder to produce crappy software. The current construct found in our industry does just that. Deadlines, fixed scope, and high ambitions together with wishful estimation lead to more rushed implementations that eventually lead to less quality for the customer in the software that we create.

But crappy software is not the origin. We need to work on our trust relationship with our customers. Over time we can achieve that they see a trustworthy software development shop in ourselves that is able to steadily add value for them. Only then can we break the positive reinforcing feedback loop that creates the vicious cycle in the overall scenario. If the customers receive the feeling that they can still step out of a contract after three months because it stopped working for them, and they still can maximize the value they get out of it, the whole industry would be better off.

So, why don’t we take the first step to create that trust-worthy relationship with our clients by inviting them every couple of weeks to present them our latest features? Maybe that could be helpful after all.

  • Print
  • Twitter
  • LinkedIn
  • Google Bookmarks

One thought on “Fixed price, fixed scope is broken contracting”

  1. I agree in principle, but I think that contracts are inherently a vehicle for mitigating risk in low-trust environments. Any time a company assumes risk, they should get paid a premium for assuming that risk. As a buyer… if I want a fixed time, fixed cost, and fixed scope contract… I should pay a premium to the seller becuase I have shifted my risk to them. As a seller… if I want to shift my risk to the buyer… and enter into a time and materials contract with no committment to scope… my potential upside should be lower because the customer has assumed the risk. If the relationship is such that both parties assume risk equally, the reward should be blended. It’s not that fixed time, fixed cost, fixed scope contracts are broken, it’s the economics of the risk/reward equation that isn’t understood. This happens becuase usually either the buyer or the seller is in a more powerful position and chooses to take advantage of the other party. You have a buyer with money and an over-optimistic seller hungry for the opportunity. The seller takes the deal not understanding the risk and looses. Again, I think the root cause is not understanding the economic risk, and how risk is being bought and sold, that is the fundamental flaw.

    If a client hires my company for 4 days of consuting ,and I have a team of people that are on salary, I assume all the risk in that transation and must charge a premium for my services. If a client hires my company for a year with early termination penalties, I can afford to offer a discount becuase of the guarantee. Whoever assumes the risk is the one that gets the money.

Leave a Reply

Your email address will not be published. Required fields are marked *