By Tony Collins
Something has to change says Ian Magee, a former senior civil servant, in the forward of a report published today “System Error – fixing the flaws in government IT”.
“The Coalition’s plans are wide-ranging, and demanding of innovative and inventive solutions,” says Magee. “It is clear that something has to change: government IT cannot be stuck in a time warp, when all around, commercial organisations are responding to very similar imperatives.”
The report is published by the Institute of Government which is hosting an event in London this evening to discuss its findings. One of the speakers will be Ian Watmore, Government Chief Operating Officer and Head of the Cabinet Office’s Efficiency and Reform Group.
The report has two main solutions to problems with government IT:
i) an “Agile” approach to IT projects, which delivers working software within weeks, not months or years. Agile is modular and incremental with an emphasis on simplicity, business people and developers working closely on a daily basis, code being adapted regularly according to changing circumstances, self-organising teams, and an acceptance of regular failures that cost little because problems are caught early, before they fester and become costly or unaffordable to fix.
The traditional approach in government is the more rigid “Waterfall” or the “V-model” in which specifications are drawn up in advance, ‘solutions’ are bought, and delivery is managed against a pre-set timetable. Critics say that by the time Waterfall projects are completed, if ever, what is delivered may be what users specified but is no longer what they need or want.
ii) Platform – a government-wide approach to simplifying elements of IT. The aim of the “platform” is to bear down on costs, reduce duplication and establish standards. The focus is on “commodity procurement, coordinating delivery of common IT facilities and services, and setting common and open standards to support interoperability”.
The report accepts that Agile and “Platform” are not without problems.
Agile needs close co-operation between potential users and developers – which is time-consuming for users and demands a big commitment from their employers. The report says that the three most significant barriers to the adoption of agile are the ability to change organisational culture, general resistance to change, and the availability of personnel with necessary skills.
The platform approach “does not imply a large re-centralisation of government IT”, says the report. But there has to be some central control and possibly mandation.
“Because of its complex structure, government faces particular challenges around authority and accountability. Crucially, the centre must be able to establish which elements of government IT are part of the platform and manage compliance.
“The Government CIO should impose a strong ‘comply or explain’ model, with a clear escalation process up to the Public Expenditure Cabinet Committee where necessary.” The Committee has the power to withdraw money from departmental projects.
The Institute’s 100-page report is authoritative, sensibly nuanced and is recommended reading for anyone who has an interest in government IT. Its case studies on Agile projects are convincing, largely because they include the “barriers” – the problems encountered.
Also, few independent reports have had input from such a range of IT luminaries including John Keeling, Director for Computer Services at John Lewis Partnership, David Lister, CIO at National Grid, Bill McLuggage, Deputy Government CIO, John Suffolk, former Government CIO and Annette Vernon who has held various CIO positions in government.
Eighteen out of the 25 CIO members of the government’s CIO Council completed a survey for the report.
In his forward, Ian Magee has a useful summary of government IT problems and he has enough passion in his advocacy of Agile to inspire people to want to try it.
Magee should know his stuff: he was CEO of the Information Technology Services Agency which handled benefit systems for the DSS, now the Department for Work and Pensions. He was also second Permanent Secretary at the Department for Constitutional Affairs is now a senior fellow at the Institute for Government.
Some quotes from the report:
“There is a well-documented history of too many high-profile and costly failures. This is rarely the fault of the underpinning technology: policy complexity, late additions to already-long lists of requirements; inadequate change management processes; and a failure to bring users fully in to the picture, all play their part.
“… the plain fact is that problems continue, despite forceful recommendations from powerful groups about how to improve the process so that government does better.”
The flaws in government IT.
“Numerous reports and articles have pointed to a long list of problems: chronic project delays; suppliers failing to deliver on their contractual commitments; not designing with the user in mind; divergent costs for simple commodity items; incompatible systems; the high cost of making even basic changes; ‘gold-plating’ IT solutions; and failing to reuse existing investments.
“Moreover, there is a critical dependence on legacy systems, and the need to deal with interoperability between these systems increases cost and complexity.
“These problems have been widely rehearsed but proved stubbornly resistant to change. This is because government’s approach to IT is fundamentally flawed for our times.”
Waterfall and V-model.
“Traditional linear IT project approaches, like the V-model and Waterfall, assume that the world works in a rational and predictable fashion. Specifications are drawn up in advance, ‘solutions’ are procured, and then delivery is managed against a pre-determined timetable.
“In reality, priorities change rapidly and technological development is increasingly unpredictable and non-linear. Most government IT therefore remains trapped in an outdated model, which attempts to lock project requirements up-front and then proceeds at a glacial pace. The result is repeated system-wide failure.
“Ironically, in areas where it may make sense to lock down choices, such as the procurement of commodity items or the implementation of common standards, government struggles. The strong departmental lines of accountability mean that while many government IT professionals recognise these issues, no one has the mandate to tackle them.”
When failure is a good thing.
“While many commentators like to focus on the failure rates of government IT projects this can be misleading. ‘Failure’ can be very useful if it is the result of experimentation and innovation that helps systems to learn and improve.
“… the real problem is that too many government IT failures occur on a massive scale and are only recognised as failures late into the process. There is no doubt that government IT is currently failing, and not in a good way.
On “departmentalism”.
Currently, strong departmentalism is a major factor in preventing a more joined-up and efficient approach to many elements of government IT. Yet the answer is not simply to revert back to centralisation. The key is to stop lurching reactively between extremes and simply continuing the power struggle between departments and the centre (an issue which goes well beyond IT).
Failure built into the system?
“By planning and designing in as much detail as possible at the outset, showing exactly how everything fits together, the number of errors discovered in the later test phases are reduced.
“In a perfectly predictable world these approaches would work very well. In the real world, in which requirements, technologies and ministerial priorities are constantly evolving, they quite literally build failure in to the system.
On outsourcing government IT and other work:
“Increasing outsourcing may also have reinforced this tendency: a preference for fixed price work, with the full set of requirements agreed at the start and steep penalties for alterations, creates contractual and financial barriers to making changes.
“This single window for requirements leads business users to request any and all functionality that they think they might want rather than focus on their core needs.
“Suppliers rarely have an incentive to question the validity of requirements. Additional complexity enables them to command bigger fees; the greater the specialisation of a system, the more likely suppliers’ knowledge of the system will be called on to maintain or update the system…
“By outsourcing a large part of government IT, the public sector has also lost much of the knowledge and skills required for it to act as an intelligent customer. It has become unable to judge objectively whether it is getting a good deal from suppliers, especially as the siloed nature of government make it difficult to obtain comparative figures for reference.
“Working with suppliers who lack insider knowledge of the department also means that the requirements have had to be specified in a greater level of detail to try and prevent requirements being ‘lost in translation’.”
On massive projects:
The resulting excess of requirements, combined with the desire to fully use all the potential of technological solutions on offer, has led the public sector to design larger, more complicated solutions than might be necessary.
On Gateway reviews:
“As the Gateway review seeks to fix problems rather than stop projects, this runs directly counter to an agile approach, which allows projects to fail small and fail fast.
“While there is an important role to be played by an independent governmental review process, the Gateway process should be reviewed by the Cabinet Office to ensure that it can accommodate agile projects.”
The Institute for Government report – System Errors – fixing the flaws in government IT
Campaign4Change 