Less Wrong is a community blog devoted to refining the art of human rationality. Please visit our About page for more information.

taryneast comments on Bias in capital project decision making - Less Wrong

40 Post author: jsalvatier 26 May 2011 06:06PM

You are viewing a comment permalink. View the original post to see all comments and the full post content.

Comments (23)

You are viewing a single comment's thread. Show more comments above.

Comment author: taryneast 28 May 2011 09:00:01AM *  1 point [-]

Yes, that's true. and we should make sure that a client thinks deeply about all the cases that would reasonably come up.

...but I often find that there are situations that come up that really could not have been predicted in advance.

A small example for an e-commerce site might be the effect that adding multiple currencies has on dealing with "$X off" promotions if all you do is scale from a single currency you end up with $5 off or £3.24 off... which is ugly... and unfortunately required us to rework promotions to allow us to add "currency value overrides" for this kind of promotion.

It was unexpected, we didn't know about it in advance( either us or our clients) but it was obvious-in-hindsight that it would be unacceptable to the client/customers.

Comment author: SilasBarta 31 May 2011 05:40:54PM *  0 points [-]

I agree with you in that respect. If neither managers nor engineers are aware of special conditions that attach in part of the designspace until it catastrophically happens, then that is a black swan, and a reason to temper judgment with a higher discount rate.

I was only adding that if engineers come back with a solution that, given what they were told, is optimal, when the managers knew all along about special conditions make the proposed solution unfeasilbe, it's not a black swan, nor really fair to say, "silly engineers -- not accounting for the real world!" (It's at that point that you should re-iterate, adding that constraint to the spec this time and you certainly shouldn't go forward with it.) And that, if this is the problem, it's not the kind of thing that requires a higher discount rate or margin of safety, just better problem specification.

Comment author: taryneast 31 May 2011 09:48:12PM 0 points [-]

Definitely agree with you on that one. I'd guess it more a problem of scope-creep. You can also solve that by discounting, but it's much better to solve by enforcing different accounting for change-requests. I've found that if you keep time spent on scope-creep as a separate bottom-line, it draws more attention to the problem (which makes it more likely to get solved).