A Fool and His Money Are Soon Parted
- Thomas Tusser in Five Hundreth Pointes of Good Husbandrie, 1573
Say a customer wants you to develop a piece of software, but you want to convince the customer he doesn't need to have an estimate from you about what it is going to cost. The #NoEstimates movement asks if there is a better way.
One way is the flow down a budget to the development team. A small budget, for a small amount of work. Perform that work to calibrate the efficacy of the development team in producing value for the customer. Keep doing this in drips of funding and getting drips of value back.
Sounds like a logical approach. Low risk. But how much total money is it going to take to get all the value for the customer? The all in value for the all in cost? #NE doesn't say how to do this, other than keep spending until the customer says stop. No estimates needed here, simple process, nothing revolutionary, the developers are just a sunk labor cost managed externally by the customer. Customer does all the work of managing the project.
But some where, some how, some one has to have an upper bound on that spend plan. No credible business can operate in the absence of a budget. You can't operate your house without a budget - or at least you shouldn't. If the business is small, the business owner may have that budget in her head. If the business is large, that budget is in a financial planning document. That document is reported in some report to the Board of Directors. It's the obligated funds needed to operate the company. It's called the operating budget.
So how is that budgeted developed. Small business person probably just hs a gut feel. I'm willing to spend $X to find out what you can do for me. Here's $Y get started and let's see what happens.
A large business might do that. It's internal Research and Development (IRAD). Money to try things out, but the budget for that try things out has to come from somewhere and that somewhere has to have an approval cycle, and that cycle needs to know How Much.
For a large project inside a small company and certainly inside a large company, the budget for software development likely has an approval cycle. Again if there is no approval cycle, then the value at risk is probably small enough that no one really cares what you do with the money. But let's pretend there are people who care. Like the CFO, the CIO, the COO, the CEO. They need to know the value at risk. Their exposure to not receiving the promised value in exchange for the money.
So now we're in a loop. #NE says that are better ways. One better way is the drip funding. But that just pushes the estimating process back upstream. Someone has to estimate how much is enough. For larger project, how much is enough needs to be know to some degree of confidence, before those approving the money, will approve the money. It's as simple as that. No estimate - from someone - no money. That's how the balance sheet works.
Now, #NE has provided - through one presentation - how drip might works. But someone has to do estimates. Who? Not the developers obviously.
So maybe #NE is well suited for 5 week projects, that have clear and concise outcomes, low exposure to cost risk, and a customer who well accept that you'll be working in the project until the 5 weeks are up, doing your very best to maximize the value for that 5 weeks. Yep, that sounds like a nice job to me. Good work if you can get it. And maybe that's the point. It's all about small chunked projects.
But just a question. Can I deploy a $150M claims processing system in this way. How about a $500M embedded flight avionics system? Or a $200M wireless umbrella replacement of a wired phone system for 5,000 users? Good question, still waiting to hear EXACTLY how to do this.
And by the way, that Yoda management style of you discover on your own, I'm just exploring ideas here sounds pretty lame in front of the CIO of a $7B health insurance firm.
