What often baffles me with engineers and especially engineering managers is that they don't derive the estimates from metrics of prior projects, especially for long running teams (as opposed to project teams). You don't need to estimate down to the minute, but you already know how many tickets/work items the completes at a given time interval with how many people in the team etc. This should give a rough estimate of how long a project might take, and you can confidence intervals like 90% confidence we finish this in 3 months, 70% confidence we finish it in 10 weeks, 50% confidence in 6 weeks and 10% confidence we finish it in 2 weeks.
IMO this is also a better way to communicate with stakeholders outside the team instead of committing to a specific date. It gives more context and clearly communicates that this is a probability game after all since there are quite few moving variables.
> What often baffles me with engineers and especially engineering managers is that they don't derive the estimates from metrics of prior projects, especially for long running teams (as opposed to project teams).
The PMI project management methodology even pre-scribes this (after the project is over, to reflect, and then to gather collected learnings and objective stats so as to help better estimation of future projects), but the problem is many engineers see project management a administrative burden rather than as a tool, and they have a tinkerer's mind-set rather than a scientist's mind-set.
Good project management practice is also not to use
point estimates but intervals: something is going to take "betweek [i;j] person days". PERT-estimates are even three-point estimates of work (best case, expected case, worst case), so you model the uncertainty explicitly rather than by some alchemist formula ("double and add 20%").
Incidentally, I found out empirically that the best technical people tend to be the worst at estimating their own time needed to complete a task. That's because the best are often also a bit over-confident, perhaps. Letting each team member estimate a task and adding a 20% correction for unforseen issues has worked well to make my projects be delivered on time.
Tip: Push back if management tells you how long you have; either explain to them what you can give to them in the time they dictate or reject their task order and say you will come back when you have calculated how long the project takes, which can only be rationally determined once the scope is clear(er).
Check out/google: PMI PMP methodology and also PMBOK (project management body of knowledge) > "Organizational Process Assets" (OPAs) > "Lessons Learned Repository"
You record the amount of time it takes people to do a crossword puzzle or play a game of chess. After a while you'll be able to make a distribution graph of how long it takes. Then you can give an accurate estimate along with a probability.
I think it comes down to the difference between predictions and prescriptions. When a person is predicting how long someone else's work will take, the revelation of their error causes them to change their subsequent predictions to be more accurate. When a person is prescribing how long someone else's work will take, the revelation of their error causes them to demand productivity increases.
IMO this is also a better way to communicate with stakeholders outside the team instead of committing to a specific date. It gives more context and clearly communicates that this is a probability game after all since there are quite few moving variables.