“Not if what I’ve seen of ‘agile’ approaches in government IT is anything to go by.”
His comments, in full, are below.
He paints a picture of Government IT as riven by the interests of those involved: suppliers and public servants.
If he’s right, and if Sir Richard Mottram is right thatWhitehall organisation is a variation of anarchy, shouldn’t there bemore external and independent scrutiny of the billions spent each year ongovernment IT?
The National Audit Office can look at some ofthe major projects, where it has evidence of important failings, but itcannot report on every large IT-based project and programme. As it is,the Public Accounts Committee has trouble fitting in hearings on everyone of the 60 reports the NAO publishes each year.
Gatewayreviews of large and risky IT projects are obviously important – butcompliance with the recommendations of Gateway reviews isn’t mandatory.Even if it were, what sanctions could there be for non-compliance?
These weaknesses in scrutiny are against the backdrop of projectedincreases in spending by government, and most public service agreementtargets not being met: the 2009 budget projected an increase in government spendingfor 2010/11 from £671bn in 2009/10 to £701bn in 2010/11, an increase of4.5% in cash terms; and only 40% of public service agreement targetswere met for the three years up to 2008.
These are Matt’s comments:
“One of the key prerequisites for any agile/RAD approach is surelythe close involvement of key user representatives with the commitment,business knowledge and authority to say what they want the system todo.
“But this is one of the main areas where all government IT projectsfail: either people do not understand their own business processes wellenough, or they are actively out to undermine the project in fear fortheir own jobs, or they refuse to commit themselves to a decision, forfear of being held accountable if they get it wrong, or they hide theirown ignorance behind the idea that their requirements are uniquelycomplex and cannot be reduced to anything as crude as a clearly defineduse case.
“Then you have the fact that the usual consultancies … who are awarded these projects, are financially motivated tomaximise their earnings – and their potential ability to clean up onany outsourcing of the resulting system – by introducing unnecessarycomplexity, gold-plating bespoke solutions to requirements that couldbe met with off-the-shelf solutions, aiming for all-encompassing andcomplex “generic” solutions to cover multiple business processes thatnobody understands in the first place, and stuffing the project with asmany expensive “architects” as they can.
“On some projects, the response to this chaos is to introduceheavy-duty RUP-style “agile” methods in order to manage the processbetter, which simply add to the bureaucracy and introduce extrabarriers between users and developers, as well as effectivelyrepresenting a return to slow and bureaucratic ‘waterfall’ developmentbut without the rigour of older software engineering approaches.
“And of course it is in nobody’s interests to save money anyway,because the provider wants to make as much cash as they can, while thegovernment client (as reported elsewhere in CW) will lose clout inWhitehall if they stop spending so much on IT.
“So you often end up with a client who doesn’t know – or won’t say -what they want, dealing with a provider who doesn’t care what theclient wants or needs, because they’re going to deliver the mostcomplicated and expensive solution they can come up with anyway, andboth sides almost totally paralysed by bureaucracy, inertia and poorcommunication.
“And now that Whitehall is planning to increase direct UK taxpayersubsidies to the Indian IT industry by handing the pension systemcontract to TCS, which will shift most of the work offshore, doesanybody in their right mind think that communications betweengovernment clients and system providers are going to become any easier?Hardly a recipe for “agile” success, surely?”