Too many destructive vested interests in Govt IT?

In response to the article on this blog by Rob Bowley, on whether Agile can help solve Government IT problems,  Matt writes:

“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?”

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Agile is a methodology that clearly will drive future application development. It is vital for not just getting it right but to engage the end user to ensure the embedded business processes belong to them. The current dictatorial approach by either vendors and their powerful ecosystems or procurement is doomed to see government failures continue.

However there is the stage beyond agile as a methodology to software technology that is agile. This capability already exists and will effectively eliminate software failure. The core code never changes with no code generation or compiling. It allows great flexibility both in build and subsequent change ensuring any investment is future proof. Indeed it is so flexible it even changes the initial specification to a much slimmer exercise in so much that it is not necessary to be complete as build is iterative with change now an expected requirement. The build is remains under control of the business analyst working with users removing any interpretation gap.

This agile software is a game changing step in the evolution of business software. An example a recent Government contract sent offshore to build at £50m changes into a max £5m build locally, so no more offshoring application development. This new technology will allow focus on better use of specialist business consultants and remove reliance non contributing senior managers and procurement people. With so many vested interests this is the real challenge as is the Government needing to become the intelligent buyer. But the old game is up as there are too many people now demanding change.

Rob Bowley and Matt’s comments have troubled me a great deal. Putting aside for one moment any sense of what is realistic, how would I feel if Agile became a magic cure-all for managing the complex relationship between Government and vendor? What if projects were suddenly delivered on time and to budget so that there were no more PAC recommendations or NAO reports talking about degrees of mismanagement and civil service obfuscation? Would I feel re-assured knowing that Government spend was now finally under control because a methodology had arrived that had the degree of flexibility to take the burden of responsibility away from Government departments?

I’m a layman when it comes to Government IT projects. I had an interest in the subject and suddenly found myself writing about it for my MBA. I find the topic pretty fascinating really and perhaps rather strangely I now find that I am quite attached to those regular NAO publications. I genuinely believe that I would miss them if they weren’t there anymore and I also think that I’d probably worry about that even more still. That’s because I believe that the core causes that created the project slippages and the massive budget overruns would still be there, albeit may they be ever so slightly hidden behind a clever piece of modern thinking. So by all means give me the right answers and tell me that Government has delivered successful IT projects on time and to budget utilising Agile, but, I will forevermore want to be able see (as clearly as they will let me), how it was that they actually managed to get there. The right answer won’t be enough I’m afraid, I’ll still expect Government to ‘show its working-out’ too.

I think the main points of this discussion are valid. Public sector IT is complex by design, to disguise the underlying motivations of those involved. The public sector and their suppliers are locked in an unspoken marriage of convenience, where the real goals are of mutual benefit to them and not to us as end users and taxpayers. Approaches like Extreme Programming and Scrum require more simplicity and transparency than the key beneficiaries would ever be prepared to subject themselves to. The real solution is to remove public sector IT from the hands of the civil service and their partners in crime in the private sector completely, I think. Real end users (hospitals, schools, job centres etc) must be allowed to commission software directly and solutions must be targeted directly to their needs with systems developed by suppliers that are geared up for - and incentivised to - doing exactly that. The "enterprise architecture" of government can be better and more economically achieved through open standards of interoperability and opportunistic and evidence-based reuse than through enormous, monolithic, "one-size-fits-all" solutions.