I work at an agency using ASP.NET, so I find myself regularly estimating for projects and small jobs. The biggest issue with our clients is that they will always argue how long things will take. One of our large clients has a SEO guy in one of their offices that has "11 years web experience" (despite not programming professionally for the best part of three years, and seemingly knowing very little about programming or how the Internet works) and he will frequently argue every small cost. We quoted two hours to modify a form used across eleven country-specific sites for one specific use case on a single site, and he went crazy, stating that it'd take him "twenty seconds in PHP". A bit of Googling shows that this guy hacks a bit of PHP in his spare time, but can't code for shit, and given his position at the company it's not really up to him to dictate price.
Anyway, the only way to give a valid estimate is to break down the task as much as you possibly can and to assign risk to each small task. Build a spreadsheet and break down every task into the smallest possible unit, and assign a risk rating to it. Any tasks that are high risk should be estimated as a range, rather than a fixed time. Even with this advice you'll still get things wrong, but it's impossible not to. It's the nature of estimating.
The best advice I can give you is to stick to your guns and estimate for how long it will take YOU to do a task. If people still argue, then tough. As rightly pointed out by adios, more experienced devs/pm's will happily overestimate and will fight their corner to say that this is how long a task takes. If you are honest with yourself on how long a task will take then you will find it much easier to stick to your guns when someone complaints that "an easy task" shouldn't take as long as you've said.
Comments
I work at an agency using ASP.NET, so I find myself regularly estimating for projects and small jobs. The biggest issue with our clients is that they will always argue how long things will take. One of our large clients has a SEO guy in one of their offices that has "11 years web experience" (despite not programming professionally for the best part of three years, and seemingly knowing very little about programming or how the Internet works) and he will frequently argue every small cost. We quoted two hours to modify a form used across eleven country-specific sites for one specific use case on a single site, and he went crazy, stating that it'd take him "twenty seconds in PHP". A bit of Googling shows that this guy hacks a bit of PHP in his spare time, but can't code for shit, and given his position at the company it's not really up to him to dictate price.
Anyway, the only way to give a valid estimate is to break down the task as much as you possibly can and to assign risk to each small task. Build a spreadsheet and break down every task into the smallest possible unit, and assign a risk rating to it. Any tasks that are high risk should be estimated as a range, rather than a fixed time. Even with this advice you'll still get things wrong, but it's impossible not to. It's the nature of estimating.
The best advice I can give you is to stick to your guns and estimate for how long it will take YOU to do a task. If people still argue, then tough. As rightly pointed out by adios, more experienced devs/pm's will happily overestimate and will fight their corner to say that this is how long a task takes. If you are honest with yourself on how long a task will take then you will find it much easier to stick to your guns when someone complaints that "an easy task" shouldn't take as long as you've said.