When avoiding the Sunk Cost Fallacy can be a mistake

One of the concepts that I learned about when getting my MBA was the Sunk Cost Fallacy. For those of you who may be unfamiliar with the term, here is a definition from Wikipedia:

In economics and business decision-making, a sunk cost is a retrospective (past) cost that has already been incurred and cannot be recovered

In other words, when you are determining whether to continue with a project, you should not consider the costs incurred to date. For example, let's say that you need a new CRM system for your company. You've evaluated the existing systems and decided that none of the existing systems meet your needs and that you need to need to build your own. $30,000 into the project, and an estimated $30,000 to go, you decide that a $20,000 system would be adequate. The normal human reaction would be to say that "we've already put so much effort into the project, we can't stop now". The fallacy here is that the original $30,000 is lost. There are no circumstances in which you can get that back. If you are to avoid the Sunk Cost Fallacy, you should decide if you want to spend $30,000 to finish the custom system or $20,000 to purchase the new one. Period.

The problem with that statement is that people's feelings do matter. When you're purchasing or building new software, people track the costs for gathering requirements, making customizations, training, etc. But people almost always forget that the hardest parts for delivering software can be around usage:

• How do I make sure that people use the system?
• How do I make sure that people use the system correctly?

When considering whether to abandon the CRM project, one must also gauge the reaction that the team will have when abandoning the project. Sometimes, stopping the project will bring a sense of relief to the team and the savings by purchasing the system will be even greater than what is obvious at first. Other times, the team will feel betrayed that their project is being abandoned and will subconsciously undermine efforts to implement the new system. (This can be especially true if there were nice-to-have features in the old system that people were excited about that were absent in the new one.) In these cases, continuing with the original plan is actually the correct decision, regardless of the savings on paper.

To be clear, I'm not arguing that the Sunk Cost Fallacy is an idea that should be ignored. Clearly that is not the case. We need to be careful about making business decisions based on our personal investment into a project. But we must also remember that excitement and buy-in are important too, and if you kill these by trying to save costs you will never realize the intended savings.