How should I fund agility?
Share on twitter
Share on facebook
Share on linkedin
Share on whatsapp
Share on email

“Our investment funding is tied to detailed upfront business cases and annual project cycles. Its hard to understand what a different funding model might look like in new ways of working”


In our Q1 Business Agility Pulse Survey funding models was one of the Top 10 antipatterns identified by those trying to improve ways of working in their organisation. 


This article offers an example  that meets generally accepted accounting rules (GAAP) and has been adopted by those at the front of new ways of working:


  1. A shift from variable project funding to fixed funding of value streams
  2. A shift from time recording of effort to algorthimic determination of cost

Having a supportive partnership with Finance is critical for these shifts. As one Business Agility Coach recently observed: 


“Once finance stopped asking ‘why am I in agile training’ and started working with us it definitely wasn’t perfect but it was SO MUCH better than before!”  

From variable project funding to fixed funding of value streams


Funding of projects and capitalisation of investment is well established in our industrial economy. For physical infrastructure it works well. Initial high cost of buying or building a complicated machine is amortised across its working life. This smoothes profitability accounting and tax receipts. A fraction of every machine’s cost is attributed across millions of widgets manufactured over time. Our accounting rules are designed to encourage periodic investment.


However In the age of digital the means of production has changed.  Every company is now an IT business – your digital services define your proposition. Constant investment at scale is needed to maintain competitive advantage, reduce waste, avoid cyber threats and satisfy new regulation. To control your destiny you need to continually improve your software. The industrial mindset of “I’ll build it once, then run it for years” – no longer applies.


On average, large IT projects run 45 percent over budget and 7 percent over time while delivering 56 percent less value than predicted – McKinsey, 2012

When speaking to CFOs about moving to fixed funding of value streams I have found an effective conversation to be:


“I promise we’ll never overspend again and I’ll give you a feedback loop on the value achieved by the investment once a month”

So far I’ve never met a CFO who disagrees with that.  


Last week the Finance team in a major corporate shared with us their approach for making such a transition, in 5 steps.


  1. Identify the long lived ‘value streams’
  2. Establish cost centres for value streams in the accounting system
  3. Move people & other costs into these cost centres
    (without Line-Mgt changes)
  4. Determine value stream budgets with Value Stream Leadership
  5. At mid/end-year review progress, if adjustment is justified by changed context then agree updates to 3 & 4

Achieving these 5 steps requires a high level of collaboration between the Finance, Ways of Working, and Delivery leadership (Value Streams).


When making such changes it is helpful to avoid overly granular value streams. In this case, for a firm with a market capitalisation of $12bn and around 100,000 employees, around 100 value streams were chosen. Value stream size varies – from 2 x ‘pizza sized’ teams, up to much larger.  



There is no secondary/shadow Project accounting system. There is no administration of rate cards, time recording, reconciliation and regular requests for more money.  


Cost is simply not a variable. Prioritisation of work is the variable. Value Stream Leads have long term accountability to generate value for their stakeholders and are empowered to prioritise, within enterprise guard rails, to maximise enterprise outcomes. Risk and regulatory policy must be supported.


If a Value Stream Lead believes there is a case for changing their capacity envelope, the implication will (mostly) be on their peers. Which Value Stream can offer up the relevant skills to help, what will be the implications of that overall, will the potential gain outweigh the potential loss through disruption of flow and context switching? Value Stream Leads discuss with each other and the Value Realisation Office. A mid-year adjustment (5) allows for financial movement if necessary, however in practice in this organisation little has been required. 


Infrastructure / Platform / shared service Value Streams


Use of an IT Cost Transparency tool to slice accounting data from cost centres using consumption metrics enables monthly ‘Show Back’ reports. This enables Value Stream Leads to be held to account for underlying costs they drive –  such as Cloud Hosting or centralised Data Services.


From time recording of effort to algorithmic determination of cost


