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.
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).
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.
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).