The "when to throw out an estimate" is something I've evolved on a lot in my career. Initially, naive happy path. After that, happy path + some overly-large fuzzy padding number.
Now, I push back on PMs who ask for an estimate at an unknowable point in the project.
The problem is not estimating work. The problem is estimating work volume risk (the range of work the project might take). And the only thing that can decrease that is prototyping and similar.
I work in somewhat of a sub-niche (automation), so have a larger than average number of black-box, outside-of-my-control, unchangeable components. But I've come around to believing modified spiral [0] is a better approach when risk dominates.
Sometimes, the right answer to "How long will this take?" is "It will take this long to get an answer to that question."
Sometimes, the right answer to "How long will this take?" is "It will take this long to get an answer to that question."
Yep, or sometimes "no idea, let me work on it for a day and get back to you". You can't expect an estimate for something with many unknowns to be very accurate so best to reduce the unknowns first.
Real world projects have too many factors out of your control as well (e.g. decision making and schedules of stakeholders, combinations of software/people/requirements you've never worked with before, evolving requirements) so this idea that you can guess the total number of hours with high accuracy as you get more experienced doesn't make a lot of sense to me.
Fixed price projects are also a way of saying "we genuinely don't know how long it's going to take, but we'll take on that risk instead of you".
Comments
The "when to throw out an estimate" is something I've evolved on a lot in my career. Initially, naive happy path. After that, happy path + some overly-large fuzzy padding number.
Now, I push back on PMs who ask for an estimate at an unknowable point in the project.
The problem is not estimating work. The problem is estimating work volume risk (the range of work the project might take). And the only thing that can decrease that is prototyping and similar.
I work in somewhat of a sub-niche (automation), so have a larger than average number of black-box, outside-of-my-control, unchangeable components. But I've come around to believing modified spiral [0] is a better approach when risk dominates.
Sometimes, the right answer to "How long will this take?" is "It will take this long to get an answer to that question."
[0] https://en.m.wikipedia.org/wiki/Spiral_model
Yep, or sometimes "no idea, let me work on it for a day and get back to you". You can't expect an estimate for something with many unknowns to be very accurate so best to reduce the unknowns first.
Real world projects have too many factors out of your control as well (e.g. decision making and schedules of stakeholders, combinations of software/people/requirements you've never worked with before, evolving requirements) so this idea that you can guess the total number of hours with high accuracy as you get more experienced doesn't make a lot of sense to me.
Fixed price projects are also a way of saying "we genuinely don't know how long it's going to take, but we'll take on that risk instead of you".