Matt Heusser's article brings up some interesting points. Let's look to see if there are any limitations from a domain or context point of view. By domain I mean, in what taxonomy are you writing software for money. By context I mean what are the constraints or governance guidelines in that domain.
1. Make the amount of money small
This is a version of time boxing. It limits the value at risk for the development process. This bounds the risk process. In exchange for the total loss of doing the wrong thing information can be found. This is also called tuition cost.
Issue: We may not have all we need to forecast the total cost and schedule. Projects in many domains aren't made up of small chunks of themselves. So we'll need to confirm that the sum of the parts results in the whole. Integration, test, verification, architecture, interface management, and many other Systems Engineering aspects need to be involved in some way.
2. Fund a pilot that delivers working software and use this model to forecast schedule
This is buying a reference class. With the reference class - all be it a class of 1 - a forecast of future cost, schedule, and technical performance. We need all three in the reference class.
Issue: this is a larger issue of Number 1. With the pilot can we be assured that work can be scaled? Verification of that will have to be part of the pilot or a follow on. Then comes the confidence intervals for how that scaling will interact with the other - yet to be developed - components of the system. Is the scaling linear, nonlinear, stochastic interactions, and a whole raft of other discoverable processes. Each needs to be planned and budgeted.The ACA web site is a recent example. A UAV I worked where the engine didn't have enough thrust after the final integration. Etc. etc.
3. Move from contract negoiation to partnership
You've simply transferred to responsibility to estimate the cost and schedule to someone else. A single example - in the article - is not the basis of a syndicatable process. So this example, while interesting, probably isn't going to go too far with someout means to address the Estimate at Complete needed in most non-trivial software development projects.
Issue: Still don't know how much the project will cost in the end.
4. Employ Start Stop Heuristics
Seems like just another version of time boxed budget and schedule.
Issue: still doesn't address the Estimate at Complete before actually reaching the end or near the end of the project.
5. Drop Estimation From Your Estimation Process All Together
Another version of time boxed budget. Someone has to know how much money is needed to run the business on an annual basis. Or how much money will be allocated to do some work on an annual basis. This is called Level of Effort. Work until the money runs out, we give you more money, or tell you to stop. PayPal works in this way - sorta. The prioritization of the work is the responsibility asking for the outcomes. They have a budget. Give that budget (not funds, budget) to the development organization in exchange for delivered code.
Issue: The project will cost a know amount. We don't know what we'll get for that amount. But that might be OK. Once work is been going for awhile, a Reference Class can be built to allow that question to be answered, assuming the requested software fits inside the reference class in some way.
So In The End
The 5 suggestions don't have a domain beyond the single examples. And the suggestions don't seem to have a way to forecast the bounds of the project with an Estimate at Completion beyond the use of the reference class of the project itself. This self referencing reference class seems a bit sporty.
So yes, there are some ways to develop software in the absence of formal estimating. Although 2 of the 5 are actually using reference classes to forecast.
Those paying for the work to be done, still have to come up with some upper bound on cost, schedule, and technical capabilities for that cost and schedule. These 5 suggestions are a start. But we don't yet know where they can be applied. If they have been applied outside of specific anecdotes, and if they are scalable beyond the personal anecdotes.
No problem. This notion of not estimating is still evolving. At some point, answers need to be forth coming and the Yoda-style conversation replaced by business conversation - what did you do with my money?
In a meeting today on the difficulties of increasing the probability of project success in our domain (DOD/NASA). There were three sources of uncertainty around cost, schedule, and technical forecasting
The program runs into things that cause cost and schdeule overruns:
- It didn't know about.
- It couldn't know about.
- It doesn't want to know about.
We really shouldn't be doing #1 and #3. #1 means we didn't look hard enough. #3 means we can't handle the truth. #2 is the definition of uncertainty. But is it uncertainty because the project, didn't know or didn't want to know.
Doing stupid things in purpose
