De Luca on FDD Newsletter Issue 7
Requirements - The Budgeting Syndrome
|Managers don't ask for what they really need when doing budgets. They're not even thinking about things this way. It's a fictional and dysfunctional practice and it bears a remarkable similarity to requirements in traditional software projects. Both the budgeting process and the traditional requirements process are not agile and both result in significant wastage of resources and lost opportunity to deliver more value.|
Any line manager in a corporate will know what it's like to budget. What is the process usually like? Well, several months before the manager has to submit his budget for the next year he starts working on it. The manager looks at last year's numbers, he considers the projects and items for the coming year, and so on. As the budget is for a long period of time, usually a year, and the manager has to do it well in advance, he puts in as much buffer as he can reasonably hope to explain. In fact, many will ask for the maximum they think they can get, not what they think they will actually need. Oh, by the way, the smart manager also makes sure that all of this years budget is completely spent (otherwise he may not get as much to spend next year) and plans to spend earlier rather than later (since we've all suffered budget cuts before).
The budget is both a defined plan and an estimate. It's done well in advance and it applies for a long period of time. The plan and estimate are expected to stick for the duration. That is, the budget is expected to be right. The manager gets to state his budget needs once, at the start of the cycle and then that's it. He may get the opportunity for some small variance quarterly, but that's usually the extent of the collaboration or interaction between the manager and the providers of the funds. The only real interaction with the providers of the funds is at the start when the budgets are being set.
This is why the manager will put as much buffer in a budget as he can reasonably hope to explain, and will often ask for the maximum he thinks he can get rather than what he actually needs.
It's a syndrome. Managers aren't thinking about what they actually need. Up-front defined planning, where plans can't change, and there aren't subsequent and continued interactions with the providers, establishes this syndrome.
What are you thinking and doing when doing a budget? You are not thinking about minimum or actual needs.
Jim Johnson. The Standish Group International Inc. 2002.
A study by the Standish Group showed that 45% of application features and functions are never used.
On a traditional software project, when users are asked to do requirements, they will ask for all they can think of. They do this because they only get to state their needs once - at the start of the cycle and well in advance of the I.T. people providing the application system. There isn't subsequent and continued interaction with the I.T. providers.
The users ask for the maximum they can think of, not what they think they really need. And they make damn sure of it, because they know that I.T. rarely delivers all the function they ask for, so even more reason to ask for more. After all, if the users ask for only what they need, they know that something less will be delivered. The users also ask for the majority of function in phase 1 as they know that when a cut is to be made "the scope" is usually the first thing that is cut. So when users are creating requirements they are not thinking about minimum whole products or their actual needs, but asking for as much as they can as early as they can get it, in the hope they will get enough.
The very nature of the interaction makes for this syndrome.
This is why traditional processes with big up-front defined planning and requirements activities are often problematic. This is why processes and organizational cultures that only involve users for a one time requirements activity at the start of a software project are problematic. This is why Agile processes, such as Feature Driven Development, value customer collaboration - for the life of the project.
© Nebulon Pty. Ltd.
With thanks to the review team: Gavin Baker, Phil Bradley, David Bye.