Capitalisation allows costs incurred in one year to be deferred to future years from an accounting perspective. This can be attractive – for example where genuine investment spikes arise. However for organisations investing in technology on a continual basis using long lived value streams to continually improve services, capitalisation tends to be an antipattern for agility. The shift from project to product (or value stream) is accompanied by a shift from CAPEX to OPEX.


That being said capitalisation may need to be supported for historical or certain other reasons and there are better ways to do this than using time recording.


Time recording focusses on the worker rather than the work; it can act to reduce collaboration and distract from optimising the fast flow of safe value to the customer. 


Once teams are organised into long lived Value Streams represented in the cost centres of the organisation a key reason for time recording is eliminated but if capitalisation is still required this is often presented as a reason to continue the practice. Capitalisation rules are complex. Time recording data allows a financial controller to select what to capitalise (e.g. new innovations), how much of it to capitalise (using a rate card) and what not to capitalise (e.g. management). The data has the appearance of being granular and is assumed to be accurate. 


How can we ditch time recording?


The adoption of work management platforms such as JIRA or Rally provides an alternative data source that can provide a higher accuracy basis for capitalisation decisions using existing artefacts from the delivery process  


Here is an example of how one organisation ditched time-recording in favour of a more accurate algorithmic determination of cost per delivered software outcome:

  1. Add a mandatory drop down field in the work management system to make it easy to categorise the type of work. Users do not need to understand capitalisation rules.


  2. The new field exists both on the Feature (business) ticket and the User Story (detail) ticket. The combination provides a rich and granular context for capitalisation decisions.


  3. Each User Story is assigned size points by its delivery team during delivery, this may be revised at any time until closure to ensure it reflects actual effort.


  4. Each User Story is linked to a Feature (business) ticket


  5. At the end of each period, an algorithm runs. Actual cost on the cost centre is divided by the actual completed story points in the work management system ($s per point). Then for each capitalisable feature a capitalisation value is calculated based on its total underlying capitalisable story points.


Hints and Tips from a team who has been on this journey:


Q: How did you get confident the new data is more accurate?
A:  We operated time recording for a period, in parallel with the value stream capitalisation algorithm; we refined the algorithm during this time; we only cut-over to the new approach when stakeholders were comfortable


Q: How do you know that all work is in the work management system, that there is not some kind of off-the books invisible stuff?

A: The Ways of Working team run an “Are you fit” initiative to help delivery teams operate their backlogs effectively. Its a virtuous circle – the behaviours needed to create financial data are now the same behaviours needed for better delivery discipline. We run detective reports – if we find teams with few tickets in their backlogs, that’s a reason to engage; if we find releases that do not correlate to backlog activity, that’s a reason to engage. These are all non-comformities which we can help iron out for teams and they appreciate it. We also run lots of lean coffees, brown bags, office hours type sessions.


Q: What are the pre-requisites for ditching time recording?

A: We had already been running some key enterprise metrics for some time. Teams were all using JIRA or Rally because this was required to support our cycle time metrics. So the data needed for capitalisation was basically already being created in the systems. 


Q: How do you handle partially capitalised Features which get abandoned?
A: We are still learning answers for all these scenarios. We have started running detective monitoring for Features where no work has been underway for 3 months. We now categorise these as obsolete and ask the team to close the item. If its been partially capitalised then we will do a write-off




Across all industries and all regions the need for business agility has been recognised beyond the IT organisation.  Core functions such as Finance, HR and Audit are responding with new approaches that enable improvements in Better Value Sooner Safer Happier outcomes. 


The Finance community is a key actor in these changes to help organisations pivot from a Project to a Product approach. Patterns such as described in this article can help create a tailwind, and provide inspiration on the way forward.  However your context is unique and the way you use or evolved these patterns to improve the outcomes for your organisation will vary. 

Share on twitter
Share on facebook
Share on linkedin
Share on whatsapp
Share on email


Better Value Sooner Safer Happier


sooner safer happier book