project budgeting
June 7, 2008
It would be nice if you way start a project by setting the budget limit: this what we can spend. But you know that just becomes the target. The programmers want to spend it all. And then some. It sets the size of the project, but usually the lower bound, not the upper limit.
But what if you started by saying you want an ROI target: this project needs to return $50m in increased annual revenue over its costs. I never seen this done. But you can see the effect, to get that much of an increase, you probably do not have small incremental fix in mind. Or do you. Consider, if the process generates $1B in revenue now, that is a 5% increase. But if the process generates $200m now, that’s a 25% increase.
More to the point, if the project looks like it’s going to cost $50m with $5m maintenance costs (the rule of thumb is annual maintenance costs are 10% of the development costs) with a ten year life span the project costs out at $100m so you should be looking for $60m in additional revenue. These figures are simplistic, but you can see that perspective shifted from ‘how much can we spend’ to ‘how much do we have to earn’ or if you will ‘how much do we have to produce?’
Because programmers think what we produce is a software product. Once we deliver the code we’re done. We don’t think much about what the software has to produce, how much it has to earn for its living. We want to get programmers to think beyond code delivery.
I do not know any programmers who think this way. Hopefully commercial programmers think this way. But I suspect many if not most of them have a Field of Dreams illusion, if you write it they will come. Just throw that software on the web and let people find it. Passive entreupeneirship. You can see why most dot comes fail.
The trouble with inhouse development is that the project managers shield the programmers from the nasty budget and scheduling process. They’ve been forced into this mode of operation, programmers don’t want to know (they just want to complain about it later). I suspect this mode of operation encourages the attitude. But if programming is going to grow up we programmers are going to have to learn the business.
