There are Mathematical Limits to Software Estimation: http://scribblethink.org/Work/kcsest.pdf http://scribblethink.org/Work/kcsest.pdf, http://scribblethink.or

There are Mathematical Limits to Software Estimation: http://scribblethink.org/Work/kcsest.pdf http://scribblethink.org/Work/kcsest.pdf, http://scribblethink.org/Work/Softestim/softestim.html http://scribblethink.org/Work/Softestim/softestim.html In general, unless you've done something very similar before, estimation can't be done accurately. Your manager should know and accept this. The best you can do is probably this: Repeatedly split the project into tasks, estimate the time it will take for each, until the next task takes several hours, and then do the next task. Keep track of estimates and actual times spent. Your manager should ask you to do this and keep it updated. Joel Spolsky wrote something similar here: http://www.joelonsoftware.com/articles/fog0000000245.html http://www.joelonsoftware.com/articles/fog0000000245.html (I'm sure I read similar advice elsewhere, but can no longer find it.) It should go without saying that you should include unit testing, code review, debugging, etc. in your estimates. And, of course, making and updating the time estimates. The project, when "complete", will still usually require maintenance, so work on the project only stops when the software is no longer used. You should never be given deadlines, as you won't know in advance what problems you might encounter, and the quality of your work (and probably your health) will suffer. This will result in a build up of technical debt, increasing maintenance costs. It's well worth reading The Mythical Man-Month, especially if you're managing a project, or working with others on the same project.