In our Agile management and transformation support practice, we have observed several “Rubicon decision” moments in the scaling/extension/rollout of Agile. One such moment is in the decision to change an established project budgeting practice to better reflect the nature of backlogs and value streams.
Agile budgeting contributes to the successful implementation of a value stream–based architecture. The established project budgeting practice is founded on two cornerstones: investment accounting and portfolio management. Investment accounting takes care of CAPEX allocations so that capital is efficiently allocated to projects that offer the best mix of return indicators. Portfolio management takes care of priorities, strategic alignment, and risk management of the company resources (beyond capital). As portfolios are managed by high-level executives, the projects within them tend to be rather complex and long.
From this perspective, a project is born when the plan and associated performance indicators are accepted, and finishes when the final product is delivered, at which point the depreciation of invested assets starts and the project dissolves into the OPEX component. Poor project performance is mostly recognized only through the delays and scope changes that affect cash flows. Product performance is usually disconnected from project performance.
Agile budgeting in the value streams is different. It is about products, rather than projects, forming the value stream portfolio. A product can already exist and generate value or can be an innovative idea that may turn into a component of the value stream portfolio. In the first case, the product has some kind of revenue stream, operational costs, and (it is hoped) profit margins contributing to cash generation. The product (or portfolio of products) also has a backlog of changes that affect its market performance and operational efficiency. Such a backlog can include important activities, such as refactoring, that are often very difficult to justify in traditional budgeting practices. A value stream perspective offers much better judgment concerning the value of such backlog items.
If the product does not exist (e.g., an innovative idea), it will most likely be built as a “minimum viable product” by some part of the existing product team. It will then be included in the portfolio and developed through the process of validated learning, based on market feedback. Generally, instead of managing a large, long, complex project, the organization distributes the work into significantly smaller chunks (“epics” and “scrums”), delivering product-related backlogs.
Thus, it seems to make much more sense to replace project budgets with a product development budget, representing a portion of value stream operational expenditures and serving as financial capacity to be used to meet the business goals of the value stream. The job of senior management changes; instead of taking decisions on large, obscure projects represented mostly by high-level goals and financial indicators, they need to focus on managing value stream performance and empowering their leadership teams to manage product development budgets efficiently. The projects that remain are the ones that truly benefit from a C-level perspective: strategy management, company acquisitions, territorial expansions, creation of new value streams, and R&D investments.
It is important to understand that OPEX/CAPEX-related indicators are an established way for investors to assess company performance. For example, infrastructure-based businesses, such as communications service providers, have better valuation when their OPEX ratios are low, and CAPEX levels demonstrate their ability to innovate and keep their infrastructure in line with growing demand and quality expectations. Agile budgeting tends to increase OPEX by allocating to OPEX a (potentially substantial) part of project costs, which would in other circumstances become CAPEX. In the long term, OPEX should normalize, as less capital will be depreciated in future. But initially the change in budgeting approach may create a hard bump in investor relations; one that represents another important Rubicon to be crossed.
Certainly the change in budgeting must be very well communicated to the stakeholders before it is executed. It may be a wise move to invest some additional effort to run double accounting for a limited time and to demonstrate the evolution of company performance using both the old and the new perspectives.
In no way should the product budget allocation be viewed as “money spent.” The actual allocation of resources should strictly follow the business results of the value stream, so rolling forecasts and fast access to performance information are important prerequisites.
The practice of Agile budgeting is rooted in the competences of the product owners. Developing their business management skills provides a good basis for the implementation of Agile budgeting practices in a way that minimizes risks for the organization.
An interesting example may be how northern European banks, such as DNB, implemented Beyond Budgeting practices — one of the first holistic concepts of an Agile business architecture. Apart from replacing formal hierarchies with distributed, networked, collaborative teams, the new approach advocated abandoning fixed annual budgets in favor of rolling, relative performance goals based on internal and external performance benchmarks, with resources allocated on demand. As a result, reporting practices depart significantly from the standards to which stakeholders are accustomed, so pioneering financial institutions had to invest significant time and effort in educating stakeholders about the goals and means until the long-term benefits could be appreciated firsthand.
[For more from the authors on this topic, see “Crossing the Rubicons of Agile Transformation: Aches and Pains of Implementing Business Agility.”]