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 (a fixed asset) is amortised across its working life. This smoothes profitability accounting and tax receipts. A fraction of every machine’s cost is attributed over time to balance the revenue being generated by the assets. Our accounting rules are a product of prior technology-led revolutions, the industrial ages, with large infrequent, capital intensive expenditures on fixed assets.

 

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, meet cyber threats and meet 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:

 

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

 
So far every CFO I’ve met has welcomed this conversation! 

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

 

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. Agree value stream funding constraint with Value Stream Leadership
  5. Pivot the focus from pre-determined output and milestones to regularly realising the most value, treating funding as the constraint
  6. Decouple prioritisation from funding
  7. Review quarterly or half yearly and if justified then apply an update to (3) and (4) 

These steps generally require a high level of collaboration between your Finance team, Ways of Working team, and Value Streams. This is a big mental shift from funding temporal projects to funding long lived teams, on long lived value streams, aligned to the customer, to achieve a continuous fast flow of value.

It is useful to avoid overly granular value streams, at least initially until the new processes are established. In the above example, 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.  If necessary value streams can be nested: team of teams, team of team of teams etc.

 

There is additionally a typical conversation about infrastructure / shared service platform teams. These platforms operate as enablers for value delivery. For example the organisation may operate a centralised data platform, or a centralised hosting platform. Their costs can be managed in the same way as above, with cost as a constraint. It is usually helpful to provide visibility of consumption to consuming value streams, using cost driver/consumption metrics to encourage responsible consumption behaviour. Use of show back reports generated using tools such as Apptio are a common pattern here.

 

 

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 linked to a Feature (business) ticket
  4. At the end of each period, an algorithm runs. Actual cost on the cost centre is divided by the actual completed stories in the work management system (average $s per story). Then for each capitalisable feature a capitalisation value is calculated based on its total underlying capitalisable story value.

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

Conclusion

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

MORE ARTICLES

Better Value Sooner Safer Happier

ANTIPATTERNS AND PATTERNS
FOR BUSINESS AGILITY

sooner safer happier book