Not all business owners, product managers and sales managers associated with software development have come to their position from programmers. This post is mainly for them. But, perhaps, it will also be useful for software developers, who constantly have to answer two standard questions:
Why can not you give an accurate assessment of the complexity of the development?
Why can't you complete all the work twice as fast?
In one serious company in which I participated in the creation of a new business line, custom software development, I even held a small seminar to answer these questions at once to all business people.

Estimation is always a probability value.
Because evaluation is always done in the face of uncertainty. Therefore, one number is never an estimate. Evaluation is always at least two numbers. From ... to ...
')
Next is your choice at what price the development to sell.
Want to sign up with a potential strategic customer? You can sell at an optimistic estimate, get guaranteed losses and consider these losses as an investment in business development.
Want a guaranteed profit - sell at a pessimistic estimate.
And the grades from X / 2 to 2X at the RFP processing stage are very good grades. Because, uncertainty.
What is uncertainty
I will try to explain with an example. Imagine yourself as a developer who needs to be assessed. Estimates have to be given always. The only question is to the extent of their uncertainty - the width of the confidence interval.
Test. Are you a good appraiser?
Give estimates from ... and to ... for the following values:
The number of cities in the CIS, which have metro.
The melting point of ethyl alcohol (° C).
The length of the Dnieper River (km).
The maximum lifespan of a Galapagos tortoise (years).
Cashier first weekend in the CIS film "Stalingrad" (million rubles).

Right answersThe number of cities in the CIS that have metro: 16.
Melting point of ethyl alcohol (° ): -114.15.
The length of the Dnieper River (km): 2,200 km.
Maximum lifespan of a Galapagos tortoise (years): 177.
Cashier first weekend in the CIS film "Stalingrad" (million rubles): 565.
And now count how many times you managed to cover the real value and how many - to keep within the range from X / 2 to 2X.
Where does software uncertainty come from?
One more example. Rate the complexity of developing a simple function for entering a contact phone number of a new client.
I will say right away the answer is 20 minutes - wrong. The correct answer should contain two estimates.
Correct answerFrom 2 people * hour to 200 people. * Hour. Because no one at the stage of concluding a contract can answer simple questions:
Can multiple numbers be entered?
Should there be a validation of numbers?
Simple or difficult check?
If we implement a simple check, will the client want to replace it with a more complex one?
Should verification work for foreign numbers?
Can I use a ready-made solution?
What should be the quality of implementation? Probability of error after delivery?
How long will it take to implement and debug? (depends on the specific artist).
The last question is especially interesting. Because when we make an assessment of the complexity, we do not know which of the fighters will join the project team. Vasya, Petya or a new developer, who will be released in two weeks. And the human factor is the most significant uncertainty in software development. I refer to industry experience -
Barry Boehm, et al. "Software cost estimation with COCOMO II". Englewood Cliffs, NJ: Prentice-Hall, 2000.Here is a diagram of the influence of the human factor, calculated according to this method.

The diagram represents the influence of factors of professionalism of the project team on the project labor costs. Therefore, if you have weak analytics, this can increase the project's labor intensity by one and a half times. And the worst assessment of the complexity of all factors will differ from the best by 22 times. Here is the industry statistics.
And the last. About timing
Here are the laws of the same Bari Boema, which he brought back in the mid-80s.
There is an optimal, in terms of costs, schedule execution time for the first delivery: T = 2.5 (N h. * M.) ^ 1/3.
The cost curve slowly grows if the planned schedule is longer than the optimal one. Work takes all the time allotted to it.
The cost curve rises sharply if the planned schedule is shorter than the optimal one. Virtually no project can be completed faster than ¾ of the calculated optimal schedule, regardless of the number of people employed in it!
Something like this.
Successes.