4 ms·

The reason no one does this is because thr answer is constant "something might fail and add an arbitrary delay" once you hace committed to play the estimation

The reason no one does this is because thr answer is constant "something might fail and add an arbitrary delay" once you hace committed to play the estimation game, you're committed to the delusion and reality checks dont matter. Just stop trying to estimate.

13of40 5y ago
Or acknowledge that the "E" in "ETA" stands for "estimated", not "promised".
corobo 5y ago
"just" is thrown around far too much on this site I'm sure my boss and customers will appreciate me saying "it takes as long as it takes", nothing will go wrong, it's clearly just that simple :) Why not instead of working at all just earn a million a year off the interest from a well performing stock portfolio instead?
abecedarius 5y ago
It's not only that. There seems to be a 'political' advantage to overconfidence even given the effect it ought to have on your track record. (This is not advice.)
- EsotericAlgo 5y ago
  Yes, and this surprises me each time it happens. As a for instance, I was the operations lead a couple years ago for a large, customer-facing financial product rollout. The timeline was insanely aggressive, approximately 10 months ahead of my prediction and predicated upon several payment and banking vendors nailing their legacy integrations out of the gate with no delay (perhaps a first in the history of the world). Several of these vendors weren't committed nor was a spec agreed upon prior to the timeline. When raising these concerns everyone acknowledged them, but mitigations or deadlines revisions we not made as it would countermand previously set expectations with the executive team. The project continued on for another 18 months past the deadline with a "launch" set every three months. Inevitably something would derail it a week beforehand that was unexpected but known months in advance by the project team (e.g. the mainframe the payment vendor uses has a fixed column length. It will take two months to build around this to support xyz). In the end it got rolled out. Everyone forgot about the delays and the project team was praised as the implementation did better than expected. The same technique is employed once again. While I don't like it, I now see the estimates and re-estimates as a method for an executive team to manage a project portfolio and prioritization. It's not a good way to do it but it's easy to express priority by simply ranking deadlines. It's much easier to avoid this in high-trust environments (typically smaller organizations).

13of40 5y ago

Or acknowledge that the "E" in "ETA" stands for "estimated", not "promised".

corobo 5y ago

"just" is thrown around far too much on this site I'm sure my boss and customers will appreciate me saying "it takes as long as it takes", nothing will go wrong, it's clearly just that simple :) Why not instead of working at all just earn a million a year off the interest from a well performing stock portfolio instead?

abecedarius 5y ago

It's not only that. There seems to be a 'political' advantage to overconfidence even given the effect it ought to have on your track record. (This is not advice.)

EsotericAlgo 5y ago
Yes, and this surprises me each time it happens. As a for instance, I was the operations lead a couple years ago for a large, customer-facing financial product rollout. The timeline was insanely aggressive, approximately 10 months ahead of my prediction and predicated upon several payment and banking vendors nailing their legacy integrations out of the gate with no delay (perhaps a first in the history of the world). Several of these vendors weren't committed nor was a spec agreed upon prior to the timeline. When raising these concerns everyone acknowledged them, but mitigations or deadlines revisions we not made as it would countermand previously set expectations with the executive team. The project continued on for another 18 months past the deadline with a "launch" set every three months. Inevitably something would derail it a week beforehand that was unexpected but known months in advance by the project team (e.g. the mainframe the payment vendor uses has a fixed column length. It will take two months to build around this to support xyz). In the end it got rolled out. Everyone forgot about the delays and the project team was praised as the implementation did better than expected. The same technique is employed once again. While I don't like it, I now see the estimates and re-estimates as a method for an executive team to manage a project portfolio and prioritization. It's not a good way to do it but it's easy to express priority by simply ranking deadlines. It's much easier to avoid this in high-trust environments (typically smaller organizations).