CapEx, OpEx and Accounting for Teams

Years ago, I wrote about funding teams instead of projects. That covered a really common big-batch funding and approval problem: the feast and famine – and the learning curves that teams go through before they’re really effective. In it, I also suggested some alternatives to big-batch project funding, giving you smoother flow of value plus more fine-grained control, by using either a time-based, buffer-based or just-in-time method.

What that didn’t cover was a couple of related problems when you fund projects rather than teams.

1. A lack of visibility around actual spend. Organisations that rely on funding, approving and capitalising in large batches (i.e. Projects) tend to have quite poor visibility of their actual burn rate. They often get toward the end of the year and have a really painful realisation that the plan was optimistic, and massively underspent.

2. A lack of visibility of the contention for scarce resources. Project funding assumes that the scarcity that needs to be carefully managed is money. So the annual planning process places money at the heart. A big long list if projects is put in some sort of order and a line is drawn somewhere. Below the line gets no money, above the line gets everything they asked for (including the padding). But at that level, you have virtually zero visibility of the fact that a bunch of those projects are all assuming that they have full-time access to the same team or individual. The truth is, it’s not money that’s scarce, it’s your capacity to deliver change. That’s your teams. That’s the bottleneck.

Feast and famine. Poor visibility of actual spend. Poor visibility of contention. How to fix these things? Long-lived, stable teams that have persistent funding. Three steps:

1. Fund the *Capacity* (i.e. the team)
2. Align teams to *Objectives, Key Results* or if you have to *Initiatives*
3. Capitalise the *Outputs* (ex post)

To really unleash the teams, minimise as much as possible those big batch “initiatives”. In some cases, they are unavoidable. But in more cases that you think, it’s better to instead just point teams at the OKRs that matter and let them figure out how best to move the needle.

What about accounting?

That last step though – the “capitalise the outputs” bit – is where lots of orgs struggle. Without an alternative approach for this you tend to get stuck in project world.

Most organisations of course need some way to recognise when the team’s time has been spent creating an asset for the organisation. The suggestion, to “Capitalise the outputs (ex post)” requires a bit of work to set up. To do that without creating a massive cottage industry I’d recommend starting with putting labels or tags on tickets.

What labels? Here’s a suggestion:

Using these four buckets/labels is helpful because not only does it make it clear what kind of value you think this is going to deliver (and therefore to quantify the potential upside), it also sets you up with what you need for accounting purposes.

Increase Revenue and Reduce Costs should generally be capitalised. If things go the way you hope, Increase Revenue shows up as top line growth and Reduce Costs to bottom line growth.

Protect Revenue and Avoid Costs would generally not be capitalised, but treated as OpEx. Protect Revenue is about preventing the top line from sinking. Avoid Costs is about preventing the bottom line from sinking (all else being equal). Since you’re not generating new returns from these investments – just keeping things going as they are – you generally treat that as OpEx.

OK, all good in theory. How to operationalise this though?

At the team level – an example

This does require some setup. For starters, you need to understand your costs at the team level. This is the “Burn rate” for the team. How much money is having this team costing us per month, per quarter, per annum. For this, you need relatively stable teams that aren’t seeing fluctuations in headcount and therefore cost. (That’s not to say that the team are fixed. You can still move people around as needed, but you need to adjust your burn rate when you do.)

For argument’s sake, let’s say the burn rate of the team is about $30,000 per week.. That’s $60,0000 per fortnight (that’s fourteen nights for the Americans out there), $375k per quarter, $1.5m per year.

Second thing you need to some system for measuring the output for a team. That is, the number of “work items” that a team get through in an average fortnight or month. Weekly is often too variable, depending on how the team works. Fortnightly or monthly smooths out some of that.

For some teams, they’ll call these work items “stories”, or “tickets” or “features” or “tasks”. Doesn’t really matter the words. What matters more is that they are delivering end-to-end from a rough idea in a backlog all the way through to being in the user or customers’ hands.

The other thing that’s needed is that each “work item” is roughly the same size. (You can, if you’d like, use some sort of relative sizing, but it’s probably better to just spend the same amount of effort at getting each one roughly the same size. Smaller is generally better for flow anyway, but it does take some practice.)

So, let’s say a team get through ~15 “work items” per fortnight. $60,000/15 work items =~$4,000 per work item. With me so far? Now we get to the accounting part…

For each work item, they need to be “tagged” or labelled in some way as to which of the four buckets above they are shooting for. In some cases (often quite a few) they are contributing to more than one. That’s ok. We can handle that.

Doing the accounting

So, of the 15 work items, we just need to allocate the $4,000 across each of the different labels. Whilst you could, if you wanted to, get fancy with some sort of % attribution to each of the labels, it’s easier and faster to just assume an equal allocation. Here’s a hypothetical fortnight’s “output”:

NB: In this example, three tickets are tagged with both Increase Revenue & Protect Revenue – so, 1.5 to each of those. Another ticket is tagged with both Reduce Cost & Avoid Cost – so, 0.5 to each of those.

So, overall, for that fortnight’s output, we are looking to Capitalise $36,000 worth of investment, with the remainder of $24,000 going to OpEx, a 60:40 ration of CapEx to OpEx.

Yes, each fortnight could be different, depending on what get’s prioritised. If you have some specific ratios of CapEx to OpEx that you’re expected to hit, it’s fairly trivial to adjust the backlog in ways that still deliver incremental value whilst still achieving the portfolio mix you desire. It’s also trivially easy to boost one or other of the four buckets of value, depending on the opportunities and the wider economy and sentiment.

You may find that Fortnightly is too frequent to do this. Perhaps Monthly or Quarterly is a more suitable batch size. Whatever it is, I’d encourage you to find ways to align with the teams rather than forcing them to fit into your schedule. I’d also encourage you to as much as possible take the outputs and artefacts that the team are using anyway and make good use of them. Reprocessing just for administrative or bureaucratic purposes is a huge drain of energy and time for what is typically one of the most scarce resources that your organisation has. Tools can help, but make sure you use a tool that the teams actually like using and gets in their way the least – otherwise it’s just another drag on your bandwidth to deliver value early and often.

Accuracy? Compared to what?

You may think this isn’t accurate enough for accounting purposes. I would argue that the alternative, which is generally based on timesheeting against a bunch of big batch projects is far worse in terms of accuracy. For instance, we know that more than half of the features developed by teams are either never used or rarely used. Those aren’t assets, if you don’t take the time to go and unpick that code and remove it, you have created technical debt. It’s often the opposite of how you have accounted for it. And if you really believe your timesheets are accurate, I have a bridge to sell you.

So, that’s it! Give it a go and let me know how you get on. This has worked for me before, but I’m keen to learn what worked and what didn’t for you in your context.