There are no hacks. Making estimates is difficult, the more information you can add into your equation as early as possible the better prediction you will get.
Let's go with "making estimates is _impossible_", at least in the vast majority of cases.
Hacks for Engineering Estimates
21–30 of 41 posts
Re: Hacks for Engineering Estimates
#22It's shocking when so much time is wasted on daily and weekly meetings and the project is still a year late or fails.
Re: Hacks for Engineering Estimates
#23I think the biggest thing holding engineering estimates back is that the people asking for them are actually not interested in accurate estimates; instead they are looking for inputs to be used in various games of corporate politics.
This is precisely the issue from my perspective as well.
Most project managers I've worked with either have a desired estimate already in mind or they don't care about any of the extenuating circumstances.
On one hand, the desired estimate is often based on the knowledge that projects estimated to take more than a quarter aren't going to get a green light.
On the other hand, it's ridiculous how many projects blow through estimates when external dependencies are ignored, newly-hired engineers create a burden on the project, and de-scoped work turns out to be necessary.
Those project managers also pursue the same estimation agenda even after several projects turn out the same way.
Re: Hacks for Engineering Estimates
#24When I make an estimate, I just double what I think it is and this is usual pretty accurate. I keep underestimating, sometimes doubling down I wonder myself, will it really take this long? 99% of the time, in the end, the answer was yes. So this is my goto method. People still think I finish stuff quick, even if I think myself it's too long.
My favorite estimation hack / joke is similar: take your best estimate, double it, and move up to the next higher time units. So "oh, an hour or so" becomes 2 days. A week turns into two months. I don't usually express those estimates, but it gives a good check on an initial, usually optimistic guess.
This is exactly my hack too! Especially when there are outside dependencies that can easily stall your progress.
Re: Hacks for Engineering Estimates
#25The best estimation tactic I've found in practice is ROPE, which works because it helps different kinds of stakeholders understand different kinds of estimates and ranges. R = Realistic estimate. Based on work being typical, reasonable, plausible, and usual. O = Optimistic estimate. Based on work turning out to be notably easy, or fast, or lucky. P = Pessimistic estimate. Based on work turning out to be notably hard,…
I usually give a range of estimation.
The issue I've had is that most "stakeholders" just want it boiled down to one number and don't care about any nuance. If I say it will take 2-4 weeks, they will assume 2 weeks if it's convenient. If there's a list of tasks, they will add up the lower bound of each task and discard anything they don't deem necessary.
It seems to me that any estimation tactic works well if you assume fair intent.
Re: Hacks for Engineering Estimates
#26It's shocking when so much time is wasted on daily and weekly meetings and the project is still a year late or fails.
That's shocking?
It seems incredibly ironic that one would be shocked by this.
Re: Hacks for Engineering Estimates
#27One estimation trick that I've found effective is the following:
(1) determine the smallest number that your sure is larger than the true answer.
(2) determine the largest number that you are sure is smaller than the true answer.
(3) take the geometric average of the two. (i.e., sqrt(a * b))
The reason this does well, is that oftentimes, (1) overestimates the true answer by roughly the same multiplicative factor as (2) underestimates the true answer by. So the geometric mean cancels the over and under estimates in order to get an estimation that does pretty well.
I find that this works remarkably well for estimating the dimensions of buildings, trees, etc.
Re: Hacks for Engineering Estimates
#28One estimation trick that I've found effective is the following: (1) determine the smallest number that your sure is larger than the true answer. (2) determine the largest number that you are sure is smaller than the true answer. (3) take the geometric average of the two. (i.e., sqrt(a * b)) The reason this does well, is that oftentimes, (1) overestimates the true answer by roughly the same multiplicative factor as (…
[deleted]
Re: Hacks for Engineering Estimates
#29One estimation trick that I've found effective is the following: (1) determine the smallest number that your sure is larger than the true answer. (2) determine the largest number that you are sure is smaller than the true answer. (3) take the geometric average of the two. (i.e., sqrt(a * b)) The reason this does well, is that oftentimes, (1) overestimates the true answer by roughly the same multiplicative factor as (…
Thank you. I love this.
Re: Hacks for Engineering Estimates
#30I think the biggest thing holding engineering estimates back is that the people asking for them are actually not interested in accurate estimates; instead they are looking for inputs to be used in various games of corporate politics.
This is precisely the issue from my perspective as well. Most project managers I've worked with either have a desired estimate already in mind or they don't care about any of the extenuating circumstances. On one hand, the desired estimate is often based on the knowledge that projects estimated to take more than a quarter aren't going to get a green light. On the other hand, it's ridiculous how many projects blow thr…
> Those project managers also pursue the same estimation agenda even after several projects turn out the same way.
This is an aspect of the https://en.wikipedia.org/wiki/Planning_fallacy.