Some good stuff in there, but heard most of it in earlier publications. Reading Steve McConnell's "Software Estimation" covers a bunch of it, Cone of Uncertainty etc etc.
Here's where i've seen estimation become accurate:
1) The people doing the work are estimating the work, and KNOW the software base they are estimating for.
2) Technology being used is not shifting considerably for the piece being estimated.
3) Processes being used to go from requirements elicitation to acceptance are not shifting dramatically for the new piece of work.
You have to have probably 2 of these 3 to have any chance of reasonably accurate estimates. I've seen this work on a fairly large (1 MLOC C++) sonar system development. After a couple of 'late' releases, where those 3 premises were not true, estimation became better, and after 3 or 4 releases, teams were getting pretty accurate, such that customer trust went through the roof.
If you don't have 2 or 3 of those ticked off, you'd better add in a bunch of padding, or get some risk $$ from the C-suite signed off.
Here's where i've seen estimation become accurate:
1) The people doing the work are estimating the work, and KNOW the software base they are estimating for.
2) Technology being used is not shifting considerably for the piece being estimated.
3) Processes being used to go from requirements elicitation to acceptance are not shifting dramatically for the new piece of work.
You have to have probably 2 of these 3 to have any chance of reasonably accurate estimates. I've seen this work on a fairly large (1 MLOC C++) sonar system development. After a couple of 'late' releases, where those 3 premises were not true, estimation became better, and after 3 or 4 releases, teams were getting pretty accurate, such that customer trust went through the roof.
If you don't have 2 or 3 of those ticked off, you'd better add in a bunch of padding, or get some risk $$ from the C-suite signed off.