I work in a domain where estimates are made every single week. Estimate to Complete (ETC), Estimate at Completion (EAC), Estimated Completion Date (ECD) are the life blood of our software intensive system of systems programs. To the left is a typical SISoS we work.
Embedded systems, data processing, image processes, web interfaces, backend databases, networking of collections of devices on the ground and in the air, training systems, logistics systems, maintenance and testing systems.
The management of SISoS is really no different than the management of any other enterprise class software system. People, Processes, and Tools all interacting in complex and complicated ways.
This is a normal environment for mission critical, must work types of programs I'm on as the Program Architect.
There are several partitions of this information that are common in building the Performance Measurement Baseline (PMB). The PMB is a time phased, budgeted description of the project. In traditional programs, this is an Integrated Master Plan and Integrated Master Schedule, with budgets laid into the Work Packages. In Agile the Product Roadmap and Release Plan are the basis of the PMB.
Since all projects operate in the presence of uncertainty, with the resulting risk - estimates are needed to make decisions that impact the future.
In the #NoEstimates paradigm, the term estimate is redefined to be Forecast and relabeled as NOT Estimating. This, of course, is nonsense, since estimates are about the past, present, and future. When past data is used, empirical estimating is the result. Estimates can be built with this empirical data, but models - parametric, Monte Carlo, Method of Moments - can also be the basis for estimating.
But Estimating is NOT Guessing. Guess is To suppose (something) without sufficient information to be sure of being correct.
So now to the point - What is an Estimate?
I belong to several professional cost estimating organizations that provide guidance and standards
- International Cost Estimating and Analysis Association
- Association for the Advancement of Cost Engineering
- IEEE
- ACM
- NASA
- Several other government estimating organizations
The generic definition of an estimate is straight forward, simple minded, and correct
A value that is close enough to the right answer, developed with some thought or calculation.
This allows that Value to be called what ever you want if you really need to redefine an estimate. But estimates are about the past, present, and future in the presence of uncertainty.
A better definition is
The process of predicting the most realistic cost, effort, or techncial oucome required to complete a software project.
But no matter what you decide to call what you do, to avoid calling it estimating, there is simply no way to make a decision in the presence of uncertainty without estimating the impact of that decision on your project. You can certainly make a decision without estimates, but you'll have no idea what will happen until it's happened. So actually you can decide without estimates. But since uncertainty is the creator of risk, you'll have not complied with Tim Lister's direction.
Risk Management is How Adults Manage Projects
So like the phrase we yes many times
What's the difference between our program and the Boy Scouts? The Boy Scouts have adult supervision
Anyone telling you can decide without estimating is either working on de minimus projects (no one cares) or selling you a hoax.