Most people do not know how to adequately assess the timing of tasks. Oh, how it makes them sometimes nervous ... Here, and "deadline sneaks up unn...
For further actions, you may consider blocking this person and/or reporting abuse
Humans are bad at estimations. There are essentially two problems here:
a) Most humans have too few datapoints in mind to make a realistic prognosis
b) Most humans are biased, mostly seeing things too optimistic
There was an insightful episode on freakonomics radio: Here’s Why All Your Projects Are Always Late — and What to Do About It
In order to improve the situation, you have to decrease the "human factor".
Thank you for your comment!
Yes, you're right - humans are bad estimators. But firstly, the project/time should be estimated anyway and secondly, by collecting several opinions your estimate more likely will be in realistic range.
How so?
If you ask people how the weather will be tomorrow, the estimation doesn't get more accurate depending on the number of people you ask. But why do we believe that to be true for project management?
Perhaps ML will improve estimations rather than humans guessing.
It's simple. It called the wisdom of the crowd - individuals may be totally wrong but the whole crowd will be quite accurate. There are several methods of ML based on this paradigm as you mention ML here =) - bagging for example
If my manager wants an estimation from me, I think of how long I think it will take. The outcome gets multiplied bij pi (like you mentioned) and that estimation goes to my manager. In most of the cases, this turns out not to be that far off. But reality forces me to admit that there is also something like Parkinsons law so my multiplier of pi might be too high.
The very reason I have a multiplier is - I think - an indication that the whole principle is wrong. If I have to multiply with a factor, it shows that I cannot safely estimate. It has become guesstimating.
Enter the management triangle:
In short: there is time, budget and quality. Any of these can be controlled by the project owner, but you can only pick two; the third one follows from the two you pick. The agile movement uses just this. It fixates time and budget, so quality follows from that. With 'quality' you can also read 'features'. Imo, this leads to better projects. The focus in agile approaches is to always have working software, so you just iterate until the project owner thinks it is good enough.
In general, software is way too complex to fully estimate in advance, so your best bet might be to accept that and use it as a basis for your planning.
It's a good point, thank you for your comment!
A better discussion on the topic than many similarly titled posts that essentially go on to say "don't give estimates. They suck." which we all know is true, but in a business setting you are unlikely to be able to just say "I start and let you know when I've finished, it takes as long as it takes". Some kind of estimate is nearly always needed in reality.