Can we learn to restrict our work to a budget?

December 6, 2013

I’ve previously talked about the idea of shifting from estimates to budgets.

The fundamental point of this article is that it’s more useful to control costs than to predict costs.

The problem of this argument is whether it’s possible to develop software in that way. How will the relationship between the developer (or supplier organization) and the customer (or the customer organization) have to change? Is this a chance we’re able to make?

In my popular style, here is a typical dialogue:

Customer “… So, we’re going to change the patient appointment request form to include the social security number of the user and use this field in all the relevant processes. Can it be done in two weeks?”
Developer “I believe so. But we probably can’t automate everything in this case.”
Customer “That’s all right, just do what you can within that timeframe”
A week passes
Developer “I’ve done a lot of work, but I haven’t got anything to show you yet.”
Customer “You’ve spend half the budget, and we’ve got nothing to show for it? That’s it, I’m pulling the plug. Throw away what you’ve done and let’s work on something else.”

Meanwhile - in another universe

Developer “Let me show you: I’ve got the field in the appointment request form and it’s also displayed when looking at the appointment details. I’ve tested this automatically and manually, and deployed it on the acceptance test environment.”
Customer “Great work so far. These are the next improvements we want (in order of importance): Make sure that non-privileged users never see the number, include the field in the invoicing process and make the input form validate the social security number. Then integrate the field in other processing as well.”
Developer “Sure thing. I’ll talk to the users for details.”
Another week passes
Developer “I’ve fixed the security issue by checking the user privilege before displaying the field. I’ve also included the field in the invoice process. But I didn’t have time to add the validation. Everything is tested, of course.”
Customer “Great! We’ve spent the budget, so we’ll stop there. The validation is actually pretty important, so I’ll considering adding a new user story to the budget for that.”

In this story the developer had to produce a minimum story before spending half the budget. This ensures that we get something when the budget runs out. The developer had to finish one expansion of the user story at a time until the budget was expended. And then stop! When the customer wanted one of these sub-features bad enough, he had to create a new user story, thus expanding the scope of the project.

Can we learn to work in this way? As a developer, can I learn to organize my work so that I have something to show for it after just half the budget? Can I learn to keep track of the time I spend so well that I know when I’m over budget? And can I have the discipline to stop once the budget has been spent? As a customer, can I learn to accept that the developer will do the best he can within my budget and accept that?