Part 3 – Introduction

So far we have looked at why we should shift to a model where technology teams work directly for the business rather than via a separate IT department. We have also looked at how we can organise those teams to deliver value most effectively. This then leaves us with the problem of how to fund those teams. This is a real problem. And it’s often the single biggest impediment to making a change like this work – the inability to effectively fund long lived business technology teams. 

In most organisations, the only funding model available for non Opex work is the project. Capex work = project. This leads to quite a few well known problems. Having to continually stand up new project teams then break up those successful teams once the work is done. The overhead of having to go through a project approval process, which because it is asking for money, is often long and onerous which limits the organisation’s ability to quickly stand up important pieces of work. I once asked the C suite at a large bank how quickly they could respond if a competitor released an amazing new product that would significantly impact their market share. After much discussion they agreed that they could maybe, if they pulled out all stops and the stars and planets aligned just right, they could get a major project approved in 18-24 months. That’s not very useful in this age of rapid disruption. 

Projects also encourage a pattern of – we have the money approved, we have to spend it. Funded projects tend to spend all their budget regardless of whether they are delivering real value, in fact, they are often structured to make any assessment of successful delivery impossible until right at the end. 

Most work actually follows an 80/20 rule – 80% of the value comes from 20% of the effort. After that, there should be an assessment of whether to invest the remaining budget to realise that additional 20% of value. Sometimes it will make sense and sometimes it won’t. But in a project, because the scope is agreed, and firmly fixed, upfront, there is little or no ability to end a project early if the value: investment curve starts to flatten out.

Aggregated Project Funding

So how can you move away from a project based funding model? The reality is that most organisations don’t. What they end up doing is building a pipeline of funded projects with similar types of work and using those to keep a long lived team going. The team moves from project to project but stays together as a long lived entity. The organisation will end up with several project streams each keeping a long lived team, or team of teams if the stream is big enough, supplied with work, and funding.

This is a model that can work and it is very simple to implement. All you need to do is keep the project team together at the end of the project and have another project ready for them to move on to. It requires no changes to your funding model, no conversations with finance, just a steady stream of projects.

Be warned though, there are some downsides. That steady stream of projects can be hard to keep flowing, and any interruption inflow means that your long lived teams will be unfriended and have to be let go. I have seen this happen in many organisations, particularly near the end of the financial year when project funding often gets put on hold. That temporary lack of funded projects means that successful teams that have been working and delivering well for a year or more, suddenly run out of work and have to be let go, only to be needed again in a few weeks once the yearly budgets are approved and the money starts flowing again.

There is significant overhead involved with setting up and managing a stream of projects. In one organisation, they funded a 5 team group through a project stream and that needed the equivalent of a whole extra team, a 20% overhead, just to manage the project stream, schedule them and make sure the pipe was always full. It’s a simple solution to implement but a very tricky one to get working well.

The “Bucket” business case

The next simplest option is to take your project stream and aggregate it into a single large yearly business case. All you are doing is taking your annual plan and rather than funding each project individually, funding them in blocks. These funding blocks are much easier to manage and should, if sized correctly, keep the team, or group of teams funded for the year. Then once the next year’s annual plan is finalised, do the same.

This is a much lower overhead way to manage funding but it does come with its own suite of problems. The first being the key phrase “properly sized”. Making sure that the funding blocks are the right size to keep a set of teams busy for a year isn’t easy. It’s very easy for the money to run out early, especially if something goes off plan and needs more people than the initial plan allowed for. If the money runs out then you are back to needing to top up through individual project funding or leaving to disband the teams.

This also locks you into an annual plan of projects. If anything needs to change, it’s very difficult to do so. If you need extra capacity you either can’t or need to fund through individual projects. If the increase is only needed temporarily that’s fine but if it will be long term you are back to having to maintain a stream of funded projects to keep that increased capacity funded until the next annual budgeting cycle.

And of course, there is still little or no scope to drop work if it turns out to be not valuable. In fact, having to keep teams funded acts as a disincentive to stopping work. Stopping work means losing that piece of funding.

Capacity Based Funding

If you want to fund long lived teams effectively, the best solution is to divorce the discussion of funding from the individual pieces of work. So rather than fund work and assign that to people, fund teams and fill them with work.

This is a major rethinking of how funding works and needs a lot of organisational realignment but it can be done. And the benefits can be huge.

Essentially we flip our discussion from a cost of work discussion – how much will these pieces of work cost me, to an investment discussion focussed on outcomes – here are the business outcomes we want to achieve in this area, how much are we willing to invest to get there? That investment then funds a number of teams. 

Note that we haven’t even looked at what work they will be doing. That comes later. For now, it’s just a discussion about investment and business outcomes. Once the teams are funded, we can start to plan work to move us towards our outcomes.

This has some major benefits. For a stat we are focussing on actual business outcomes rather than project deliverables (which may or may not deliver actual value). So the teams have an incentive to measure actual business value and stop work that isn’t moving the dial in the right direction. No more spending your whole budget because you feel you have to. The team has the flexibility to adjust the work they are doing to ensure that the outcome is met.

The QBR

By including a regular review of work vs outcomes along with a review of the strategic investment envelope, we can build a really flexible process that allows the organisation to adjust its investment decisions on a much faster cycle than yearly and have those decisions based on actual data on value delivery rather than assumptions about projects. 

In many organisations this is referred to as the QBR or quarterly business review process. This is a quarterly forum where progress against outcomes (not individual deliverables but actual outcomes) is discussed and investment decisions are made – is a set of teams doing really well and needs some more funding to capture some extra opportunities? Give them more funding and take it from less well performing areas. Do we need to add capacity to plug a gap? Move funding from where it is needed less. This sort of whole organisation participatory budgeting allows the whole organisation to align on the delivery of the best possible business outcomes

Of course, it all hinges on how we measure how effectively teams are delivering business value. How do we do this? We’ll look at that next time.

Read Part Four: Measuring Success

Single View of Work