Sunk Cost Fallacy

Sunk Cost Fallacy is a trap that most experienced IT Architects fall for. You need to be aware of Sunk Cost Fallacy and avoid doubling down on failed or legacy solutions.

Sunk Cost Fallacy

This situation is an IT classic. You introduce a Solution (Mostly a COTS product or a platform). Before the decision is made, as any good Architect, you performed in-depth analysis and due diligence. Midway through the implementation, it's evident that the product sucks, the adoption is very low/slow, and the outcomes didn't meet your expectations.  You tried everything to win stakeholder support, but the product comes with a significant product tax. You can't seem to find specialists who can configure the product, and you need to extensive customization than you initially thought. The product is missing some key features necessary to meet your goals - You could have missed these in the initial evaluation, or these could be new requirements.
You realize that you made a suboptimal decision; however, you decide to push forward because;

  • Your organization have a "can't fail" culture
  • Sunk Capital
  • Sunk Human Efforts
  • Unsure if starting over is better

This situation, my fellow architects, is known as Sunk Cost Fallacy.

The Sunk Cost Fallacy describes our tendency to follow through on an endeavor if we have already invested time, effort or money into it, whether or not the current costs outweigh the benefits.

-DecisionLab


If you come across this situation, you need to pause and think critically about the solution, its current state, and other alternatives. Doubling down on failed solutions is not the same as stopping and rethinking decisions constantly and ending in the plateau of indecisiveness. There will be solutions that will be difficult to implement, no matter how superior your decision or approach is. Sunk Cost Fallacy is ignoring the clear evidence and facts that point to a wrong decision.

Another version of Sunk Cost Fallacy is not necessarily a new product or a solution. Instead, a product that has already been in the enterprise but is obsolete. Your team continues to build features on the legacy solution. This cloud be because it is easy, or the legacy vendor upsold a product feature at a price cheaper than competing software in the market, but either way, it is a story with a sad ending.

Next time you double down on a solution- ask yourself if your decision was heavily influenced by the fact that the platform/solution was already there. Ask yourself if the cost benefits of using a different platform or product outweigh doubling down on the legacy stack.