Price-Fixing

I’ve done a lot of projects in my time, both as a buyer and as a supplier, and most of them go badly. Having spent half a lifetime thinking about why this is so, my particular ire is aimed today at a very popular construct.

Fixed-price IT contracts are everywhere. Buyers love them because it supposedly gives certainty and removes risk. Suppliers love them because they get better control and better pricing power. Both sides thus sit across the table and hash out a win-win.

Acrimony doesn’t start till months later.

The most common reason for all the screaming is failure to do on-time delivery (usually by months) but quality is also a frequent problem child. The worst of it is that the main benefit of this — the fixed price — fails because you need to compensate for all the things going wrong.

Don’t get me wrong; in theory, there’s nothing fundamentally wrong with a fixed-price contract, just that those foundational assumptions it has been hoisted on almost always fail to hold up. Such contracts have a huge element of risk and a jumble of counter-incentives that lead to frequent failures. Let's take a look.

Fixed Work

This is really the core assumption of this kind of contract — that work is fixed and can therefore easily be costed for. The customer gives a fixed list of deliverables, and the supplier quotes a fixed price (and a fixed delivery schedule) against it. In theory, it should be like ordering a pizza — specify the crust and the toppings, give your address, pay a fixed amount and the stuff lands up hot and steaming thirty minutes later. Software isn’t like pizza though, and what should be a nice dinner becomes mired in all kinds of complexities.

When people hear fixed work, their instinct is to assume that this is all the work that will be allowed. The Gabbar Singh of this world is the Change Request — get your fixed work scope correct, otherwise, Change Request will come by (and presumably bad things will happen). Now change requests happen all the time in companies, and are natural and ongoing parts of any IT system. In fixed-price contracts, however, a change request is considered a bad thing that must never be allowed; this incentivises every stakeholder to stuff as many features as possible into the fixed-work envelope.

I would argue that, no matter how good a price you get it at, more is not better. IT systems work best when they are simple and focused, not when they have every feature on earth. More features mean more gaps in understanding, more chances of misspecification, more learning curve, more maintenance headaches, more of every kind of problem that plagues IT systems. A pepperoni pizza is a classic — loading it with a hundred toppings usually makes things worse. Teams need to be encouraged to pare their requirements down to the essentials, but this is rarely done. Multiple verticals contribute multiple requirements and there is usually a feeling that not contributing a requirement today that may be needed tomorrow is going to be a black mark, so maximise the laundry list.

Feature creep usually happens in three popular areas — User interface, workflows and reports. In the UI there is usually an over-emphasis on validations and usability and making things idiot-proof — it's surprising how many companies feel they employ idiots as users. Workflows that mushroom to deal with every contingency, no matter how unlikely, are another source of creep. Reports — everyone wants some variant and combination of fields and layouts for every possible need; many end up never being used.

There is no disincentive to asking for a feature, so why not. Price could be a disincentive but individual features are not priced individually, and in any case, piling on features is not a good thing even if there is money to pay for it. The only way to control this is management discipline — thinking of every superfluous feature as an impediment to project success.

Fixed Price

The second leg of this manoeuvre is just as difficult to get right. Estimates are just that — estimates — with some margin of error. Fixed price contracts, on the other hand, have no margin of error — the price is fixed beforehand and all such estimation errors must have been accounted for. Here the internal teams of the supplier have competing incentives — the sales team wants as low a price as possible, while the delivery team wants to reduce the risk of project failure.

These uncertainties are unique to IT. In other projects such as civil works or marketing campaigns, the level of uncertainty in project execution is, in my experience, much less.

For the team that is forming the estimate, three major uncertainties are at play:

1. The complexity of the requirement is uncertain. Something seemingly simple-looking may be very hard to achieve, or vice versa. It may also be that the supplier will understand something but the buyer intends something a little different but more complex. Much estimation of this kind relies on thumbs and guts, so also dependent on who’s doing the estimating. People tend to err on the upper side — overestimating rather than underestimating — to avoid going totally off base.
2. The availability of appropriate resources is uncertain. Resource availability is a particular challenge for IT firms because firms don’t want idle capacity sitting by waiting for a project to start. Most firms have idle capacity (bench strength) in the low single digits as a percentage of their overall workforce. Other constraints can also come into play — licenses, servers etc — but these are increasingly becoming relatively minor. People resources are the bid bad gorilla of bottlenecks. Sometimes it's an availability issue (in that there is no availability on the bench) but there’s also a programming team’s potential productivity. Depending on the dynamics of the teams, output can be good or bad and can fluctuate a lot even within a project so a job may be finished in one month or six.
3. The cadence and coordination of the players are uncertain. Many teams have to move in sync for a project to succeed. Users have to explain needs in time, developers have to develop in time, testers have to test in time and so on. On a spreadsheet these parts don’t move and hence line up nicely; real life is a lot more messy. Resource planning in a software project is entirely black art; as Mike Tyson says, everyone has a plan till the first punch lands.

