Using agile techniques to deliver software development projects promises clear benefits. Most notably, these include a 62% higher likelihood of success compared to conventional, sequential or waterfall delivery methods.
Agile practices that make software delivery successful are informing enterprise-wide operating models. Increased product focus and rapid feedback cycles can give organisations a real business edge, so it’s unsurprising that enterprises are turning to agility
In spite of this, a lack of understanding amongst senior finance leaders means funding the wider adoption of agile techniques can be an uphill struggle. This can leave agility confined to technology and perhaps one or two adjacent business units. Where this happens organisations do not develop a widespread culture of innovation and market responsiveness. Such companies fail to benefit from the improved business performance associated with agility and risk falling behind their more agile competitors.
As well as facing issues of funding, organisations can also run up against resistance to new ways of working among teams at other levels. Nevertheless, the way transformational investments are funded and managed presents the biggest impediment to wider enterprise agility. This paper explores why paying for agility can be difficult and suggests ways to overcome the challenges.
Why is funding agile so challenging?
The chief obstacle is the unwillingness to embrace uncertainty.
If the advantages of agility are obvious, why is it so hard to convince the finance department to fund it? There are typically two reasons.
First, internally, project accounting dominates decision making and forms the heart of the typical business case. This seeks certainty over costs by knowing the exact project scope and predicted long-term benefits. The finance department plays a central role governing the business case. This does not sit well with agile delivery approaches that embrace flexible scope in return for frequent, predictable releases to maximise market responsiveness.
Second, externally, accounting rules and regulations governing financial reporting require organisations to classify expenditure in ways that fit better with sequential, waterfall development methods than with highly iterative, agile approaches, where multiple activities are performed simultaneously.
In other words, the chief obstacle is the unwillingness to embrace uncertainty.
Differing project approaches to uncertainty
Agile accepts that not all aspects of a project can be accurately predicted
The reason project-cost accounting and agile do not make good bedfellows is, in a word, uncertainty. Project accounting and traditional financial governance processes seek to eliminate cost uncertainty or at least reduce it to the greatest extent possible.
The rationale being that by removing uncertainty it is possible to exercise greater control and thus predictability over outcomes.
This is achieved by defining a fixed scope of work and predicting the associated costs of implementation and benefits well into the future. Frequently, this process is linked to annual budgeting cycles encouraging the creation of large, long-range, business cases which bake in rigidity.
Eliminating cost uncertainty is attempted with upfront planning and a detailed work breakdown, but the further ahead the projections look, the bigger the errors are likely to be.
The problem is, costs produced this way are often wrong, with the degree of error correlated to the anticipated duration of work.
In addition, the likely benefits will depend on how well the project delivers what the market wants. Unfortunately, the traditional approach means it is only possible to test benefit assumptions, and thus eliminate benefit uncertainty, once the project is complete. If business conditions have changed or the underlying assumptions prove wrong at that stage, it’s too late to change since the full project costs have already been paid.
In contrast, agile accepts that not all aspects of a project can be accurately predicted.
Agile manages uncertainty by eschewing long-term estimations and testing the market through small, frequent releases that aim to confirm the benefit hypothesis in a smaller, more incremental, way.
Estimating error is avoided by providing only high-level estimates for long-range planning purposes, whilst focusing attention on techniques to increase the accuracy of short-range estimates covering only prioritised work scheduled for the near term.
Instead of attempting to predict benefits well into the future, agile uses small, frequent releases to test market responsiveness.
More frequent releases provide more opportunities to test market assumptions and learn what users want. Invaluably this affords the ability to course correct before significant project costs have been incurred.
These fundamental differences in approach to project ‘control’ make agile hard to reconcile with the financial governance applied in most organisations.
The external regulatory and reporting framework
The way that accounting treats costs is the second reason that the finance department is not a natural advocate of agility. In the UK, the regulatory and reporting framework (Financial Reporting Standard 102) within which all finance functions operate, requires expenditure to be treated either as an operating expense (opex) written to the profit and loss (P&L) account, or the cost of developing an asset (capex).
Capex improves the balance sheet whereas opex does not. For costs to qualify as capex, they must directly relate to the creation of an asset. This is important because the finance department wants to ensure that costs can be justifiably classified as opex or capex.
As the most recent regulatory reporting standard, FRS 102, identifies two separate phases of activity; ‘research’ and ‘development’. Costs are treated differently in each phase.
All costs incurred during research must be written to the P&L as opex. The logic is that when carrying out research it is not possible to demonstrate that an intangible asset exists and therefore it cannot be shown that it will generate future economic benefit.
Costs incurred during the development phase may be capitalised as contributing to the creation of an intangible asset, but only if the organisation can demonstrate the asset will be beneficial economically.
