After more than a decade of experience, I'm still bad at estimating. This post matches my best understanding of how they should be done though. The goal is small chunks, each of which is well-understood enough to give someone instructions on without them having to improvise.
Another thing is to let the stakeholders know as soon as possible if part of the schedule is slipping.
One problem I've had though, is that sometimes the tasks I've broken something down into turn out to not be the right direction to slice things. So I've got tasks A, B, and C, but a week later I've got half of A, 75% of B, and a quarter of C done.
I consider myself as an enthusiast in learning new things everyday, about our history and future as well as the present. My interests: Ancient History, Comparative Religion, Science and Tech, C++
It is nearly impossible to get everything right in the initial stages of a project and the situation that you mention is not unusual. However this is the reason we now have iterative software development process (agile) in place with small sprints. With shorter sprints, with time as you get more aware of the requirements of the project your estimations get better.
I like the idea of agile, but when done in a formalized way it seems to do more harm than good. I've done scrum in a few places, but never enjoyed it or found it to be very helpful. It seems to be designed to keep people from getting a chance to catch their breath or get into their work. I suppose there may be some types of project where it works well, or some people who are good at it.
Basecamp has recently posted some videos about their process with six week iterations, which looks interesting.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
After more than a decade of experience, I'm still bad at estimating. This post matches my best understanding of how they should be done though. The goal is small chunks, each of which is well-understood enough to give someone instructions on without them having to improvise.
Another thing is to let the stakeholders know as soon as possible if part of the schedule is slipping.
One problem I've had though, is that sometimes the tasks I've broken something down into turn out to not be the right direction to slice things. So I've got tasks A, B, and C, but a week later I've got half of A, 75% of B, and a quarter of C done.
It is nearly impossible to get everything right in the initial stages of a project and the situation that you mention is not unusual. However this is the reason we now have iterative software development process (agile) in place with small sprints. With shorter sprints, with time as you get more aware of the requirements of the project your estimations get better.
I like the idea of agile, but when done in a formalized way it seems to do more harm than good. I've done scrum in a few places, but never enjoyed it or found it to be very helpful. It seems to be designed to keep people from getting a chance to catch their breath or get into their work. I suppose there may be some types of project where it works well, or some people who are good at it.
Basecamp has recently posted some videos about their process with six week iterations, which looks interesting.