Budgeting agile projects - codecentric AG Blog
In most Enterprises with an own software department ideas and requirements from the business must be approved before they can be developed. That means the business has to request for a budget and has to show a capital expenditure including a return on invest.
But how does the business know the costs for developing the required application? In most cases a requirement specification is written and based on that specification an estimate is made. (You can have multi-level approvements for making a rough estimate upfront but that’s not important for that what I want to say in this context) .
But who is paying for the specification? Mostly companies dispense of making an internal cost allocation. Therefore the requirements manager or business analysts need to provide the effort irrespective of the project will be developed or not.
A huge amount of specification is the result, which often buried in the files or need to be completely revised as the initial situation has changed.
How can agile development solve the problem?
In contrast to a sequential development method the agile approach doesn’t need to create a detailed specification which often takes month to finish. But this fact is not sufficient for a solution. The executive management needs to have the following information to make a decision:
- What kind of benefit brings the project and how big is the benefit compared to other projects?
- When is the project ready to launch?
- How much will it cost?
For question 2 and 3 the agile method doesn’t have a proper answer too. Who will bear the risk for projects without knowing when the project can be launched and how much it will cost?
Borrowing a finance model from venture capitalists
Venture capitalist are specialized in evaluating business plans and allocating money to very encouraging companies. This venture capital (also called “intelligent capital”) is allocated in increments with the option to stop spending more capital after each iteration. In our case the business plan comes from the stakeholder and is not a requirements document. It is more a description of the possible benefit.
That means to get more money after each iteration the project needs to deliver representable success. This is what the agile approach is promise to do. Agility means high-quality Software after short iterations on schedule.
Thus the goal is to divide software projects into small usable components and deliver those parts with the highest benefit as soon as possible. This makes it easy for management to decide on further capital for the respective company / project.
In a best-case-scenario it is possible that projects after some iterations paid by way of self-settlement.
An organizational implementation can be done as followed. The stakeholder from the business send their business-plans to a steering committee. The steering committee collects, assess and compares those business-plans. Participants of the steering committee should be the stakeholder, the executive management and product owner. Those plans with the highest business value and best strategy get the highest priority. The business plans (also called “Epics” in an agile language) will then be sorted into the product backlog by the product owner. I’m sure the rest of the process is known by you.
Essential for such an approach is a new way of thinking in the management. Those who see the IT as a pure cost factor, will never recognize the value and the potential of agile development. A culture driven by business value is needed and if you hold a professional agile development team it lays the foundation to become very successful.
If you can imagine such an approach or if you already have experience in such an enterprise it would be great if you drop some lines here.