When to walk away from software you've already paid for

Most nonprofit operators sit in some version of this meeting at least once. An organization has spent a long time, and real money, building a system that still isn't finished. Somewhere along the way the ground shifted, a second overlapping system appeared, and now people are trying to stitch the two together. It isn't working.

At some point someone has to say the part nobody wants to say. You've spent a lot of time and money getting here. If you keep going, the spending doesn't stop. It grows.

That conversation is hard, and it usually runs long. But the point is simple: stop bolting a new system onto an old plan. It's a textbook case of sunk cost.

What sunk cost actually is

The sunk cost fallacy is the pull most of us feel to keep going on something because of what we've already put in, even when finishing it costs more than it returns. The money and time are already gone no matter what you do next. The fallacy is letting the past decisions decide what you do next.

It comes in three forms: money you've already spent, time you've already put in, and effort your team has already burned. The effort one is the quietest and usually the strongest. People defend a bad system because of how hard they worked on it.

It is hard to tell your board you spent real money and the better part of a year and now you want to scrap the project. It is worse to keep spending just to avoid saying it.

What to do about it

1. Count the cost of finishing, not the cost so far.

   "We've put $15,000 into this" is the wrong perspective here. "This will cost another $8,000 and four more months" is the one that tells you whether to keep going. Only future costs are still yours to decide.

2. Separate the person from the decision.

   In many organizations the project has a face. The staff member who built the shadow system. The board member who pushed for the platform. Ending the project is not ending them, and they will assume otherwise unless you say so. A champion who feels personally attacked will keep a dead project alive for months.

3. Bring in someone from outside the decision.

   It is far easier to see the flaw in someone else's plan than your own. That is most of what I do in a meeting like the one above. You don't need a consultant for it. A peer at another organization with no stake in the outcome, or someone from another department, works fine.

4. Turn it into a lesson, not a loss.

   "We messed up" is where most of these end. The more useful version is naming what you would watch for next time, so the money buys you something. In the case above, the lesson was clear: don't let a parallel project run for months without deciding which one wins.
   

The call

In the case that opened this piece, the organization stopped the integration work. They kept the system that was doing its main job well and stopped forcing the two to become one. The time already spent was spent. What they got back was the headaches, expense, and time they'd have poured into a merger that was never going to hold.

*This story comes from a real organization, and the amounts and details have been changed.