Introduction

Are government computer projects different?

Size – Government systems are often intended to serve large populations with millions of people.  This means that the system often handle a huge amount of data.

One-Offs – Because government applications tend to be unique, they are often forced to create their own system rather than purchase ready-made ones.

Complexity – The systems that governments create are often based on complex legislation that is built up over years.  When combined with the requirements necessary to put them in operation, the result is a system of incredible complexity.

Very long development timescale – The large scale on which government operates, and the slow speed at which they effect changes, mean that the development of computer systems is usually protracted.

Very high cost – With all the factors mentioned above – size, custom built applications, complexity, and long time scale – government systems can’t help but command a very high price tag.

The US IRS Tax System modernization project is a key example that illustrates these differences.  Since its inception in 1986, the IRS has been engaged in this project to create a fully automated and modernized tax-processing system.  Between 1986-1990 the IRS spent $80 million on the projected.  The project is expected to have a final cost of $23 billion and last until the year 2008.

The process of building the large and complex information systems required by governments is often very different from the development of most commercial systems.  Some of the factors include:
 

1. Technology-led -- There is a tendency for government information systems to be technology-led rather than oriented towards satisfying the needs of the users and the public it is intended to serve.

2. Low-Cost Solution not sought – The preference for the solution that make use of the leading – edge technologies within government projects indicates that there may be a tendency to adopt high-cost approaches to systems, rather than low-cost solution.

3. Custom system rather than packaged solutions preferred – Because of the unique nature of many core governmental information systems, there is a tendency to assume that all government systems require a custom rather than a packaged solution.

4. Short-term tenure of managers overseeing projects – Continuity of the management overseeing large information systems developments is essential.  However, management charges occur frequently in government projects, with adverse effects on the project.

5. Priorities may be refocused – Changes in government policies that occur during the development of a system can cause a shift in focus.

6. Imposition of external deadlines – The effective date for changes in government policies, which are usually selected for political reasons, are often the deadlines by which information systems must be operational.

7. Highly bureaucratic decision-making processes – The Bureaucratic decision-making process in government is probably good for the accountability of public funds.  However, such level of bureaucracy often creates organizational structures unsuited for the effective management of information systems projects.

8. High-level of public interest and oversight – Government projects are carried out in the public arena surrounded by a level of interest and public access unknown in commercial developments.

In 1992, the General Accounting office of the US produced a summary report of problems with government computer projects.   The top four problems identified were:
 

a) Inadequate management of information systems lifecycle.

b) Ineffective oversight and control of Information Resources Management (IRM).

c) Cost overturns

d) Schedule delays

These problems, along with the other factors mentioned above, are illustrated in a brief review of three recent information systems projects:  The Wessex RISP System and The Field System in the UK, and the Veterans System in the United States.  These projects represent different types of computer projects, planned at different times by different governments, in different countries.  However, similar mistakes were made and similar lessons can be learned from each project.
 

The Wessex Regional Information Systems Plan (RISP)

At the time of the RISP development, Wessex Regional Health Authority was responsibility for the provision of healthcare for a major part of southern England.  The regional Health Authority (RHA) was divided into ten Districts that provided healthcare for its local area.

The RISP project evolved from a decision to develop an information system strategy that would cover all information requirements within the entire Wessex RHA. The project was adopted in 1984 with its aim being: “to use modern technology in order to optimize the use of information in the continuing improvement of the effectiveness and efficiency of clinical and other health services.”  The main point of the plan were:
 

• The development of five major systems (accountancy, Personnel, Hospital, Estate & Community) in every district.

• Development to be completed in five years

• Integration of existing systems, where possible

• RISP was to be developed centrally by Wessex RHA.

There were many problems within the RISP development.  During the development external auditors presented a series of reports that were critical of various aspects of the project. No significant action was taken to correct these problems. For example, on numerous occasions it was evident that there was conflict of interest in the procurement process.  For example, Digital Equipment Corporation (DEC) was selected out of five proposals to supply hardware for the project.  Then, Anderson Consulting /IBM consortion, one of the losing bidders, was appointed to advise on Software for the DEC based system.  Ultimately, Anderson consulting/IBM ended up with the contract for both hardware and software.

There was also lack of a clear definition of the scope of RISP.  As a result there, were difficulties in budgeting and controlling expenditure of the project.  The official estimate for the project was between £24 to 33 million ($36-50 million).  However, the internal unofficial estimate was that the project would cost not less that £80 million ($120 million).

RISP was a technology-led project that was pursued even though there were practical evidence that it was not working out.  It was reported that within Wessex senior management there was near obsessional belief in RISP.  It was evident that a full project plan was never developed and that many of the projects were authorized on an ad-hoc basis.  There was also poor supervision of the consultants, who basically managed the entire project.

