Site Overview 
Is 'Design To Cost' better than 'Estimation of Cost': I think so!
So this paper is now on our website. I'd be happy to write a full paper for publication if someone invites me to do so.
http://www.gilb.com/tiki-download_file.php?fileId=259
The essence is that I am very unhappy with most all conventional thinking about software project cost estimation, the the Agile Story culture is no exception. Barry Boehm's COCOMO that long ago recognized that there are at least many dozen cost drivers (such as the availability level) is clearly much more realistic for large and complex systems.
http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html
I think the Agile Gang do not care about quality in any serious way, and certainly not the way a systems engineer has to worry for space and military projects.
But there is something that Boehm (who I admire greatly!) seems to have missed, Spiral Model notwithstanding. Something that Mike Cohn, the Agile Guru does recognize
http://www.youtube.com/watch?v=fb9Rzyi8b90
home page
www.mountaingoatsoftware.com
blog
http://blog.mountaingoatsoftware.com/
That if you actually do the project, with your team, architecture, and processes, in many early small increments (not really a feature of Spiral Model) you can get a practical insight into what things really cost, and adjust your estimates for the remaining project duration accordingly.
So, at the extreme, any random number, or politically interesting number, can be used as the initial estimate, but week by week a more realistic estimate can be made. And... week by week we can attempt to 'design to cost' so as to increase the probability of meeting any previously committed budgets or deadlines.
Well, here are my views:
Estimation or Control?
• Accurate estimation is impossible for complex technical projects, but keeping to agreed budgets is still possible using feedback and change.
Version: initial draft: 28 December 2006, Latest =29 12 06
First public release Nov 29 2008: at gilb.com.
©
Introduction
Accurate estimation of complex systems and software projects is seemingly impossible to guarantee. There are many unavoidable reasons for this. Even when estimation seems to work, this might just be a case of stopping the effort when the budget runs out, but as a result - delivering systems of unacceptably low quality.
The main idea of this paper is that there is a constructive alternative to bad estimation processes.
o You use ‘process control’ (do a little, learn quickly, change quickly) to quickly and continuously tune anything and everything about your project, so that prioritized budgets (like time to market, money, human resources) can be met.
o You consciously sacrifice less-holy things for your more-holy things
We are better off stipulating reasonable resource constraints (deadlines and cost budgets) and then learning to live within them. This is acceptable as long as we get our highest priorities satisfied when Resources run out. The rest is by definition, marginal.
Why we cannot estimate project costs accurately:
o We do not define Requirements well enough to estimate their costs
o We do not collect or have access to experience data that would allow us to estimate costs, even if we did have clear Requirements
o Even if we did have historic data for the costs of meeting clear Requirements, it would probably not help much because our new project would be different in some way.
o
We do not really need time and cost estimates:
o They are an old custom, intended to prevent overruns, and to give management some feeling that the job will get done in time at a reasonable cost. But they do not in fact prevent overruns or assure value.
o What management needs is delivery of some critical system Requirements in a predictable time frame
o And they need to be sure that the project will be profitable, and not embarrass them with unexpected losses.
o This paper describes an alternative way to achieve these management needs.
__
Principles of Resource Control__
The Risk Principles
1. DRIVERS: If you have not specified all critical performance and quality levels numerically – you cannot estimate project resources.
2. EXPERIENCE: If you do not have historic data about the Resources needed for your technical solutions - you cannot estimate project resources.
3.ARCHITECTURE: If you do your project solutions all at once without learning their costs and interactions – you cannot expect to be able to estimate the results.
4.STAFF: If a complex and large professional project staff is an unknown set of people, or changes in mid project – you cannot expect to estimate the costs.
5. SENSITIVITY: If even the slightest change is made after an ‘accurate’ estimation, to any Requirements, designs or constraints – then the estimate might need to be changed radically. And – you probably will not have the information necessary to do it, nor the insight that you need to do it.
The Control Principles
6. LEARN SMALL: Do projects in small increments of delivering Requirements – so you can Measure results and costs against estimates.
7. LEARN ROOT: If incremental costs for a given Requirement deviate negatively from estimates – analyze the root cause, and change anything about next increments that you believe might get you back on track.
8. PRIORITIZE CRITICAL: You will have to prioritize your most critical Requirements and constraints: there is no guarantee you can achieve them all. Deliver high-value for resources-used first.
9. RISK FAST: You should probably implement the highest-risk ideas early, so you have plenty of resource to deal with their uncertainties.
10. APPLY NOW: Learn early, learn often, learn well, and apply the learning to your current project.
Some Constructive suggestions to people who want estimates.
• Stipulate one or more useful deadlines from you point of view.
o Be specific about what has to be done by each deadline.
o Ask if these deadlines seem reasonable for the tasks prioritized.
o If necessary make adjustments.
• Stipulate the value to you of reaching each major (top 10) requirement. Make an outsourcing contract and pay part of that value only when that Requirement is successfully delivered.
• Do business with suppliers who consistently deliver value for money. Don’t waste your money on suppliers who make excuses. ‘No cure, no pay’ is one way to motivate suppliers to give you value for money – otherwise their motivation is to keep billing you forever.
