Good Governance - Effective use of IT

Written evidence submitted by Andrew Hardie (IT 14)


The financial crisis and resulting budget cuts provide the strongest driver and best opportunity yet to shake up UK Public Sector ICT systems procurement, project management and operation.

Key topics and themes include:

· Decoupling of commodity infrastructure supply from the applications that run on them.

· Recognition that:

ICT procurement is very different from construction or commodities.

Public Sector ICT procurement is different from corporate.

Every ICT procurement is different.

· Contract frameworks must accept that change happens and support the agility to react.

· Smaller projects must be encouraged – fear of aggregation accusations must be removed.

· Obstacles to direct SME supply to Government must be reduced; the sub-contractor route is unsatisfactory, benefiting neither Government nor the SMEs.

· Focus must be shifted from compliance to capability and competence.

· Front-line users must be involved throughout the procurement and development process.

· Early and repeated testing of applications during development, not just for final acceptance.

· Integration is a two-edged sword – tightly coupled systems magnify and propagate faults.

· Equating connectivity and integration with inter-operability is a big mistake.

· The perspective on risk needs to be re-aligned; if suppliers can't 'price it in' or perceive it as too onerous they will walk away.

· Obsession with 'process' must replaced by leadership and innovation, in depth – ritualising procedures abolishes initiative and creativity.

· Similarly, excessive use of analytical 'methodologies' to create abstractions far removed from reality abolishes judgement and understanding.

· Realising that in most information systems the only really important factors are the users and the information they interact with via the applications; the rest is infrastructure.

· Project management must be more flexible, recognise human factors more and not just accept change but prepare for and enable it.

· There must be recognition that:

The more human-created software ICT systems incorporate, the less deterministic and more unpredictable they become.

The more systems depend on human-mediated content, the more sensitive they are to human behaviour – adding a sociological/ethnographic dimension.

ICT systems are installed in a context of vested interests, prejudice and fear.

· The most important document in a project is the one that describes the problem or requirement – preparing it requires experience and understanding. Fact gathering is not (indeed, almost never) enough. Requirements capture is a seriously undervalued skill.

· Competence development in procurement is essential, both for customers and vendors.

· Open Source Software is now 'best of breed' in many areas and its use should be positively encouraged.

Questions and Issues

How well is technology policy co-ordinated across Government?

(No comment)

How effective are its governance arrangements?

(No comment)

Have past lessons from NAO and OGC reviews about unsuccessful IT programmes been learnt and applied?

In addition to the NAO and OGC reports on ICT failures mentioned in the Issues and Questions paper, there have been many others examining large ICT projects in both public and private sectors. Perhaps, the best was the MPA (Major Projects Association) report from 2003, identifying the people issues that are at the heart of the problem, such as insufficient project agility, political pressures, insufficient team training and not listening to the people on the front line.

Yet, despite all these reports, failures continue. The question of why has become known as Cobb's Paradox: "We know why projects fail, we know how to prevent their failure – so why do they still fail?" The answers are less about technology and far more to do with the people involved, on all sides. Organisational learning in Government seems to remain a serious problem.

At the Project Management level, failures are often attributed to insufficiently rigorous enforcement of 'the plan' when, in fact, the problem was that the plan was too rigid and became overtaken by events. Project management must be more flexible, recognise human factors more and not just accept change but prepare for and enable it.

More widely, 'management by maxim', based on myths of linear reasoning and control, is another bad habit that needs changing. ICT systems development turns out to be more like gardening – it has to be nurtured and cultivated in a conducive environment; shouting at the plants achieves nothing.

The ritualisation of risk is yet another problem. Risk assessment, instead of involving in-depth thinking about systems during specification, development and in use, is frequently reduced to another box-ticking compliance exercise. Tabulating and claiming to have 'mitigated' a list of risks both ignores the risks that were not identified and, worse, fails to consider the second-order risks that arise from the attempts to manage the identified risks. The identified risks are then devalued by highly subjective estimates of probability and impact.

Furthermore, the simplistic model of "risk exposure = potential loss x probability of loss" is largely inappropriate for complex ICT systems because they have both deterministic computers and unpredictable human elements – analysts, programmers, integrators and users – and rely on human generated and mediated information.

How well is IT used in the design, delivery and improvement of public services?

The focus seems to be on cost-reduction by making business and citizens submit statutory information online instead of on paper. This may be laudable but it is not exactly Business Process Re-engineering. Efficiency and economy do not necessarily equate to better services.

It must also be accepted that public sector projects are not the same as corporate ones and that corporate techniques and solutions do not always translate to the public sector. In particular, the context of public sector projects is often very different, with high visibility, political issues, etc.

What role should IT play in a ‘post-bureaucratic age’?

In a word: enabling.

