When asked to make estimates of future cost, schedule, and technical performance many wince. Many refuse saying we don't make no stink'in estimates here. Well there's a few problems with that approach:
- Those with the money need an estimate to get that money, hold on to that money, get more money and explain to those who gave them the money how they are being the proper stewards of that money.
- Without an estimate of cost, the value of something cannot be determine with any degree of confidence. This is the olde test driving a car you can't afford problem. I'd sure like to own the new Audi A7, but I can't afford it. Instead before I go shopping (with the actual intent to buy), I make an estimate of what I can afford, using my Credit Union payment calculator, then go looking for cars withint my budget.
- With the project underway, those with the money need to know how much more money and time will be needed to complete the project. This is the Estimate To Complete (ETC). With the actual costs in hand, that ETC is used to calculate the Estimate At Completion (EAC). That number should be - or better be in our contracting domain - at or below the Budget At Completion (BAC), which is what the real customer, the Defense Department, provided in bottom right corner of Standard Form 26, showing the contract award amount.
These numbers are Probabilistic estimates - except the contract award value. It's not probabilistic, it's a Not To Exceed (NTE) number.
So when there are objections to making estimates for lots reasons - some real, some very lame - we need to start with the full understanding that all estimates are Probabilistic. In the probabilistic estimating business, the best way to provide a credible number is from prior experience. This is called Reference Class Forecasting. Some might say, well we've not done this before so how can we estimate? There are very few things in the commercial software business that haven't been done before in some way. Don't be lazy, look around, ask some questions, do some home work, decompose the system into bite sized chunks that are recognizable as oh yea that looks familiar. This by the way is called system architecture.
Below is the Bayesian statistics formula which essentially says past is a forecast of the future. Don't whimp out, use common sense. Long ago I had advice from a Booz Allen site partner. We were working a large proposal for a Federal Agency. We had gotten all wrapped around the axle about stratgey, capabilities for the customer, our fancy dancy estimates and system architecture. He announced to everyone on the proposal team look boys its real simple our customer (the agency) has money and we want it. That's the strategy. The people with the money get to say if they want an EAC or ETC, no you.
