Managers responsible for a portfolio of existing applications must decide how to allocate their budget for application enhancements across their portfolio. For the purposes of this discussion, I am going to assume the following constraints:
- There are too many applications for the manager to make decisions on individual application enhancements. Instead, the manager must delegate this to product owners who have responsibility for specific applications.
- Enhancements would optimally be prioritized by expected return on investment (ROI), but ROI is difficult to calculate especially for comparisons between applications.
- Development teams are available for making these enhancements and need to be kept busy.
I have seen a number of strategies used for budget allocation that encounter difficulties:
- Allocate by historical spending. This is based on the immediately prior budgeting period . For example, assuming a 6 month budget, the amount spent per application from January to June would be the basis for allocation in July to December. The most serious difficulty this approach runs into is that it assumes that future work per application will match past needs, which is not always true. Some applications will have spikes of need driven by business changes that this allocation strategy does not take into account. Another difficulty with this approach is that it encourages each applications to spend all of their enhancement budget even if the return on investment is low (or negative) so that their budget is not reduced the following period.
- Allocate by application criticality and longevity. A common practice in application portfolio management is to assess each application according to its importance to the organization and expected lifespan, and then allocate budget accordingly. One difficulty with this approach is that the more critical and longer-lifespan applications may be very stable and require very little in terms of enhancements, whereas newly-built applications, irrespective of criticality or longevity, often have a higher volume of enhancements needed.
I propose a different strategy - allocating budget based on the backlog of work available for each application. This strategy avoids the disadvantages of the above approaches and makes it much easier to keep development teams busy since the money is being allocated to where the work is. Another key advantage of this approach is that it provides strong motivation for product owners to maintain backlogs. This helps provide insight to stakeholders (like the development team) within the organization regarding the future direction of the application, and makes it much easier to do activities like release planning.
Like all strategies, allocation by backlog can lead to some issues revolving around the backlog. Product owners may create overly large backlogs, typically padded with items that are either very low-value or that represent vague ideas that no one (including the product owner) would know what to do with. One possible refinement to the strategy to help avoid these issues is to only count clearly defined backlog items when allocating budget. One easy definition of "clearly-defined" is items that the development team can start working on immediately.
I will note in conclusion that any allocation strategy should not be used blindly - flexibility should be maintained to allow for budget adjustments both initially, at the start of the budget period, and over time as new information comes to light.
If you find this article helpful, please make a donation.