My boss does this for "estimating" software project schedules. He built a goddamned spreadsheet* where he will rate the entire project on a scale of 1 to 5, with 1 being trivial/quick-win territory, and 5 being extremely labor-intensive.
Two problems with this approach as used at my job:
He assigns the ratings before requirements gathering has even started (if they ever get documented in the first place).
He bases the final deadline around the calculator spreadsheet, and sends that date on to the business partners/project stakeholders within the company, and they usually pass it along to upper management.
So, by the time we finally get requirements together and find out, oh, shit, this is actually way more complicated than a 2.71828 or whatever, the stakeholders have already told the Senior VPs of Thought Leadering that my team will be done by a specific date. The week before that date rolls around, boss goes into a panic, demands that I work on absolutely nothing else as I'm being pinged daily to put out random bullshit fires on other projects that were rushed through implementation before I even worked here. Between that and the low pay, I start really strongly considering pulling a no-show. I stay up late a couple of nights, project gets finished. Rinse. Repeat.
I envy the dead.
*: No, it's not a Monte Carlo simulation or anything that fancy -- he just multiplies the complexity rating by a set number of labor hours, and doesn't bake in additional time for risk mitigation. They promoted his ass because this is so scientific and data-driven. Edit: and no, there isn't a more detailed breakdown/implementation milestone schedule somewhere further down in the estimate. It's literally "I feel like this is a... 2. You have a week. GIT 'ER DUN!"
My boss gives me the opposite. He asked me to give a work estimate on a year-long project, he added +25% buffer for unknowns and submitted it. When the work ended, we were so efficient that we only used 70% of the estimated budget, and this was a problem! Buddy, that's why they're called estimates, we can't make perfect guesses before requirements are gathered.
Nope because in this case our client has to request a budget and justify it, so in this case they asked for too much and have to explain what went wrong
Of course, the key is to enumerate all tasks, assign complexity to individual tasks, consider likely blockers, and multiply times by an uncertainty factor.
My boss does this for "estimating" software project schedules. He built a goddamned spreadsheet* where he will rate the entire project on a scale of 1 to 5, with 1 being trivial/quick-win territory, and 5 being extremely labor-intensive.
Two problems with this approach as used at my job:
So, by the time we finally get requirements together and find out, oh, shit, this is actually way more complicated than a 2.71828 or whatever, the stakeholders have already told the Senior VPs of Thought Leadering that my team will be done by a specific date. The week before that date rolls around, boss goes into a panic, demands that I work on absolutely nothing else as I'm being pinged daily to put out random bullshit fires on other projects that were rushed through implementation before I even worked here. Between that and the low pay, I start really strongly considering pulling a no-show. I stay up late a couple of nights, project gets finished. Rinse. Repeat.
I envy the dead.
*: No, it's not a Monte Carlo simulation or anything that fancy -- he just multiplies the complexity rating by a set number of labor hours, and doesn't bake in additional time for risk mitigation. They promoted his ass because this is so scientific and data-driven. Edit: and no, there isn't a more detailed breakdown/implementation milestone schedule somewhere further down in the estimate. It's literally "I feel like this is a... 2. You have a week. GIT 'ER DUN!"
My boss gives me the opposite. He asked me to give a work estimate on a year-long project, he added +25% buffer for unknowns and submitted it. When the work ended, we were so efficient that we only used 70% of the estimated budget, and this was a problem! Buddy, that's why they're called estimates, we can't make perfect guesses before requirements are gathered.
This is basically how we got the agile manifesto
My work is so behind the times that this would literally explode their collective brains
Isn't being under-budget usually considered a positive?
Nope because in this case our client has to request a budget and justify it, so in this case they asked for too much and have to explain what went wrong
What you describe sounds absolutely terrible, but there is a way to do something like this well:
https://jacobian.org/2024/mar/11/breaking-down-tasks/
Of course, the key is to enumerate all tasks, assign complexity to individual tasks, consider likely blockers, and multiply times by an uncertainty factor.