The truth is we are far from a post-bureaucratic age. Most Government online services are simply automated versions of existing processes – filling out forms online just relocates the typing. True, such processes can produce faster and more convenient results for citizens but truly innovative projects remain rare.

What skills does Government have and what are those it must develop in order to

acquire IT capability?

Since demise in the 1980s of the CCTA and its valuable advice to government, we have seen well-meaning initiatives such as smart procurement and intelligent customer come and go. The truth is that the big suppliers now have the upper hand in almost all areas.

In the past twenty years, the old civil service attitude of 'on tap but never on top' towards technical staff has been replaced by chronic undervaluing of their importance, steadfast refusal to pay market rate salaries for skills and, assisted by outsourcing and civil service fragmentation into agencies, ICT staff have relentlessly migrated to the private sector.

Rebuilding civil service technical, project management and procurement competence must be given the highest priority or it will be impossible to change the current situation, the big suppliers will continue to dominate and the failures will continue to happen.

How well do current procurement policies and practices work?

There have been some notable successes but the numerous high profile project and information governance failures have shaped the current climate.

There needs to be a recognition that the current procurement practices are unsatisfactory, especially for software-dominated projects. The way in which non-commodity software applications are specified and procured needs to change. The real users, not their management, must be involved from an early stage. The old-fashioned and widely discredited 'waterfall' development model must be replaced by an iterative model, with early and repeated testing of the applications during development, not just acceptance tests at the end of the procurement. This approach is widely and successfully used in the games software industry and often includes the '10% milestone', where an early version of the game is tested and, if the publisher doesn't like it, the rest of the project is cancelled. Incorporating that in Government procurement would be a major culture shock but it's better to lose 10% than 100% of contract value.

What infrastructure, data or other assets does government need to own, or to control directly, in order to make effective use of IT?

Government should own its own data and never have to pay to get back information created at public expense.

Government should also own those special-purpose applications developed at public expense and promote their reuse elsewhere in Government wherever possible. The trend towards commodity 'cloud' computing (sometimes referred to Software as a Service) facilitates this.

Almost all general ICT projects can now operate entirely on commodity equipment. Outsourcing of communications infrastructure is not only appropriate but to be encouraged, especially where competition for bandwidth and quality of service can be embedded. Workstations and departmental networks are now 'commodity' products that should be regarded more like furniture and electricity. The trend to virtualisation and 'cloud' has shown that back-end server systems can be commodities as well although issues of information management – in the widest sense – in the cloud context are far from being resolved. Virtual network routers are an exciting new development, further assisting 'on demand' resource provision.

This separation between commodity infrastructure and the applications should extend to the procurements, with contracts for infrastructure and applications handled separately. The focus must be on the applications to run on the out-sourced, commodity back-end systems, networks and workstations. There is no reason why these applications cannot be a mix of government-developed and owned, rented (in the sense of pay-per-use or pay-per-user) and free (Open Source) software.

How will public sector IT adapt to the new ‘age of austerity’?

Hopefully by, at last, being forced to 'think small'. It is ten years since the OECD called for "dolphins not whales" in a plea for smaller projects when they warned of the "hidden danger to e-Government" caused by over-large ICT projects (Ref 1), cautioning that they "should be avoided wherever possible". Yet, it seems that the lessons have still not been learnt. The ‘goldfish memory’ of public sector ICT procurement persists along with the high-profile disasters.

Perhaps, the greatest fallacy in both government and private sector ICT systems implementation is that greater systems integration is the answer. It isn't. The more tightly you couple ICT (or, indeed, any) systems together, the greater the speed, range and impact of problems and side-effects become and the harder it is to change the resulting monolithic systems, precisely at the time when ever greater agility is needed. Look what havoc tightly-coupled financial systems wrought on the global economy – a 'Black Swan', low probability, high impact event that cannot be extrapolated from past experience, no matter how elaborate or rigorous your project governance. Increasing integration also brings risks of supplier lockin.

It is the author's assertion that "the answer to many stovepipes is not one new stovepipe". The touchstone for any contemplated ICT system must be 'would it scale to the Internet?'. The Internet does not depend on commonality or tight integration. Instead it is a loosely-coupled network of compatible (not common) devices and systems of widely varying ages and capabilities, yet it works and works well. Over-specifying and trying to over-standardise are common mistakes.

The Internet, or more specifically Web, model of distributed, non-cooperating applications also points the way out of the stovepipe trap. High street retailers solved the problem of uneconomic, over-sized department stores by adopting the 'shop within in a shop' concept allowing flexible response to changing market conditions. The Web, in a way, does the same by decoupling big infrastructure (Internet and the Web) from service delivery (Web applications) which can be developed, deployed and updated rapidly. 'App-stores' are just the latest manifestation of this trend. The more new Government applications are specified and developed as entirely Web-based, the better.

