When the discussion of estimates starts from the point of view of developers that have not worked in domains where cost, schedule, and technical performance estimates are the norm - in fact are the bread and butter of the project - it is surprising to learn they think of estimating as a Dilbert boss process.
The notional picture below is our standard process for large, software intensive, mission critical, and nearly impossible programs - per Edwin Land's quote. Early in the life cycle it is simply no possible to have an accurate estimate in the same way we would have one later in the program.
All estimates, no matter when they are created have confidence intervals, whether they are recognized or not. The question is never should we estimate? Because we must estimate. Not because the customer asked for the estimate (even if they do), but because without the Estimate to Complete and the Estimate at Completion, it is not possible to determine when we will be done and how much it will cost to get to done. The only way to do without an ETC and EAC is to stop work when the customer runs out of money. Working in that paradigm is called Level of Effort and we are then just labor - not that much fun, since someone else is making assignments of the work we are doing.
The notion used by some is to time box the work efforts. Provide a fixed amount of money, perform work at some steady pace, with prioritized activities from the customer. This is all well and good. And is a flow based process found in most manufacturing domains, including software Kanban.
But someone, somewhere still has to come up with the not to exceed (NTE) budget for that flow work. Segment the work into near same sized chunks so Little's Law can work - queued inputs arrive at the same rate as outputs leave the system, so a backlog is not created.
So without the ability to estimate our future performance, either because the information is not available, or we intentionally refuse to learn how to develop probabilistic estimates, we are driving blind. Sure, if we have a list of work activities that are same sized and we can assess (this will require and estimate as well) your capacity for work, we can calculate - again considering the variance in our estimated performance - how long it will take to complete that list of work.
That is the machine center Kanban approach. But the total cost and duration of the project is not known unless all the work activities have been planned and sized and placed in the queue. That's called Big Design Up Front. And once this is done, and the Kanban process is in place, the development team becomes labor, just like that machining center. Highly paid labor, very creative labor, critically important labor, but labor all the same. The work of planning, estimating, and forecasting the performance of the project will be left to someone else.
Estimating the future is not about control, it is about avoiding the undesirable.
So if Aristotle can figure this out in De Motu Animalium c. 400 BC, we can probably do the same. Unless of course you simply don't want to answer the question how long will this project take and how much will it cost, what things can go wrong, how many resources do we need to complete on-time, on-budget, and conpliant with the requirements without having to wait till the end of the project.
The rough translation ... But how does it happen that thinking is sometimes accompanied by action and sometimes not, sometimes by motion, and sometimes not? It looks as if almost the same thing happens as in the case of reasoning and making inferences about unchanging objects. But in that case the end is a speculative proposition ... whereas here the conclusion which results from the two premises is an action. ... I need covering; a cloak is a covering. I need a cloak. What I need, I have to make; I need a cloak. I have to make a cloak. And the conclusion, the "I have to make a cloak," is an action.
Thanks to Richard Askew.
