Teach this to your manager: At the beginning of a task, uncertainty is highest. Under no circumstances should you give an estimate in ‘man-hours’. Even days is too precise. The first estimate should be in months or years (of course depending on the size of the project). Then, as your insight into the project grows, you refine that to months, then weeks, later days. A vague estimate with a lower and a higher bound is way more useful to your manager than a ridiculously ‘precise’ but highly speculative number.
This lesson was brought to you by either “Code Complete 2” or “Rapid Development” by Steve McConnel, and by my former manager who wanted projects estimated in minutes.
Just use unix milliseconds
Point the ticket using the value of a cryptocurrency.
my former manager who wanted projects estimated in minutes.
That wasn’t a manager, that was a demon.
my former manager who wanted projects estimated in minutes.
Sorry, the number buffer overflowed.
Sir, I estimate the project will be completed in 135 days and 11 hours.
Not if your manager then takes the minimum of your estimate.
I don’t work for a while anymore.
Your minimum estimate should be your actual estimate times three.
Don’t forget to add padding, so I’d just round it out to 18 months to be safe.
A good project manager doubles your number an adds 20% anyway.
Triples it if you are working more than one project.!
A good project manager
A what now?
HA
A typical project manager will get a range, take the lower bound and communicate it as the only relevant number to every other stakeholder. When that inevitably does not work out, all the blame will be passed on to you unfiltered.
Depending on where you work it may or may not be worth giving someone new the benefit of the doubt, but in general it is safer to only ever talk about the upper bound and add some padding.
I hear this criticism all the time, but I’ve never seen it happen in 5 companies I’ve worked for so far. Usually there’s an understanding that estimates are wild guessing, and things are planned using dependencies rather than timeliness.
Only novice PMs do that and believe it or not, the project manager carries the can for failure .
My teams new hire project manager was even more advanced. When they found out we were working on 5-10 projects at once with no PM, they quit.
We had 3 PMs when I started here, and have been down to 0-1 for 6 months. That 0-1 runs a whole unrelated team, but is technical still a PM.
Dysfunction is fun. The plus side? No one asks me for estimates.
this is my number one thing I hate. So we are going to be converting over one system to another and you have no ideas what issues will pop up. give an estimation on the project. or like estimation onf fixing a bug or doing something you think the software can do but your not real sure till you look into it.
Hofstadter’s Law: It always takes longer than you think, even when you take into account Hofstadter’s Law.
My boss asking, me: “2 days to a week”.
Meaning: 2 days best case scenario, but there’s likely something where i’m stuck for days trying to solve it, so a week.
My boss: “ok, two days then.”
The Good Place mentioned!!! 🗣️🔥🔥
That’s because all tasks finish in the dot of the “i” of the Jeremy Bearimy sprint, I dunno what to tell you…
