AGILE IN ACTION

In the software world, budgets are mostly about headcount and capital expenditure. Headcount is managed by cost per unit, where a unit is a person considered to be more or less a uniform resource capable of producing fixed output. On a cost per unit basis maybe 100 people offshore are cheaper than 10 onshore. But in my experience, more people means more waste.

Projects typically get funded based on their business cases. Business cases that seem to stack up on paper usually get budget. Business cases that don’t stack up are either rejected, because they’re clearly absurd, or, they do get budget because the business sponsor shouted loudest or had more political influence.

Estimates are lies and estimating is waste. That doesn't necessarily mean it can't sometimes be useful. It's still waste but used at appropriate times, in appropriate ways, and understanding the flaws in the results it can help things along with business and finance people and clients. People just have to realize that it's just not possible to be any good at estimation. The best you can hope for, and certainly what you should aim for if you have to do it, is consistency rather than accuracy. If you're always consistently over or consistently under that's enough for reasonable planning.

Despite the UK Government issuing it's new budget today - oh utter joy, btw - this post was motivated by IT budgeting experiences.

Companies need to move away from using fixed price contracts where their expectation is, for a fixed price, they can have everything they ask for delivered on a specified day in the future. How did it get this way?

The Extreme Programming corollary practice of negotiated scope contract advocates fixing time, cost and quality while scope is negotiated on an ongoing basis. I am currently working on a contract that employs this practice. There is a contract per iteration that fixes time. The composition of the team is fixed per iteration therefore fixing cost. The quality is fixed by adhering to coding standards and ensuring a JUnit test coverage greater than 85% is maintained with the outstanding 15% corresponding to functionality that is unlikely to break.