Tuesday 15 September 2015

Why can’t government IT systems be more like supermarkets?

Despite the rapid diffusion of ICTs and the internet generally and the increasing
use of networked systems in the public sector known as eGovernment, the failure of some of these systems continues to dominate the news in the sector. Last year in the UK, the British government axed a new e-borders system, with a cost to the taxpayer of £224m. But that was small change compared to the abandoned National Health Service (NHS) patients’ record system, which in 2013 lost nearly £10 billion.
The UK government’s current IT-based benefit flagship, Universal Credit, has been beset with enough problems to keep those of us who keep a critical eye on these things tutting into our coffee for years to come and although not all the problems there are IT-related, the other problems identified by the National Audit Office (2014), including poor management and a ‘bunker mentality’, have meant that the whole project has had to be ‘reset’, which means the design and implementation of the IT system has been significantly overhauled – and you can imagine the bill for that.
So is the failure of these ambitious projects inevitable? Some studies show that the rate of total or partial failure of eGovernment systems in some economies is as high as 85% (Heeks, 2006). These failures are costly in the obvious economic sense but equally costly in terms of citizen’s trust in their governments’ ability to implement the kinds of systems that the private sector seems to have no problem with (‘if supermarkets can do it, why can’t the NHS?’ etc etc).
So what’s the problem? Why are eGovernment projects abandoned with eye-popping write-off costs with such regularity? And does anything actually go well, despite the headlines? The answer to that is of course, but success rarely makes good news copy. There are many examples of eGovernment systems in place that offer a number of benefits for citizens and governments alike. Simple examples such as the ability to apply for licences and permits or pay taxes and fees online in general work well and save citizens and agencies time and money. Efficiency gains such as removing the need to attend government offices during office hours means that citizens can navigate some forms of bureaucracy more conveniently and, in some cases, removing human interaction can even reduce mid and low-level corruption.
One could argue that these transaction-based systems compare well to private sector systems such as online shops and financial services which enjoy relatively high acceptance (take-up) rates amongst consumers; some studies show that between 50-66% of people with access to the web use it for some kind of financial transaction (Horrigan, 2008, Ofcom, 2011), with electronic cash transfers in some countries enjoying parallel success: For example, 65% of households in Kenya use a mobile phone-based cash transfer system (Jack and Suri, 2011), a pattern that is seeing similar success in other sub-Saharan countries.
But the problems occur with systems that are designed to process and manage a more complex range of variables, systems which often have to retrieve this data from existing ‘legacy’ (old) systems and which, by their very nature, require new ways of thinking about and working with this data. Business processes that worked fine on a range of unconnected electronic and paper-based systems may need to be re-engineered to fit the new world and this then becomes a project that is as much about people as it is about technology. Re-engineering these systems often means navigating complex and ever-changing hierarchies and stakeholder groups. Add to that the political drivers to outsource the work and push for an urgent roll out and you can see the iceberg ahead.
Technology is only a part of a ‘complex adaptive system’ that includes people, processes, politics and all the usual complexities of organised human life and understanding that seems to be the key to understanding eGovernment ‘success’. Only the very naïve (or pathologically optimistic neo-liberal) would suggest that government IT systems are comparable to supermarkets but I can’t help wondering why, when there is so much research in this area now, governments continue to make the same mistakes. The National Audit Office (2014) notes that the ‘reset’ Universal Credit project will be rolled out with a less ambitious timetable, with stable leadership, with more control of suppliers and with an incremental ‘test and learn’ approach to the process. I do wonder though if political ambition might thwart this promise. I will be watching with interest, coffee in hand.


Heeks, R, (2006) Implementing and Managing eGovernment: an International Text, London, Sage.
Horrigan, J, (2008) ‘Online shopping, Pew Internet and American Life Project Report’, available http://www.goldminenetwork.com/_did_you_know_online_shopping.pdf,  accessed 1st September 2015.
Jack, W and Suir, T (2011) ‘Mobile money: The economics of M-PESA’, NBER working paper No. 16721, available http://www.nber.org/papers/w16721, accessed 9th April 2015.
NAO, (2014) ‘Universal credit: progress update’, available at http://www.nao.org.uk/wp-content/uploads/2014/11/Universal-Credit-progress-update.pdf, accessed 1st September 2015.
Ofcom (2011) ‘Internet use and attitudes’, http://stakeholders.ofcom.org.uk/binaries/research/media-literacy/media-lit11/internet_use _2011.pdf, accessed 1st September 2015.


Jane Lund teaches on the online Masters programmes in Public Policy and Management in the Department of Social Policy and Social Work at the University of York. She has a keen interest in eGovernment and eLearning. 

4 comments:

  1. Back in the early 2000's I got so frustrated with the failure of big IT projects that I wrote “The problems of software development” (Now found here:http://www.brusselsblog.co.uk/the-problems-of-software-development/) Some key bits:

    Project Size

    A key factor that has been identified in the failure of software projects is sheer size. A more recent article in Software Magazine by Jim Johnson, chairman of the Standish Group saysviii “Most of these new [successful] projects are well within The Standish Group’s criteria established in “Recipe for Success, 1998,” which limits project duration to six months and  project staff to six people.

    Plans and Specifications

    The problem here is that it is all but impossible for a large software project to be planned in a way that enables the final product can be clearly seen.

    The Power of an Incumbent Supplier

    [Having a large project that has apparently clear objectives for which a fixed payment is how the procurement process is conceived.] The problem with the approach is that, once a contractor has been accepted, that contractor often becomes a monopoly supplier. The more important the project is to the customer, the more power is given to the contractor. He benefits by being locked into the project.

    Resolving the Specification Problem

    --First, we must abandon reliance upon the requirement for full initial specification. It does not and cannot work.

    --Second there must be a rapport between the customer and the developing product itself. Given the complexities inherent in translating real world requirements into a computer program, every effort should be made to remove all impediments in the process of communication.

    --Third, there must in place of an initial “up-front” specification be a continuous dialogue between the customer and the provider. It is only in this way that the fuzzy edge of real-world requirements can be fitted to the structure of a computer program.

    Punch line

    Try a few small partial prototypes and build on the ones that work and use a procurement method that can cope with this approach.

    P.S. The lessons of the Marshmallow Challenge apply. https://www.ted.com/talks/tom_wujec_build_a_tower

    P.P.S. I did ring up the development people at the NHS at the time to warn them.

    ReplyDelete
    Replies
    1. Thanks Geoff, I enjoyed your comments (and congrats on boldly contacting the NHS!) and agree that up front specs should be seen as a starting point, not an end point. The research literature concurs with much of what you say here and I can also see the value of seeing these systems as part of a much bigger 'system' , a complex adaptive system which helps us to understand the importance of the soft aspects of system design (ie. the wetware, us) and how the interaction between individuals and groups are non-linear and rich, making it unwise to develop 'closed' systems in response. So your dialogue between provider and customer, I would suggest, needs to see the 'customer' as the entire human system in which the IT will be situated. I like your small prototype approach! (I couldn't find your blog post - has it moved?)
      Jane

      Delete
  2. This comment has been removed by the author.

    ReplyDelete
  3. And yes, building big government IT systems is a wicked messy problem.

    ReplyDelete