The iPhone app example in the presentation confuses me.
The way it is presented, it looks like the conclusion is that you should always be willing to spend an additional $6999.99 no matter how much you have already spent. If current you is willing to spend the extra money regardless of whether you have already spent $4000 or $10999.99, then I don’t see why future you would feel any different.
I would think that you should take in to account the fact that your original estimate of the cost was too low. Given that this is the case, you should expect that your current estimate of the cost to finish is also too low. I would multiply your cost to finish estimate by (current estimated total cost) / (original estimate) and only continue if that result is less than $7000.
Going over this in the presentation would introduce complications to the problem that would most likely lead to even more confusion, but when the details are left out, it looks like you are endorsing the same decisions that the sunk cost fallacy would lead to. I suggest changing the example to something else entirely.
The example is bad in that it compares income forecasting with expenses. In reality you would have an expected distribution of revenue, some probabilities etc. You can fix the example by imagining it as contract work where you get paid the mentioned $7000 on delivery, with no penalty for non-delivery.
The problem you see is the point of the sunken cost fallacy. Current »you« should ignore the money already sunk, and just look at the options presented. Therefore sinking more money into the project to complete it is worthwhile as long as the money sunk is less than your payout.
If in the future you are even only 1$ away from finishing the app it does not matter how much you put into it already. The money is gone, sunken. You get to invest the 1$ and reap the benefit or not.
I agree that if the numbers given in the example were trustworthy, then it would be a good example. The part that confused me was that there would be no incentive to start the project unless the original estimate of the cost was significantly less than $7000. It seems reasonable to expect that the next $4000 you spend will have a similar effect on your expected cost to finish. If you perpetually think “Just another $5000 and I will be done”, then you are no better off than if you think “I already spent so much, I can’t just quit now.”
The more money that is sunk into it, the stronger the evidence that you are bad at estimating the cost. I assume that this evidence is implied to be included in the new cost estimate, but I think a general audience would not immediately notice this.
I think you broke the example. The point as I see it that the surrounding conditions can change. Availability of coders, legal situation. Needed items from external sources etc.
It should be made more clear.
The iPhone app example in the presentation confuses me.
The way it is presented, it looks like the conclusion is that you should always be willing to spend an additional $6999.99 no matter how much you have already spent. If current you is willing to spend the extra money regardless of whether you have already spent $4000 or $10999.99, then I don’t see why future you would feel any different.
I would think that you should take in to account the fact that your original estimate of the cost was too low. Given that this is the case, you should expect that your current estimate of the cost to finish is also too low. I would multiply your cost to finish estimate by (current estimated total cost) / (original estimate) and only continue if that result is less than $7000.
Going over this in the presentation would introduce complications to the problem that would most likely lead to even more confusion, but when the details are left out, it looks like you are endorsing the same decisions that the sunk cost fallacy would lead to. I suggest changing the example to something else entirely.
This has changed my mind. Including examples that require slightly different thought patterns seems to be a good idea.
The example is bad in that it compares income forecasting with expenses. In reality you would have an expected distribution of revenue, some probabilities etc. You can fix the example by imagining it as contract work where you get paid the mentioned $7000 on delivery, with no penalty for non-delivery. The problem you see is the point of the sunken cost fallacy. Current »you« should ignore the money already sunk, and just look at the options presented. Therefore sinking more money into the project to complete it is worthwhile as long as the money sunk is less than your payout. If in the future you are even only 1$ away from finishing the app it does not matter how much you put into it already. The money is gone, sunken. You get to invest the 1$ and reap the benefit or not.
I agree that if the numbers given in the example were trustworthy, then it would be a good example. The part that confused me was that there would be no incentive to start the project unless the original estimate of the cost was significantly less than $7000. It seems reasonable to expect that the next $4000 you spend will have a similar effect on your expected cost to finish. If you perpetually think “Just another $5000 and I will be done”, then you are no better off than if you think “I already spent so much, I can’t just quit now.”
The more money that is sunk into it, the stronger the evidence that you are bad at estimating the cost. I assume that this evidence is implied to be included in the new cost estimate, but I think a general audience would not immediately notice this.
I think you broke the example. The point as I see it that the surrounding conditions can change. Availability of coders, legal situation. Needed items from external sources etc. It should be made more clear.