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 that Whitehall organisation is a variation of anarchy, shouldn't there be more external and independent scrutiny of the billions spent each year on government IT?
The National Audit Office can look at some of the major projects, where it has evidence of important failings, but it cannot report on every large IT-based project and programme. As it is, the Public Accounts Committee has trouble fitting in hearings on every one of the 60 reports the NAO publishes each year.
Gateway reviews of large and risky IT projects are obviously important - but compliance 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 projected increases in spending by government, and most public service agreement targets not being met: the 2009 budget projected an increase in government spending for 2010/11 from £671bn in 2009/10 to £701bn in 2010/11, an increase of 4.5% in cash terms; and only 40% of public service agreement targets were met for the three years up to 2008.
These are Matt's comments:
"One of the key prerequisites for any agile/RAD approach is surely the close involvement of key user representatives with the commitment, business knowledge and authority to say what they want the system to do.
"But this is one of the main areas where all government IT projects fail: either people do not understand their own business processes well enough, or they are actively out to undermine the project in fear for their own jobs, or they refuse to commit themselves to a decision, for fear of being held accountable if they get it wrong, or they hide their own ignorance behind the idea that their requirements are uniquely complex and cannot be reduced to anything as crude as a clearly defined use case.
"Then you have the fact that the usual consultancies ... who are awarded these projects, are financially motivated to maximise their earnings - and their potential ability to clean up on any outsourcing of the resulting system - by introducing unnecessary complexity, gold-plating bespoke solutions to requirements that could be met with off-the-shelf solutions, aiming for all-encompassing and complex "generic" solutions to cover multiple business processes that nobody understands in the first place, and stuffing the project with as many expensive "architects" as they can.
"On some projects, the response to this chaos is to introduce heavy-duty RUP-style "agile" methods in order to manage the process better, which simply add to the bureaucracy and introduce extra barriers between users and developers, as well as effectively representing a return to slow and bureaucratic 'waterfall' development but 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 the government client (as reported elsewhere in CW) will lose clout in Whitehall 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 the client wants or needs, because they're going to deliver the most complicated and expensive solution they can come up with anyway, and both sides almost totally paralysed by bureaucracy, inertia and poor communication.
"And now that Whitehall is planning to increase direct UK taxpayer subsidies to the Indian IT industry by handing the pension system contract to TCS, which will shift most of the work offshore, does anybody in their right mind think that communications between government clients and system providers are going to become any easier? Hardly a recipe for "agile" success, surely?"
Subscribe to blog feed
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.