I don’t have the figures to hand but the SEI have a whole bunch of statistical research about what is and is not possible. A “mature” organisation — you know, one of those rare, sane businesses we all want to work for — can get estimate variation down to somewhere in the vicinity of +/- 20%. The SEI claim that teams following their TSP can get that as low as +/- 5%, but that’s for a really good team.

As usual, it’s not that we don’t have ways of developing much better estimates, producing better code, preventing defects and all the other software engineering wishlist; it’s mostly that nobody applies anything that the academics have cooked up. I have a theory that tools, and not methods, drive industry improvement. If it’s not in a dead-simple tool, it doesn’t exist in industry practice, end of story.

Of course you can always get lucky and with as many people in IT million to one shots happen every day. So good luck.

On the other hand, I’ve gotten fairly good at giving accurate estimates on half-a-day to three-days scale. If someone expects an accurate estimate on a month long project, it would have to be broken down into 30+ steps implementation plan.

I have participated in a 5-person, 5-month fixed cost
contract that became a 10-person, 18-month failure.
A lot of review went into that schedule. A lot of
tracking was done on that schedule. The company failed.

Don’t like Gantt? Try PERT charts, worked for NASA:
Ferens, D.V. “Computer software schedule estimation: an appraisal”

Think the problem is that companies don’t train schedulers?
http://www.ieeeboston.org/edu/2009spring/course_estimating.htm

I have a long list of war stories, all of a similar
nature…make a gantt chart, break the project into
8 hour chunks, track the project by day. Been there,
survived that. Nothing works. Nothing.

Find a thick piece of steel. Chisel this phrase:
NOBODY KNOWS HOW TO SCHEDULE SOFTWARE.
Mail it to management.