Back in October last year I wondered out loud why we couldn’t start funding teams not projects. At the time I rather naively thought that there was some senior person or group of people who just needed to be persuaded that this was a good idea, and everything would fall into place.
That blog post did kick-start some great conversations at Defra, and even made it to number 1 on our department’s list of digital principles. But I’ve learned a few things along the way. Chief among those is this: making big changes like this hasn’t been as quick, or as easy, as I’d thought.
I’m keen to explore why that’s so.
Licensing and Permitting
A large amount of the work undertaken by the Defra group involves providing licences or permits for people to do certain things. A lot of the work involved in providing these licences and permits is repeatable, whether we are providing people with licences to abstract water, or as with my team providing permits to handle waste.
A group of people leading the teams working on licensing and permitting took on the idea of standing teams and set up a programme of four standing teams that would work on a shared backlog of the highest value work from licensing and permitting.
Everyone was hugely enthusiastic. This would guarantee keeping the four teams together so would avoid losing the shared knowledge those teams had. It would also ensure those teams really were working on the highest value work rather than just focussing on the business area that was currently funding them. The group got together, discussed priorities and were all set to go.
A snag
The problem, as is often the case, was funding. Everyone agreed that funding standing teams was a good idea. Everyone agreed that having a shared backlog to keep teams focused on the highest value work was a good idea. But the question was how to fund it. Within Defra, a small amount of our funding comes through our IT department, but the majority comes directly from the business area that each team was working with.
Business areas were unwilling to give funding for teams that might not be working on their services. In particular, some business areas were unable to provide that funding, as the money that comes from their charges can legally only be spent on improving their service. We’d hit the problem of the agency model.
The agency model
The Defra group has a centralised IT department but decentralised funding for it. Internally this is often referred to us our department being demand-led, but it is also commonly referred to as the agency model. How this works is that any individual working in the department has a day rate, which covers both the cost of that individual working on a project, as well as any extras such as project support and line management. When someone from within the Defra group wants a service developed for them, they come to the IT department who will charge them for the people who will work on that project. This works similarly to a software agency, hence the name agency model.
So why follow the agency model?
The agency model is common, because the reasoning behind it seems to make perfect sense. By charging business areas for individuals you should be able to ensure that the highest value work is done, based on who is willing to spend the money. You also provide an impetus for the IT department to make sure as many people as possible are working on as many projects as possible maximising the department's efficiency. Finally, if demand increases sufficiently you can respond quickly by hiring contractors to fill the excess demand, and then release them again when demand drops.
Why doesn't it work?
The reality isn’t quite so pretty. Mary Poppendieck expressed the problem with this approach far more eloquently (and at far greater length) than I’ll ever be able to, but I would like to contribute particular problems I see here.
The big one is that in order to deliver a digital service, everyone needs a really great understanding of how digital development works. We’re not in a position where that level of understanding has reached everyone in the organisation, which means that as an IT department, we really need to take a lead in how projects are structured. Unfortunately, as an agency, we’re not in a position to do that.
If you’re funded centrally, and a someone comes with a plan to do a big 2-year project which will deliver everything right at the end, you can have the confidence to push back and encourage them to start with a minimum viable product (MVP) and deliver incrementally. If you’re funded as an agency, you’re looking at two years of funding for a team of people. How could you say no?
This leads in to the second problem. It changes the motivation of the department. If, as a department, you are judged by delivering great services, then this becomes your motivation. If you are an agency then you are judged by your ability to charge for your headcount. Delivering great services only becomes a means to the real end, which is fully utilising your resources.
If the organisation treats the IT department like an agency, we end up making it harder for us to fund teams instead of projects.
The impact on licensing and permitting
We did eventually get funding for the four teams on licensing and permitting, and it came from specific business areas. So while the hope was that the programme would have the flexibility to focus on the highest value areas, the reality is that we will likely have to carry on working on whichever areas have agreed to fund us.
It’s also worth noting that the funding has only been agreed until the end of this financial year. A huge amount of work went into agreeing that the teams could be funded for this year, and with the work came a huge amount of uncertainty in the teams. We didn’t know whether to wrap up what we had done so far, or to focus on what was coming up next. It seems pretty likely that all this work and uncertainty will be repeated again as we move into the next financial year. Whilst I am optimistic about the future of the licensing and permitting teams, only time will tell.
So how should things work?
Funding teams is hard. But we’re gradually getting better at it.
I think the end goal to support this would be decentralised IT and decentralised funding. This would mean IT teams loosely collaborating, but largely being focused in their business areas. This would give them full scope to not only develop great digital services, but have that digital development influence, and be influenced by business processes providing the best result for end users. That is quite a dramatic step, and would require a high degree of digital maturity outside of our IT department.
In the interim, having centralised funding for IT would mean that people in the IT department could properly structure how our teams develop digital services. This would allow us to deliver the business outcomes that Defra requires, cheaper, quicker and more effectively.
3 comments
Comment by Jack Oliver Aaron posted on
Hi David
Do you have any statistics for how much companies spend on team development? I imagine that given the difficulties you have listed, the amount is quite small. I was hoping to quantify that to some degree.
Best Wishes
Jack
Comment by David Thomas posted on
Hi Jack,
I'm afraid I don't. I guess it would also depend on what you would count as team development. I would say costs like Scrum Masters/Delivery Managers and time spent in retrospectives are pretty explicit expenses on team development. But any time a team spends working together will be developing and improving the way that team works.
As a rule of thumb I assume that a team that is freshly put together is working at about half capacity, and it takes a year to get up to full speed. If companies are regularly switching teams about then they are spending a pretty significant amount on team development.
Cheers,
David
Comment by Hakan Altintepe posted on
Hi David - Thank you for making an excellent case for 'funding teams rather than projects' in your previous post, and sharing your experiences along the way to funding teams.
Ideally, the business wants to have a clear commitment from IT for what they will get, when, and how much it will cost. The traditional 'project funding' approach gets very close to meeting this expectation by agreeing to a set scope, schedule and cost, dedicating resources to projects and project managing activities. On the other hand agile initiatives, by definition, do not have set scopes, schedules or dedicated resources. hence, the fundamental challenge for agile organizations is how to satisfy the commitment expectations of business.
Funding teams, rather than projects, is an evolutionary step in agile adoption, and it is not optional. Because, agile work needs to be organized in terms of products, products serve multiple customers, and therefore agile teams cannot be dedicated to a single customer demand. Project funding at agile organizations creates a wasteful conflict between business project managers and IT product owners, and when the pain is great enough, those organizations ponder moving to 'funding teams'.
As you elaborated in this post, funding teams is not easy. Furthermore, it is a necessary step in agile adoption but not sufficient to meet the commitment expectation of the business. With this new approach business will know what to pay, but unsure of what they will get and when.
Effective collaboration between the business and IT teams by establishing a product mindset eases this expectation gap, and there are additional steps organizations can take:
1) Minimize cross team dependencies - This means redundancies are continuously eliminated, and certain architectural and organizational components are duplicated. Both are expensive but routinely performed by leading agile organizations. (Note that, most digitally successful financial services spend 10% of revenue on IT, while average IT Spend/ Rev is 6% among financial companies. Digital native success stories often have deep pockets)
2) Optimize agile operating model - This requires advanced techniques to systematically prioritize backlogs, allocate capacity to teams, and manage portfolio work-intake rate.
With an effective collaboration, business and IT get on the same page about uncertainties. With minimized dependencies and an optimized operating model, IT teams feel more confident to make scope and schedule commitments. Consequently, business feels more comfortable with the idea of letting the project funding go.
Finally, I question if decentralized IT and decentralized funding will be suitable for all organizations, because these approaches will most likely lead to redundancy across IT while trying to reduce dependencies, and only a select few enterprises with deep-pockets can afford them.