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.
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:
ReplyDeleteProject 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.
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?)
DeleteJane
This comment has been removed by the author.
ReplyDeleteAnd yes, building big government IT systems is a wicked messy problem.
ReplyDelete