A recent Blog post used an example of negotiated estimates between the developers and management. In the example buying a car is used and compared to negotiated the cost of software development. The car was an example of knowing information about what was being negotiated and the software was a example of not knowing what was needed to produce an outcome.
The notion that in the software business we don't know or can't know what the cost, schedule, and outcomes are before we reach the end is sadly misinformed. One of my colleagues - a former NASA cost director - has three reasons projects go over budget, get behind schedule and don't produce the needed benefits:
- We couldn't know - it was a true science project - inventing new physics
- We didn't know - because we were too lazy to do our home work, and come up with some assessment of what it could cost
- We don't want to know - because if we knew we'd never start the project, or we'd cancel the project now that we know
So let's pursue the car negotiation versus software negotiating on what something will cost a bit further
When negotiating the purchase of a car, the dealer starts with a price based on facts. The price paid at wholesale, the cost of money for flooring the car until it's sold. The buyer of the car usually comes equipped with facts as well. Edmunds pricing, Consumer Reports pricing, and similar sources of cost, margins, dealer incentives, local market conditions.
When the negotiations are successful, when there is a mutual beneficial outcome between the two parties - there is no asymmetric negotiating position. For the dealer, he moves a car, stops paying on the 90 day flooring note needed to put the car on the lot, and the buyer gets the car at an acceptable cost.
If we accept that estimates are for the business to make decisions more often than they are for developer decision, then facts are needed on both sides for a negotiation to have any mutual beneficial outcome for the business and those provided value to the business in exchange for the cost of that value.
When there is no factual basis of estimate, those asking for the estimate - the business, and there is no basis on which the judge the estimate provided by those being asked - the developers - there is no foundation for a mutual beneficial outcome. The result is an asymmetric negotiation. Those with the money usually win.
When negotiating the cost of software development effort between the person asking for an estimated cost and the developers providing the software, there is a similar process. When the developer says it will take 5 units of cost (hours, weeks, months) and those asking for the estimates say “I need it in 3” AND there is no basis of estimate for either 5 or 3, there is no means to actually negotiate and the result is those paying.
Those with the money have the final say on how much and when. The developers have no recourse, since they don't possess a credible counter offer showing that the real cost is 5. The developers are on the wrong side of an asymmetric negotiation.
Until those being asked - the developers - come to the table with credible, verifiable, statistically sound estimates, this relationship between those asking and those providing will never change. Those providing the estimate - and consuming the money need to have a credible basis of estimate. Those providing the money also need to have some sense of what a credible estimate looks like. This removes the asymmetric relationship and creates a symmetric relationship on which to actually negotiate a mutually beneficial outcome.
This by the way is one source of dysfunction the #NoEstimates advocates love to use without ever stating what is the source of the dysfunction. The Dysfunction is the asymmetric relationship between the parties. The buyers have a target, the sellers are clueless if that is a reasonable target - end of conversation.
Showing up with NO counter estimate to a requested number - is a self-inflicted wound in the negotiating business. The result is those with the money get to tell those without the counter estimate what to do and it turns into a lose-lose outcome. Then the developers blame the estimating process for the resulting dysfunction and wonder why the business no longer listens to them.
You asked me to do it for 5 and I have no counter offer, so you win and actually we all lose. Then blame the request for estimating for the dysfunction.
It is conjectured by #NoEstimates advocates that removing the estimating process will fix the dysfunction (what ever that is). Of course making decisions in the presence of uncertainty requires knowing something about outcomes as a result of the decision. But without a starting point for the estimate on the part of those spending the money, the asymmetric negotiating position cannot be removed. This is the actual source of Bad Management and cannot be the fix, since the negotiation is one sided and those with the money prevail when there is no counter offer.
This is like walking into the car dealer wanting to buy a car, with no understanding of the cost of the car you want - your the business. No Morhoeny Sticker. No web pricing. No nothing. And the dealer - the developers - doesn't tell you what the price of the car is either, because it's too hard, is waste of time, and believe they'll be held to the price they say.
Update
Gene Hughson added his voice to negotiating estimates
And I fixed the title to be less obtuse
