By Tony Collins
Alistair Maughan, a lawyer who specialises in large ICT projects, argues that agile won’t work in government ICT.
“The Government ICT strategy had some good ideas. Agile project management isn’t one of them,” says Maughan in a cogent and informed blog post for Computer Weekly.
I asked the Institute for Government to respond to Maughan’s comments. The Institute advocates agile in its report System Error: Fixing the flaws in government IT.
My thanks to Jerrett Myers, a senior researcher at the Institute, who has written the piece below, in response to Maughan’s comments.
Agile government ICT – a question of innovation
Like any management innovation, there are plenty of challenges in adopting an agile approach, but fortunately none are insurmountable. The innovation guru Everett Rogers outlines a series of factors that influence the rate of adoption of an innovation – in effect setting out a test for how likely it is for an innovation to be implemented.
The first is test is the relative advantage of the innovation – the degree to which a new way of working is perceived as superior. Government departments and agencies have reported extremely positive results from agile projects. Indeed, the Department for Work and Pensions, the Ordnance Survey and the Ministry of Defence have all used agile methods for delivering ICT projects.
Regularly changing priorities, advances in technology and the desire for more cost-effective and user-led solutions require a far more responsive approach to running ICT projects. Of the thousands of people who have downloaded our recent report, we have had an overwhelmingly positive response to the idea for government.
So how can government make it work? The second innovation success factor is ‘trialability’ – can departments test out this approach on a limited basis. Again, the good news is that at relatively low cost, departments can use an agile approach for running ICT projects – and indeed they are committed to doing so.
The third characteristic is ‘observability’ – are the results of the innovation visible to others. Whitehall has committed to creating a centre of excellence across government and the private sector which can enable fast start-up and mobilisation for agile projects. It will also establish a cross government approach and capabilities for agile. This should serve to raise the profile and ‘observability’ of agile projects.
The fourth factor is complexity – how difficult is an innovation to use and understand. Here, the government faces a greater challenge. New skills will be required which are ‘in-house’ rather than bought in through contractors. This includes making difficult trade-offs and prioritising effectively. Regular testing, planning and demonstration will need to take place to handle risks. And by taking part in agile projects, it can serve to internalise agile values, build skills and help to foster support, understanding and momentum for change.
The final factor is perhaps the greatest barrier to overcome – compatibility – the degree to which an innovation is consistent with existing values, norms and operating procedures. Maughan underscores how different the agile approach is for running ICT projects. The project approval processes and legal arrangements governing contracts need to be adapted to be far more responsive and receptive to agile delivery.
Equally important is the culture of empowerment that needs to surround projects. Fortunately, the experience in other large organisations in the public and private sector suggest this transition is possible.
At a large government agency, budgeting and governance processes have changed to accommodate and encourage more agile projects. Its new investment approval process involves obtaining early permission to fund development immediately without a fully specified business case being approved (although a robust justification must still be provided). The projects are given permission to spend at a particular rate over a period of time and return to the investment board at specified intervals for further approvals and to update on progress.
On each of these points, it appears that agile can succeed with the right leadership and determination for change. Ultimately, however, this isn’t just about adopting a new approach to government ICT, reforming the procurement process or taking a more sophisticated approach to managing risk. Instead, it is a test of Whitehall’s capacity for innovation.
**
Jerrett Myers is a Senior Researcher at the Institute for Government. The Institute for Government’s report, System Error: Fixing the flaws in government IT can be downloaded here.
Alistair Maughan’s blog post for Computer Weekly is here.
Campaign4Change 
Tony,
I couldn’t agree more with Jerrett’s sentiment about when to adopt an innovation, and the approach. Having said that it doesn’t address the original comment by Alistair that agile doesn’t fit government – and as of today – I would be inclined to agree.
Now, before you think I’m siding with a lawyer (heaven forbid), it does illustrate the total lack of understanding within the legal community for how to advise their clients (government included) on how to “do” an agile project.
Alistair starts by saying an agile contract is for resources – WRONG ! – it’s for a rate of change and a set of agreed deliverable dates, and a termination clause. Note that I don’t include the deliverables in that list – most lawyers feel uncomfortable about that, so can’t believe they should contract without it, but they are invariably wrong at the start of a project, so you end up in change-request hell, so why not start there by contracting for a rate of change?
Alistair continues by arguing that government customers want fixed-price up-front, so as a lawyer he recommends against agile. How many projects do you know have delivered for the initially quoted price? – Even government understands it gets ‘stiffed’ on the change-request culture that fixed-price contracting breeds – and let’s face it, if you have to resort to the contract, you’ve lost anyway because their lawyers are better than the government ones. Agile delivers early and provides confidence that the “cone of uncertainty” (look it up !) is headed in the right direction, and can typically do so within months of starting a project, so the overall risks are lower.
Alistair then throws into the mix the usual “procurement” red flag saying we are legally bound as government to select “apples-for-apples” and pick the best price. There are two flaws with this argument – firstly that government already has “frameworks” from which it selects who it wants to work with on a rate-card – so any given project is staffed on T&M anyway – no-one dares to measure the effective value from these suppliers (save when re-negotiations are due) and government is typically 6-10 times less effective at delivering functionality per man-day than the best of the private sector.
Secondly there are many mechanisms within public procurement law that enable a customer to select the best supplier of agile resources on a monthly basis if needed – go look up “Dynamic Procurement” in the regulations and then consider that the last time I looked only 9 UK authorities used this process last year, and 5 of them ticked the wrong box accidentally when filling out the form. Perhaps better legal advice on how to use DPS would help?
Thirdly, Alistair says without the contract containing the deliverables, there would be no recourse to sue the supplier should they fail to deliver. Let’s look at that objectively in the light of the NHS “farce” and whether government will ever recover monies from a failing supplier? – I believe the damages and cancellation costs currently run to £100Ms and beyond – how is that better? Then consider the alternative of an agile project that can be terminated at a moment’s notice with nothing more to pay when the deliverable has been met, or the instant it looks as though it won’t – why isn’t that better for the tax payer?
Finally Alistair points out that agile requires direct and key involvement of the customer and a level of trust between the parties. Don’t start an agile project if you don’t have these things – and for once I would agree. But then again, why would you start a traditionalproject if you don’t have these things? You’re simply starting on the wrong footing, and likely to need the lawyers. Trust is built upon visibility of deliverables, and agile makes these appear at the start of the project, not at the end. The availability of customer resources is always critical – seemingly they are made available at the end of a project to give evidence when it all goes wrong, so why not spread that commitment throughout the lifecycle?
As with any innovation, “agile” involves a change in process, and that change in process makes people uncomfortable. Both government and it’s suppliers need to do something different, so both need to be advised on how to change as the very definition of insanity is doing the same thing over and over again and expecting different results (Einstein 1921).
Regards,
Adrian.
LikeLike