Appetite for Obstruction: How Government Procurement Is Strangling Its Own Agile Digital Ambitions
“You might call it agile, but if you don't set up the contract properly, it’s not. Call it what you like, but if it clucks and lays eggs, it’s a chicken."
- Agile Consultant on Universal Credit
The Government has proposed the agile delivery of digital projects at various points over the last few years in order to accelerate the delivery of mobile and online services to citizens in an increasingly digital world. And rightly so.
But why hasn’t it happened yet?
Amongst the various barriers that stand in the way of truly agile government-as-a-service I think that the outdated and obstructive procurement process is the least appreciated as well as one of the largest.
In order for agile policy to be delivered in an agile fashion, the procurement process itself must be open and flexible, with an emphasis on the needs of users over the preferences of departments. The procurement process currently obstructs this in three ways.
How the Procurement Process Obstructs Agile Policy Delivery
- The ‘old guard’ SIs that created the problem are favoured
Firstly, the procurement process favours the same large SIs that have been (mis)managing government projects for decades. These lumbering SIs are favoured because they are a known entity, despite the fact that these organizations are precisely those that precipitated the Government’s lack of in-house talent and experience in the first place. Their land-and-expand business models create a long-term reliance on their services, slowly hollowing out the Government’s in-house capability.
Instead, the Government needs to use suppliers that can give them the skills they so badly need through coaching, mentoring and pair programming.
2. The convoluted process means new suppliers can’t compete effectively
This brings us to the second problem: the convoluted and difficult procurement process makes it very difficult for new suppliers to successfully compete. A deep knowledge of its procurement and tender processes is required. This, of course, is a barrier in itself to small tech firms and startups, and gives an advantage, again, to the traditional suppliers to government – the large SIs – who have more experience and resources.
3. The tender process is not itself Agile!
Thirdly, the process itself is not suitable for delivering Agile projects. Requirements and deliverables are fixed upfront, with no user feedback until the service is in the citizens’ hands or scope for flexibility. This dooms any potential Agile project from the outset.
Together, these are having an adverse effect on the public sector’s ability to choose, deliver and complete successful projects that involve agile software development.
Case in Point: Universal Credit
Let’s look at a historical example. The DWP’s first major agile IT project was Universal Credit. This was part of the Government’s ‘digital by default’ initiative, which aimed to move away from large, outsourced IT programmes with incumbent system integrators.
They had contracts with the likes of HP, Accenture, Capgemini, IBM that fixed the features of the seven-year programme right at the beginning, making it a Waterfall contract. When changes to the original agreement inevitably emerged, the suppliers charged exorbitant fees to execute them. The DWP was left with spiralling costs and a service that didn’t meet the needs of its users.
"The fundamental problem was procurement," said a former agile consultant on the project. "Our hands were tied because of procurement … we were effectively on a waterfall project because it was a waterfall contract.”
"Universal Credit was wrong from the beginning. Government needs to rethink the way it procures. Until they change procurement, the rules of the game are stacked against anyone doing agile properly … You might call it agile, but if you don't set up the contract properly, it’s not. Call it what you like, but if it clucks and lays eggs, it’s a chicken."
The problem is that the traditional ‘project’ mentality gets in the way of the service that’s being delivered. This is where the procurement process fails.
Five years on, has the Government really embraced the changes needed to find a new way forward? I’m concerned that the procurement barriers are not going to melt away easily, and that they are acting as a buffer to engagement with the SME community.
Why Does the Procurement Process Fail?
Is it possible that departments fear the practical size of a big, sea-changing methodology like agile, and that it suits them better to do things in a business as usual fashion?
Last year, when GDS DG Kevin Cunnington talked to IT suppliers at a briefing, the issue of the lack of in-house digital skills loomed large. A shortage of as many as 4,000 people with digital skills across Whitehall was reported. He also talked about 1,600 databases in Whitehall which all contain citizen data, which are independent from each other, and in different formats.
When faced with statistics like that it’s easy to see how Government could fear practical change.
Whitehall needs to close that skills gap – a meatier in-house pool of flexible thinkers is required, and not just in development roles. Handing government contracts to the big SIs will never deliver this step change in in-house capabilities – after all what’s in it for them? Instead, more emphasis should be put on skills transfer and building talent from within, eliminating the need for further reliance on other parties.
To sate the Government’s appetite for obstruction, procurement needs a second life: clearer and more appropriate communication to the wider commercial world as well as deeper integration with the nature of the projects that it is procuring for.
