Neil Killick posted a good question, what's the common ground for talking about estimates.
In this post I'd suggest predictability is very difficult to achieve in the presence of uncertainty. And all projects operate in the presence of uncertainty. All estimates have two attributes - accuracy and precision. The values of these two attributes are what those needing the estimates are after. With the knowledge of the two values of these two attributes the decision makers can assess the "value" of the estimate.
It may well be all they need is an order of magnitude (10X). "How much does it cost to install 50 sites of SAP, with 100 users at each site?" A question asked to our firm in the past. 100M, 200M, 500M? Or something more accurate and precise. "Can these two Features 2015007 and 2015008 going to make into the next Cadence release, scheduled for the end of November?"
Predictable is not actually an attribute without knowing the "Desired" accuracy and precision. That request comes from those asking for the estimate. In our domain that starts with a Broad Area Announcement to provide a "sanity check" to those asking for the solution to "test the bounds of the budget they may need to acquire the capabilities from the project.
Regarding the dysfunctions of business that are connected to estimates - there are many. Many in our domain and most other domains. But that dysfunction is not "caused" by the estimate. It may a "symptom" of poor estimates, but not the "cause." Without first identifying the Root Cause of the symptom, not suggestion for improvement will be effective. Root Cause Analysis is the key here. It's been suggested Estimates are the smell of dysfunction, but not root cause is defined, nor any Corrective Actions. Just the conjecture of a symptom. This is bad root cause analysis, no matter how many times the 5 Whys are suggested, it's still Bad RCA. So if we want to actually find the root cause of the dysfunction, it's going to have to follow a process.
Finally without a context for asking for the estimate and providing the estimate, the assessment of the needed precision and accuracy cannot be determined. Here's a paradigm to agile project management, where we can separate the domains and ask when is it appropriate to estimate and when is it not needed
My suggestion for a common ground is to establish
- The understanding that estimating are needed to make decisions for those providing the money
- The needed precision and accuracy of that requested estimate
- The available information (past performance), model (parametric or probabilistic) that the estimate will use, and how that information will impact the accuracy and precision
- Confirm that those making the estimate have the needed skills, experience, and knowledge needed to produce an accurate and precision estimate to meet the needs of those requesting the estimate
- Acknowledge on both sides of the conversation that making decisions in the presence of uncertainty requires making a decision based on an estimate of the outcomes of that decision. This estimate be "quick and dirty" even to the point of "it's my feel this will be the outcome," to a detailed bottom up Basis of Estimate for spending Millions if not even Billions of the customers money. This is the Value at Risk conversation. What are you willing to risk of you make that decision without the needed accuracy and precision to "protect" your decision for a loss?
Then those exchanging ideas about the need for estimates can have a common set of principles to exchange ideas. At this point there are no common set of principles. I'd suggest that the #NoEstimates advocates have not provided the principles by which decisions can be made without estimating the impact of that decision. And until there are principles from the #NoEstimates advocates, it's going to be hard to actually have that conversation.
