Tuesday, May 29, 2007

Sunk Cost - Fallacy and Dilemma

First of all, I think it's pretty funny that the first substantial post here is me, talking about project management stuff, but it's true.

On to the good stuff:



Sunk Costs
The definition of a sunk cost is simple, but with some subtle points.
Sunk costs are the unrecoverable past costs of an endeavor.

Examples:
Buy a sandwich and eat it. Sunk cost: sandwich price + time spent.

Buy a book, read it. Sunk cost: Difference between the retail price and the resale price, plus the time spent.

Now that that is out of the way, we can talk about why they matter.



Sunk Cost Fallacy
This is the formalization of the old adage about not 'throwing good money after bad'.

Basically, people have an irrational tendency to count sunk costs when they make a decision. This is pretty obvious to see in the tendency to never quit on a failing project, even if it's the overwhelmingly right thing to do.

As wikipedia says, you don't see many half finished bridges.



Sunk Cost Dilemma
Here's the really interesting part: due to sunk costs, always doing the right thing (in a naive setting) can result in failure.

Say you estimate a time and date for a project, sign the contract, and start work with the expectation of plenty of time and resources.

Midway through, your star takes sick. You have to decide whether to keep going or pay someone else to finish it. You figure there's still time, so you keep going.

Now, what's the right choice if you run into another problem? If you look at it naively again, odds are good you'll keep going in hope of that payout, even if you'll lose a little money.

The right answer to this problem is twofold: First, you assess the likelihood of the outcomes, and secondly, you take into account possible future costs of each outcome.




Anyway, to relate this back to the realm of technical things, this is one of the foundation principles of Agile/Lean methods: the more risk and the more competitive the market, the shorter your feedback cycles need to be.

I see this all the time, with feature creep and bloat. Once you build it, it's a sunk cost, whether or not it's at all useful to anyone.

In many cases, the rational answer to feature creep and bloat is to throw many things out or start over, but people hold on to the existing features because they think the money spent on them will be 'more wasted' if they are removed.

No comments: