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.
I've been recently envolved in something very similar!
I've been asked by several customers to help them define their electronic strategy for the next 3 years (e-Governement). I've analysed thir needs, business concerns, market etc. Then we have set a couple of strategic vectors and started to fill in those vectors with stretegic components (Information Systems and application that they would need). All this in a framework thar took in too account 6 transformation criterias.
It came the time to estimate cost (budgeting). We did not yet knew the requirements for each component, we just knew their mission scope within the strategy, nevertheless for the plan to be approaved we need to be budget every component. The question was how much it would cost?
So basically we classified each component by complexity (complexity that would take into account different factors, change management, lack of information systems to back it up in place, lack of practices, etc). After this we transposed the complexity of each component to some time interval (this was a sensorial task rooted on a collective experience that was put into a fuzzy formula and adapted to by ....).
We had an average cost of the software required, plus the average rates that would be applied for development, installation and support). So a development cost was set to each component, the sum of these costs were the budget required.
But this is not over. After this was done we had to take into account the company finantial ability per year. So we have taken the last two years as a measure for the budgeting practice in the following years.
The result was a best effort budget per component (that would be basically a cost center).
It was approved!
If you need to enforce a strategic vision, and budget it there are other methods but non can be of course Iterative. An iteractive approach can be used to fine tune the strategy, and the budgeting but only after you have a baseline to guide you during the process otherwise there will be risk that the cost will outcome the benefits in ways that cannot be controlled in other manners besides .. abort! abort! abort! (When do enough is enough?)
Now its time to write some RFQ Documents per component and start scanning the market for suppliers.
Nuno Lopes
One more thing
I would'nt say that budgeting is a disfunctional activity. In fact it can be very very functional within the scope of the company strategy.
The bottom line is that you can steer the development of a project but rarely you can steer a budget!
Nuno Lopes
One more thing!
I have wrote:
"The bottom line is that you can steer the development of a project but rarely you can steer a budget!"
Domain Experts (the clerk, the picker, the mechanic, etc etc) are quite often unware of this reality, so is quite natural that they ask for every single feature they can think that will help them performing their job without the budget mind, neither the strategy sustaining the proposed budget.
Nuno Lopes
In reply to a couple of your points
Nuno
Experts (the clerk, the picker, the mechanic, etc etc) are quite often unware of this reality, so is quite natural that they ask for every single feature they can think that will help them performing their job...
Its my experience the people doing the work - the clerk, the picker, the mechanic, etc ask for functions that get used. Its the managers who think they understand how things work but in reality don't, that are the problem.
Second point is that the plan should accurately reflect the work that is performed and hence the budget should accurately cost the work to be performed. The reality in IT is that this is generally not the case. Ergo the budget is a fiction and just a grab for as much funding as possible.
I have commented that software development is a resource limited activity. So why not accept this and fix resources (i.e. dispense with the notion of a budget and a plan as a forecast of work to be performed). Management focus then shifts to optimizing fixed resources and away from the whole project notion, which I happen to think is a not very efficient way of doing software development. Software product development works this way because you must have a stable team of high skilled people. Release oriented (and iterative) development results naturally from this arrangement.
A fixed resources and flexible work approach is a much more Agile approach than is the planning/budgeting syndrome that Jeff describes.
Phil
In Reply
Hi,
"Its my experience the people doing the work - the clerk, the picker, the mechanic, etc ask for functions that get used. Its the managers who think they understand how things work but in reality don't ..."
That is my experience too, more or less. But is also my experience that domain experts are unaware of budgeting issues. That is my point of the previous reply. As for process owners only asking functions that will get used, IMHO that is not always the case, as they ask for things that will also be rarely used or not used at all (the embelishement risk). I believe that unless a compreensive approach for this issue is put on the table taking into account managers and domain experts concerns, there will always be problems (IMHO, It is naive to say that managers are the problem).
"Second point is that the plan should accurately reflect the work that is performed and hence the budget should accurately cost the work to be performed.
That is true, but the reason for that is becouse most people don't know how to plan for accuracy including myself sometimes. I don't think that a plan should accurately reflect the work that is or will be performed, rather then that should accurately plan deliverables (When do I want this feature ready). The reason why the usual plans do not work is becouse they attempt to reflect how work will be done accurately (process driven rather then objective driven), which is of course a straight jacket for developers. This is why most most GANTT plans are put in the drawer, not to mention that GANTT also falls into the trap of emblishement (ex: "this task is there becouse it should be there rather then is necessary to be there").
"I have commented that software development is a resource limited activity. So why not accept this and fix resources (i.e. dispense with the notion of a budget and a plan as a forecast of work to be performed). Management focus then shifts to optimizing fixed resources and away from the whole project notion, which I happen to think is a not very efficient way of doing software development."
I believe that different approaches can be put in practice depending on the business context. There is no solution fits all. If the scope is a fixed cost contract (that is the cost is set a priori) how do you deal with this? This is the main problem as far as I'm concerned. We should strive to understand why this is common practice in companies, I've tried to present some ideas complementing Jeff's point of view.
Quite often, the budget is a resource too to take into a ccount when planning. Especially when that manager say that we have $X to spend on this and no more. Even if the manager does not say this clearly there is always a limit on his mind.
The problem of overblowing budgets is not just one of software development. We have been witnessing this in all sorts of projects (How much will it cost to build Block C for R&D, or the Cultural Center, or the next Town Museum?) overblowing budgets (The Museum was supposed to cost $10M now is on $30M, we need an inquiry :). IMHO it is far more relieable to estimate cost based on time and materials around deliverables rather then how the work will be actually performed, that is, rather then process.
Nuno Lopes
Iron triangle
There is an iron triangle between scope, resources and deliverables. Everyone accepts that you can not vary one of the three without resulting in a change in the other two, but and this is huge 'but' process varies the relationship between the three.
IMHO it is far more relieable to estimate cost based on time and materials around deliverables rather then how the work will be actually performed, that is, rather then process.
If this is true then your processes don't add value, and you should look at getting new processes.
Phil
Iron Triangle
"If this is true then your processes don't add value, and you should look at getting new processes"
It depends on what you believe that value is. A process is just a mean to achieve an end (as the FDD book actually emphasis so much), so basically if the process allows one to reach the goal within the stated constraints it does not need to be changed.
I'm supporting FDD due to all sorts of reasons, none of them as to do with how I negotiate a contract or budget, but with how I manage software development complexity to reach and comunicate results. It happens that customers also appreciate this as the process itself promotes customer and developers awareness. But I never say to a customer that "look with this process you'll get there quicker/longer or with less/more cost", I prefer to say "with this process you'll be able to control/supervise the development of the project in the ways that you require" as the reporting features of FDD are so strong and simple. Furthermore "you" as the Manager can use this reporting scheme to comunicate with your Director, or Board of Directors about what is going (no more development black boxes).
If there is a problem everyone know what/where the problem is.
Nuno Lopes