Another popular fallacy is the 'strategic alignment' of ICT systems development with the organisation's strategy goals. This notion, long promoted in the fashionable management press, is in practice unachievable and attempting to follow it is counter-productive. What is needed instead is a framework that provides flexible resources that can adapt quickly to changes in the organisation and outside. Virtualised and commodity systems are ideally suited to these needs – it's just the management perspective that remains to be changed. Simply using virtualised systems to replace physical systems is wasting their real advantage - agility.

How well does Government take advantage of new technological developments and external expertise?

It seems that Government mostly does not, except where it suits the large suppliers to offer it. But, this cannot be considered surprising in a procurement climate that discriminates so heavily against the traditionally innovative SME sector. The complaints from the SME sector about the obstacles to winning public sector business must be listened to and acted upon.

Through bitter experience as a director of an SME in the 1980s, the author can confirm that partnering with or sub-contracting to large corporations is not always the best way to gain a foothold in Government markets. This was the era of routine late payment by large suppliers to their sub-contractors and the prompt payment by Government to those SMEs who did manage to secure direct business kept many of them alive during the various financial crises of the 1980s.

Large corporations often try to conceal the SME’s contribution, especially if it is innovative, so as to prevent the SME building a reputation for that might one day undermine the large corporation’s own market. If the SME is cost-effective, then the large supplier can simply pad their margin to avoid embarrassing comparisons with their own pricing structure.

In the current financial crisis, the large ICT corporations may have even less incentive to partner with SMEs, as they to try to maximise retained revenue in an effort to prevent further downsizing. It is also questionable if placing large contracts with large multinational corporations is the best way of tacking the UK’s economic crisis, as the multinationals may simply repatriate the profits to suit their global debt picture or to profit from currency movements.

What is needed is a simple, cost-free way of SMEs presenting their products, services and capabilities to the whole of government and an easy way for orders to be placed. The suffocating bureaucracy, obsessed with compliance not capability or competence has to be swept aside.

Furthermore, 'blue-sky' research and experimental ICT systems projects must be encouraged and the results publicised. Much innovation arises from creative people just 'playing about'. ICT departments in Government should be allowed and encouraged to 'play' with ideas and new developments in the context of their organisation's needs, which they will understand better than any supplier.

Similarly, pilot projects must be treated for what they really are, an experiment. Growing pilot projects on into full-scale deployments is wrong, as is trying to conceal the results of pilot projects perceived as having 'negative results'. Those are not failures but successful demonstrations that something doesn't work or is inappropriate and should be welcomed and learned from.

Lastly, the contribution that Open Source Software (OSS) can make to Government ICT projects must be promoted. Many OSS packages are now the 'best of breed' available and run large parts of the Internet and corporate systems. Everyone using email, the Web or a mobile phone is, unwittingly, using numerous OSS applications every day.

How appropriate is the Government’s existing approach to information security, information assurance and privacy?

The HMRC disk loss was a defining moment – an 'event horizon' – in UK government ICT. Senior civil servants, always cautious about the career risk of being involved with or responsible for major ICT projects, now not only don't want to take ownership the problems, they don't want to own the solutions either in case they backfire. It has skewed the whole perspective on information assurance and risk.

The truth is that all public sector project risk ultimately reverts to the Government – this, along with universal service obligations, are the two biggest differences between public and private sector ICT projects. Yet, the passion for trying to outsource risk persists along with the almost pathetic obsession with having a single, incontrovertible contractual point of blame. The result, unsurprisingly, is a distorted market in which only the largest suppliers can operate and thus do so largely according to their own wishes, including ignoring or withdrawing from projects they don't like and taking on projects that initially are unprofitable, in the expectation that downstream changes will bring the profits. The parallel with major corporate or sovereign debt, where the debtor effectively controls the lender, is depressingly striking.

At the information management policy level, the work EURIM is doing in this area is particularly valuable and I commend it to the Committee.

How well does the UK compare to other countries with regard to government procurement and application of IT systems?

Research conducted by Dunleavy et al into public sector ICT procurement (Ref 2) in the major economies found that the country doing this best was Holland, where they are not afraid to break large projects down into smaller parts, despite the possible accusations of aggregation the UK seems paranoid about. Better guidance and a more pragmatic interpretation of the spirit of the procurement rules is sorely needed – the 'gold-plating' of the letter of the rules we have now simply disadvantages the UK.

But, there’s a snag: splitting big projects into smaller ones and managing their implementation and interoperation requires government to be an intelligent customer – you can’t just hand off the whole problem to a supplier.



1. The Hidden Threat to E-Government
- Avoiding large government IT failures

, Puma Policy Brief No 8, March 2001 (http://www.
oecd .org/data oecd /19/12/1901677.pdf)

2. "Digital Era Governance" , Dunleavy et al, Oxford University Press, 2006

Author background

Further information about the author and papers relating to the topics discussed here can be found at:

January 2011