Funding service teams rather than projects

Project funding is often used as a proxy for governance. Funding work as projects theoretically makes governance more straightforward as you track spend against a set business case. Given the issues with this approach with digital projects, there is clearly an argument for rethinking how we govern digital spend. Funding teams rather than projects is often discussed, and I currently work somewhere close to that approach. Here I outline the governance we use for our teams' spend. I’ve written previously on the benefits I’ve seen as a delivery manager for the team, so this is more an outline of what governance we use to achieve that. This isn’t exhaustive, and is only an outline of our model as everywhere has its own peculiarities.

First, there is the total amount that the organisation is willing to spend on digital. There will be various ways to determine this number including previous spend and projections. At the end of the day though, this determines the size of your team, and how much you can deliver. Once these people exist, you should be prioritising what they work on, rather than applying for headcount for projects.

The organisation decides where its priorities are, and provides part of its budget to support digital services in the organisation

Second, the organisation decides what its priorities are. There are a couple of ways of doing this, but grouping services that align to areas of business value enables the next level of prioritisation. The organisation decides the priority of each service group, and assigns a proportion of the budget. They also decide what they want the split of new build to live service support to be. A delivery team aligns to these services, and users of the services govern the service group.

We revisit this split quarterly. This is to ensure that the split still aligns to current priorities, and if the work done over the quarter has actually reflected the split. The flexibility of the teams means there may be variation if there have been lots of live service issues or change requests.

The organisation decides where its priorities are within digital between different service groups, and funds the delivery teams accordingly

Third, the members of the service group communicate the priority of the services the delivery team look after. This helps with deciding which change requests to accept, what level of support to give defects for different services, and which new builds take priority. We review this monthly, checking if the work still aligns to the priorities, questioning if it doesn’t, and communicating if the priorities need changing.

The organisation decides how much to spend on supporting live services against building new ones. Prioritising services against each other is done by the service group

The communication of changing priorities can go both ways. The service group contains users of the services who communicate their priorities. The delivery team raise anything they have uncovered doing user research or analysing live service issues. The team also feedback on the complexity of the work, and what impacts it might have. I've found this is particularly useful when prioritising change requests. Having users of different services discuss these together with the delivery team demonstrates the effect prioritisation will have on the delivery of other work.

The governance groups at both levels also act as a check that value is being realised. They agree and challenge budgets for new builds based on business cases, which act as upper limits for spend on that particular work. They can also provide challenge and support for benefits realisation. This model where governance acts as the critical friend to delivery, rather than a top down inquisitor is incredibly helpful in improving communication and gaining traction for change.

We do still have some challenges, and improvements to make. For me the main challenge is continuing to move the thinking from prioritising work to prioritising problems. Currently the delivery team has a lot of power to suggest different approaches and teams are coming around to articulating problems they want solved, but we still have some way to go. If the prioritisation at every level was on the basis of which organisational problems have the most priority, I would be pretty happy.