How does one deal with these substantial uncertainties? In a word, buffers. And cascading ones too — estimation buffer, project buffer, negotiation buffer, payment risk buffer, delivery risk buffer, ramp-up risk buffer and so on. Generous, generous buffers. This is why sellers love fixed-price contracts — they’re usually quite profitable because in most cases the buffers are enough to compensate for the risk and more. If high risk is not attached to high reward, many companies would be going bust — but most IT services firms are quite profitable indicating that the rewards are indeed high. Fixed price shifts pricing risk from buyer to supplier but in the process the buyer pays a fat premium.

The next challenge with fixed-price contracts is the sales cycle. In a world of competitive bids, multiple parties are trying to outbid each other for the same scope of work. In theory, this should lead to better price discovery; in practice, it rarely does so. Suddenly, you’ve given Engineering too little time to properly estimate, and Sales the incentive to believe in the most optimistic version of such estimates. This problem amplifies with each iteration — proposals are less well estimated, and Sales is more convinced that nothing will go wrong. In the end, this is what you get — a project whose plans are inadequate because the assumptions are too rosy — the supplier increases the chances of winning, but also the chance that the project will go off the rails.

Thus, what you’re discovering in the bidding war is not price but the risk appetite of the parties — a gambler’s strategy for betting rather than the serious scientific model your spreadsheet convinced you of. The cards will anyway fall where they must without looking at the contract, and things will go the way of most gambling strategies. The odds are still stacked in favour of the bidder, so most projects will leave the buyer worse off. Remember, the buyer is the one that initiates the fixed prices (and is responsible for some of the risks being high) but is the one bearing the cost of failure in almost every case. Unfortunately, the buyer keeps repeating the process — convinced that this project will be in the winning minority.

The Three-Body problem

As we see in practice, many projects fail to deliver. This, of course, is what real-life gambling looks like — the odds always pan out. Long delays, sometimes much longer than the original project duration itself, is the norm rather than on-time delivery. I have almost NEVER seen a large project being delivered on the date signed for during contracting.

Unfortunately, time slippage is the most costly of them all.

Time slippage for the buyer is opportunity cost. Most buyers would rather launch a product quickly that makes money rather than save money by delaying the launch. This is because most projects have significant positive leverage — the return is much higher than the investment. A loan system that costs a few crores total will generate hundreds of crores a month in revenues — every month lost is thus hundreds of crores of revenues lost. This is not to mention all the other costs that are idling — people, offices, partners and so on. However, the fixed price is for fixed scope, not for fixed time, and only in IT do things slip. A lot.

All projects have essentially three variables, only two of which can be optimised simultaneously. It’s the holy trinity of project management. The three variables are Features (Scope), Price (Budget) and Time. Fix any two, and the third bears all the variability. It isn’t possible to fix all three unless a project has zero uncertainty.

In a fixed-price project, the assumption is that Scope and Price are fixed, with a go-live date that is fixed as well. We all know that Scope tends to have significant uncertainty in interpretation between the parties. The buyer will say this scope means X, the seller will say it has assumed Y (and Y is invariably less than X). Given that price is fixed, all these gaps in understanding have to be accommodated in time slippage. There’s just no way around it.

There is, of course, a minimum viable feature set — scope cannot be reduced forever. As argued earlier, however, fixed price contracts incentivise loading on rather than paring down features, leading to the outcomes we see.

What am I saying?

I would rather not do a fixed-price contract if left to myself. Usually, however, this is not a choice the CIO has, even if he wants. There is a substantial organizational momentum towards fixed price — all evidence to the contrary. Organizations and most CIOs (including me many times in the past) genuinely believe it will be different this time. Agile, the hot-cake jargon of the times, explicitly advises against fixed-price and has much better outcomes but momentum is so powerful today that there are fixed-price “agile” projects. Does no one notice the contradiction — fixed but agile?