RISP was abandoned in 1990, five years after it started.  By this time £43 million ($64.5 million) had been spent on the project, £20 million ($30 million) of which was wasted.  There was only partial implementation of three of the five core systems.  In the end, Wessex RHA still did not have the information system that they perceived as essential to the effective management of their operation.
 

The Field System

Plans for The Field Systems (TFS) stemmed from a 1988 review by the Department of Employment into the systems operating within its regional offices.  The decision was made to replace the five stand-alone systems that had evolved over the years with a single integrated system.  It was expected that the new system would supply the needs of each field office, be more usable, and provide better-quality information to improve decision making.  TFS was to be implemented between June 1990 and April 1992.  Development of TFS for the field offices was already underway when government announced the establishment of TECs.  The TECs were commercial organizations, independent of the government, that were to assume the work of the Department of Employment’s field offices.

The business case prepared for TFS was seriously flawed.  It assumed that it was necessary to provide the News TECs with a common information system rather that allow them to determine their own needs.  The prudent approach at this point would have been to allowed the TECs to begin their operations with manual systems until they were in a position to determine their own needs.   Instead, the Department decided to adapt the Field System already under development.  The Business case for TFS ignored the following risks:
 

• The information needs of both the TECs and the Department were likely to change during development.

• The information need of the TECs would have to be defined by the Department.

• The information needs would likely be different between TEC.

• The number of TECs was unknown.

• The rate of establishment of TECs was also unknown

• TFS would need to be ready six months earlier than originally planned.

An external consultant commissioned to review the project reported that the plans were over-ambitious and of doubtful feasibility given all the risks.   They also found that the personnel assigned to the project lacked the experience essential to the management of a project of this scale.

Inspite of those reports, development continued.  Due to the lack of user involvement, the users needs were not met, because they were never clearly defined.  There was ineffective testing and early versions of the software were released with a large number of errors.  The TECs reported that the system was slow, cumbersome and not user friendly.  Of the 71 TECs, most were not using all the facilities of the system, and six were not using it al all, having preferred to purchase their own system.

An external review of TFS done in September 1992 by the National Audit Office found that many of the TECs intended to reduce reliance on the system or replace it within a year.  In that same month the Department of Employment announced it would withdraw from the Field System.  The Field System had three key deficiencies that contributed to its failure: it was not subjected to rigorous and realistic risk assessment, it did not have the best possible user involvement from the outset, and it did not have effective project management.
 

Veterans Benefits Administration

The VBA is part of the US Department of Veteran Affairs (VA) and is responsible for the distribution of non-medical benefits to approximately 27 million veterans and their dependants.  In 1991, the VBA handed over 3.5 million compensation and pension (C & P) claims.  By the end of 80’s the VBA’s existing mainframe computer system could no longer fully support all the VBA’s program.  Consequently, the VBA embarked upon a modernization project to replace its existing system with a decentralized system that integrates all information about a veteran.  This would enable claims to be processed more quickly.  The VBS also expected to improve the services it offered through the use of document imaging, workflow systems and expert systems.  The VBA’s Information Resources Management (IRM) office was to lead the project, and design and development would run in parallel to the acquisition of hardware and software.

The GAO review of the VBA’s modernization plans found that it was flawed in numerous ways.  First, it was a technology led project.  VBA had planned to purchase hardware and software before their information architecture or information requirements were defined.  Second, their current business process was poorly understood.  The major part of the work of the VBA is processing claims related to C & P, with the average claim taking 151 days to process.  The VBA’s IRM Office attributed the delays to the paper based system and expected to reduce the delays with the use of an imaging system linked to workflow software.  However, a GAO study showed that 55 percent of the time to process a claim was taken up in waiting for someone to work on the claim.  Therefore, the proposed plan would result in only marginal improvements of 6 to 12 days.  Third, the goals of the system were unclear.  The VBA has not outlined any specific levels of service to be achieved nor had any performance indicators been established.  Finally, there was poor communication between those responsible for creating the new system, (the IRM office) and the C&P managers who were to use it.  The C&P managers did not see how the new system would address their business problems and believed that the IRM office was acquiring technology solutions without regard to their needs.

The GOA recommended that the VBA postpone the procurement of any hardware or software under the modernization scheme, until all the major flaws were addresses.
 

Lessons from Government Computer Projects

Organizational Lessons

Project Lessons

System Failure – What can be learned?

CFFs may be useful in providing a set cautionary pointers to those involved in IS development.  They can help managers quickly to identify troubled projects and enable them to take appropriate remedial actions.  CFFs that are in less than optimal state will increase the chance of an IS development becoming either a failure or a disaster.
 

Conclusion

References