Too Big To Fail

The project is huge. It's been running for years. It's late. It's getting later every day. No-one can remember why the project started in the first place. No one is sure why we are still pushing ahead, but the project refuses to die. Money is thrown at it. The project team becomes larger and larger. It becomes harder and harder to get any other projects funded because MegaProject is sucking up all the available money and people. The project has become Too Big To Fail.

We've all seen something like this at one point or another (preferably from a long way away) - a huge project, lumbering on year after year, never delivering anything but consuming every part of the organisation it touches. Everything is diverted into making sure this project doesn't fail. Those on the outside (and many on the inside) wonder why the decision isn't made to kill it off. The original business case has long since evaporated. The project will never deliver the benefits it was supposed to. Why doesn't management pull the pin? The answer is simple - the organisation has fallen prey to the sunk cost fallacy, also known as the gambler's fallacy.

The fallacy is pretty simple - "I've been gambling for a while and I'm down a bunch of money. If I stop now I'll lose the lot. I have to keep going to win some of it back and reduce my losses". Of course, as gambling is a tax on those who are bad at maths, the longer you gamble the more you lose. Add the gambler's fallacy and the more you lose, the more you feel you have to gamble to reduce your losses and so on. Many gamblers will start "doubling down" - betting more and more to try to win back losses. Protip - this never works.

It's the same in the corporate world. The company has spent a lot of money on MegaProject. If they kill it off they lose it all. If they keep going, they may make some of that money back. Companies will even double down and start pouring increased funding into these budgetary black holes in order to try to save at least some of the benefits. Protip - this also never works.

If pouring extra money into a budgetary black hole wasn't bad enough, these projects also have another cost - opportunity cost. As these projects get bigger, it becomes increasingly harder for other projects to get funding as all the available money is being funneled into MegaProject. By consuming funds, it prevents the organisation from doing other things with that money. Things that might have far greater benefits than the original project. So there is also the significant cost of lost opportunity to consider as well.

As MegaProject gets bigger and starts to impose larger opportunity costs on the organisation, MegaProject tends to get even bigger, as everyone who wants funding for something finds some tenuous connection to MegaProject and manages to get their pet project bolted on - it's the only pot of money around so we have to be part of it. So the project that was already big and late keeps getting bigger and later. Protip - this will not end well.

As an indication of just how bad it can get, an organisation I once worked for (who shall remain nameless) had a MegaProject that was supposed to take 5 years. 3 years in they realised that they were still 5 years away from delivery. 2 years later, the team had grown from 500 to 1500, the company was purchased by its joint venture partner to save it from insolvency, every other development department worldwide was shut down to focus all efforts on this project (this is where the organisation and I parted company) and the project was still 5 years away from delivery. Now, several years later, my spies tell me that the project is still running, bigger than ever and is, yes, you guessed it... 5 years away from delivery.

Fortunately, there is a solution. And it's a simple one. The trick is to ignore money previously spent. Anything you have already spent on a project is a sunk cost. You can't get it back. Look instead at how much will it cost you to finish, against what the return will be.

Let's look at an example. The project starts with a budget of $1m and an expected return of $2m. That's a 2:1 return, so not bad. After a year, we find that the project will cost twice as much, so we still have $1m to spend for a return of $2m. Is it worth continuing? If we look at the whole project spend, its $2m for a $2m return... 1:1. Not worth it. But unfortunately, our sunk cost bias gets in the way - we don't want to throw away that $1m so we almost never make the intelligent decision to kill the project.

So let's ignore that. Ignore the sunk costs. Write them off. Treat it as a completely new project with a budget of $1m and a return of $2m and work out whether we would do it. It's 2:1 so still maybe worth doing.

If we discover that the delay also cut the expected return to $1m, the case would be very marginal its back to 1:1. If there are any projects out there waiting for approval worth a better than 1:1 return, we would be much better off switching our focus to them. If there aren't any projects out there with a better than 1:1 return, then we have some much deeper issues with our business model to work through as well.

Take the bias out of business decisions. Sunk costs are sunk. You can't get them back. Each time you assess a project, ignore the previous spend and look at whether you would approve a new project with the expected costs and returns you would get if you finished this one.

If you want a more in depth discussion of why this is a good idea, the best place to look is in Don Reinertsen's Principles of Product Development Flow.