Is calling this a gambler’s strategy too extreme? What would you call a system with huge amounts of money at stake and statistically low chances of success?

Remedies

If you’re not going to throw Fixed Price out of the window, there are still a few things you can do differently to increase the chances of success.

Choose Partners First

Companies talk about partnership, but in the case of a fixed-price project, choose a price first and take whatever partner follows. This usually arises from an absence of trust — the buyer is worried that as the project progresses the supplier will keep asking for more money — “please tell me up-front how much it will cost and I will not pay a penny above it”. On the other hand, with a trusted partner, you can give a budget and ask to start work based on a quick estimate — trusting that he will not overcharge or repeatedly add tail-end requirements.

My recommendation is, even when fixing a price remove the trust lottery by first choosing a partner. Most IT services firms are equally capable of delivering most projects if given adequate time to ramp up so this evaluation should be based on organizational fit, willingness to engage and overall capability, rather than a bid for a login screen.

Mind you, a long-term partnership is no panacea, because the risks of estimation, pricing and delivery still exist. However, it does lower the optimism risk and contrary to popular belief gets better price discovery — through cooperation and transparency rather than competitive bidding (where generous buffers are a necessity). Resource risk is lowered because, in a stable partnership, the supplier is often able to anticipate the buyer’s needs and plan ahead. This kind of sourcing with a small number of pre-qualified suppliers is not unusual, and does not violate procurement best practices; indeed it is usually the recommended approach. If cut-throat bidding was the best way to get a good result, so much government procurement would not be sub-optimal.

Do IT services companies really give any benefit to partnerships? You bet they do. Accenture and TCS and the like reserve their best for their deepest relationships, rarely for one-off projects. IT services firms get most of their revenue through repeat business from their best buyers, so they butter their bread accordingly.

Pare Requirements Ruthlessly

This is the real key to success in the fixed-price world. In software, all requirements have a certain degree of uncertainty so the more requirements (and the more complex the requirement) the greater the chance that things will go wrong. Remember, it is in the buyers’ interest to get things right because the bulk of the risk and expected losses are borne by them — IT companies rarely lose money on any project. Core showstopper requirements have the most value, but most peripheral requirements don’t — it will help to take a very close look at everything to make sure everything meets the showstopper requirement filter. In my experience, the flab percentage is often very high. In most projects only 20% of the list are showstoppers, the rest are ready for the pruning shears.

Paring requirements is not easy. People often believe they can’t live without things even when they really can. Good projects are usually led by people who are ruthlessly good at simplifying the laundry list down to the bare essentials, where the reward indeed justifies the cost and headache that is sure to follow. I’m always particularly careful of people trying to scare me into a feature. Compliance, security, legal — these justifications are red flags, not because they’re unimportant but because people frequently overdo these areas under fear. See how much discussion goes into the login screen on every project — even when people have been building perfectly secure and functional login screens for decades.

Move Fast and Don’t Break Things

Fixed-price projects are, emphatically, not about innovation. They work best when everyone already knows what they’re doing and does it quickly and without unknowns. The less there is to experiment, discover, or innovate, the better the chances that things will finish on time and nothing will break. Innovation can come later, as incremental cycles after the basic project is up and running — don’t stand out in the rain while the world’s smartest home takes too long. Experimentation is not just in technology, avoid also those requirements that are not well understood and well established. Most businesses are not startups; there is no value in “hatke” versions of standard processes.

On the other side, the shorter the project, the better the chance that external changes will not throw spanners into the works. Unlike (say) a road from A to B, software projects live in a very dynamic world. If it takes years a lot of the underlyings may change in the meanwhile. I’ve seen projects implemented on hardware that went obsolete years before the project finished. Budgets and spends will not change whether you do one large mega project or a series of small ones. On another note, make sure your procurement processes don’t force you into big projects.

Summing Up

My first recommendation would be to ditch fixed prices entirely and go for a proper agile project with iterative requirements. If unavoidable, however, do focused, rapid, pared-down projects with a trusted partner rather than a giant project with competitive bidding. Worst case, take a big brand IT services company and give out a contract so complex that everyone can be blamed and no one will lose his or her job.

Originally published at http://braveforfree.in on July 4, 2023.