[sas224dbm]

I've worked on reasonably large >$100M defense programs for the last 25 years. Nearly all of them overran both time and budget constraints. They have mostly been firm-fixed price, except for the last 5ish years, that being incentivized agile. I have seen estimation be accurate when the following criteria are met :

1) Experienced personnel are estimating the work (experienced technically and in the product being developed); 2) The work being estimated is of similar technology to existing product; 3) The time period being estimated is less that 6 months

If any of these are violated, e.g. new hires are given the estimation task, a years worth of work is being estimated, new technology is being estimated etc, i would not trust the estimate, and apply big 'ol bucket of risk money.

[nonameiguess]

I actually have seen this legitimately work as well, as in being on a program where we pretty consistently hit every deadline with every planned feature at or under the promised price, for years on end.

But then take the same company, even many of the same people, and put them on a new project, and the estimates go to crap.

It really takes a lot of domain-specific experience, and I mean "domain" pretty narrowly, like knowing the code base, knowing the developers, knowing the customer, knowing the external surprises and constraints you're likely to come across because you've seen them so many times before. I've never seen it work for greenfield, even in an organization with the discipline and know how to do it correctly for their older applications they've been working on for years or decades.

[kqr]

What does "accurate" estimation mean to you? 50 % of things completed within that time? 90 %? Something else?