(Let me be clear up front: this is a potentially controversial post. It proposes radical change in the way we do things. But I feel strongly about it, and I think this needs to be said.)
Over the last few years, departments have been encouraged to adopt agile ways of working and service design thinking. Everywhere you go now, you can find multidisciplinary agile teams working on services, and making great progress. I'm part of one of those teams in Defra.
It's taken a few years for this new approach to catch on, but now it's caught on, the teams love it, and it’s delivering great user-centered services.
What hasn't changed in that time is the way everything is funded.
The traditional approach is to write a business case and create a project. Funding is found for that project, for a fixed period of time. When the predicted timeframe ends, so does the funding.
You can see the problem here: just as with designing services up front in a huge specification document, planning projects in extensive detail up front can lead to real problems. In real life, service development is complicated and unpredictable. The whole point of agile is that you find out what users need instead of making assumptions. But when it comes to funding, we're still making assumptions about how long each piece of work will take, and how much it will cost.
The result is friction between the teams doing the work and the people agreeing the budgets. That friction gets in the way of delivery and slows us down.
What's wrong with funding projects
Using the traditional project-based funding method, projects are given a finite length and budget. Changes within the scope of the project typically mean we have to go back to the approvals board (the decision-making body that decided the budget in the first place) to ask for more money or more time. The development of a service may be split up into multiple projects, or may be completed as one. Or it might be stopped completely.
The project model says: “We can predict what we'll be doing for the next few months, how much that will cost, and the benefits we’ll get from that work.”
The reality is that this was never true for either traditional or agile development. Predictions can be made at a high level at best, but typically plans are out of date within weeks, not months or years. The funding model assumes nothing will change. But things always change, and the funding mechanism isn't flexible enough to cope. There's no easy way to increase or decrease the budget, or to change the direction of development.
The project model says: “We can have a high degree of flexibility over how and where we spend our money.”
The cost of starting up a new team is rarely taken into account when putting together a case for funding. This means that to someone approving funding, the cost of stepping down a team by discontinuing a project isn’t taken into account. The implication of this is that if a funding request is turned down, then the money won’t be spent. But as long as we have permanent staff, those staff will carry on drawing a salary. Relying more heavily on contractors is not a solution - that just adds to the start-up costs for new projects, as well as the ongoing cost of staff turnover.
The project model says: “Approvals boards are best placed to decide on the direction a service takes.”
Approvals boards are made up of very senior, very busy people. They rarely have the time to decide the direction service development should take. (It's hard for them to have time to attend things like show-and-tells and user research sessions too.) Agile methods promote empowerment of teams, so ideally, a full time member of the team (the product manager, for example) should be responsible for making these decisions. By shifting product decisions to the teams, we free up time for the approvals boards to focus on wider strategic planning (more on that below).
In summary: the agile ways of working we're encouraged to adopt are weighed down by governance that is far from agile.
Why it's done this way
When you stop and think about it, you can see why projects are funded like this.
Agreeing project budgets up front provides certainty. There's only so much money in the pot, so if you have multiple requests for funding you can decide which ones have priority. You can see how the various projects align strategically with what you are trying to achieve. You can decide how many projects you can afford to fund in a single year.
But the reality is that none of those things are certain.
The certainty is an illusion. Real-world problems will interfere with plans and budgets. Projects will fail, because they break out of the rigid constraints they were devised under.
Funding teams instead
What if we changed our funding model? What if we started with teams, rather than projects?
I think we'd achieve more if we:
- allowed teams time to learn, grow and mature
- gave them a pipeline of work to tackle
- let them decide whether each piece of work is cost-effective, and progressing well
- let the team leaders decide whether continued investment in the team is cost effective
Under this model the role of the approvals boards would change: instead of project-by-project control, they focus on the wider strategy. They’d prioritise what’s in the pipeline, work with teams to decide when they should move on to the next item in the pipeline, and decide when we need to scale up and build more teams.
Let's make funding more flexible
We’ve updated the model of development, moving from projects to agile service design, but we haven’t updated the funding model to go with it.
That disconnect is slowing us down. It restricts our ability to develop great services. If we thought about funding in the same way, and started to fund teams to work their way through pipelines of work, I think we'd cut down on that friction and make better progress with transformation.
The good news is: senior people are already thinking about this, and taking steps to change it. I hope to be able to write another post here in a few months with an update on progress.