Of course, they want a commitment. I’d think that’s where things like late penalties come in. “If my estimates are right, I have an 85% chance to complete by week X for a 14% profit or better, a 10% chance to complete by week Y for a 7% profit, a 5% chance to complete by week Z and break even, and a 5% chance of serious trouble.”

And if they say “But we have to have it by week X” then the obvious response is “OK, let’s look for ways to improve the odds.” You can look for ways to make the specifications easier to meet, or split the project into pieces and give each piece to a separate contractor, with a well-reputed group writing the interface tests. That has its own risks, but when the other contractors aren’t your subcontractors you have a better chance to get your own part complete and tested on time.

But when the customer prefers to go with somebody who’ll make a definite promise he can’t keep, that may wind up hurting the reputation of the industry as a whole but — that’s what the customer wants.

I do believe managers should be the one providing the estimation. It is probably the most important foundation of Taylor’s management priciple that managers should observe, collect data, and analyze. If it is the case, why not managers take time to review the history of his team’s capacity, and he/she will have the most accurate estimate in his mind.

Eg if the house is 60% complete, but the owner decides that they now want the pool to be where the garage is, the garage should be moved somewhere else (they *say* they don’t care where, but if you guess wrong there will be heck to pay), it should have a helipad on top… oh, and please replace all the insulation and wiring with fibre optic cable, because my buddy George was talking about how wonderful fibre optic is at our last golf game. And fibre optic sounds like fibreglass, so they must be interchangeable, right?

In that scenario, you would doubt the homeowners sanity. If they wanted all that, in the same time frame, without increasing expenditure or resourcing, you would just laugh at them.

Whereas in the Software world, such a scenario is all too common.

So what is our confidence level in the requirements? The more detailed they are, the longer it would have taken to gather them, and the more likely they are to have changed in that time, so the more detailed the requirements are the less confident we are in them.

Then there is the companion Anti-patterns to this one. Such as not refining the estimate, doing the estimate at the start, (when you know the least), and holding the developers to the original estimate even if the requirements change.

If the sponsor takes the original estimate and then starts making promises based on that, but doesn’t also actively protect those requirements, then their promises are threatened.

But these are just symptoms of the real problem, which is lack of power by developers.

But the way that most people estimate software tasks is by starting from their gut/experience. I think that using percentages to display confidence in this context, is a lot like “Potemkin villages”. It gives the impression of accuracy, where there simply is none: On what arguments would you base that some estimation has a 90% confidence level rather than a 89% confidence level? (Without going the route of some kind of “numerology” that is).
I think qualifiers such as “highly confident” or “moderately confident” will do a better job.

Another thing is that below a certain confidence level for (relatively) undividable tasks, your accuracy window for any subsystem (that is composed by a dozen of such tasks) will “explode” and cover a very wide area. This will have the effect that only estimates with a high level of confidence will be accepted, which makes the remaining differences even more arbitrary…