This is why I agree with the original article over these comment parents. I work in a small software agency for clients who would never grasp the Cone of Uncertainty. They are much closer to the pointy-haired boss type than the type of person who appreciates the finer points of software project estimation. While reading the literature is good, the average developer will seldom find the time to do so. And even if they do, an off-the-cuff estimate is often better than carefully planned specification documents that no business stakeholders will ever read.

Of course accurate estimates have tremendous business value. But in reality they often come at the expense of what the client really needs which is delivery of features. I have seen estimation and tight project control taking up substantially more time than delivering actual features. And it was exactly as the OP stated:

> Software projects that require tight cost control are the ones delivering little or no marginal value.

The lesser the project value the tighter the control leading to a vicious cycle of developers cutting corners and increased micro-management.

> I have seen estimation and tight project control taking up substantially more time than delivering actual features.

It sounds to me that what you saw was a conflation of estimates and plans. Which is a common error.

Clients sometimes want an estimate of how long a single feature or fix will take, even when it will take only 15 minutes. The communication overhead and time spent estimating easily outweigh the time to implement.

I'm ... not sure what this proves?

Nothing, just an explanation of what I meant by estimate.