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.