ACM Interactions

Governments are increasingly providing services and information to the public through information and communication technologies (ICTs). There are many benefits to providing information and services through ICTs. People who are looking for government-related information can find it much more quickly. Government agencies can update websites more easily than paper documents. Those taking advantage of government services through ICTs can save time and frustration, which often accompany waiting in line at government agencies. Further, government agencies can save resources when transactions can be handled automatically. In addition, ICTs for internal government use have the potential of helping manage large amounts of information and handle processes more efficiently.

In spite of the promises of e-government, there have been several notorious failures in the implementation of e-government systems. The most recent example in the United States was the website for applying for health insurance under the Affordable Care Act (also known as Obamacare). The website was not usable by a significant portion of users when it launched. This is only the latest example of an e-government system that does not work as planned and requires additional resources to be functional (if it is not completely scrapped). These challenges have occurred across different administrations, and with different political parties in power. In the United States, historic examples include the Federal Aviation Administration’s air traffic control software, and the Federal Bureau of Investigation’s Virtual Case File [1]. Dada [2] provides examples of e-government failures in lower-income countries.

These failures tend to stem from the difficulty in following modern software engineering and user-centered design methods when contracting with companies for the development of ICTs. These modern methods call for iterative processes of development with significant stakeholder input and feedback. There is an expectation, for example, that detailed requirements will be developed over time, and that some may change. Typical government contracting for ICTs, on the other hand, often assumes that government employees, oftentimes without any training in software engineering, will be able to deliver an accurate set of requirements to a company that will then build a system with little or no feedback from stakeholders during the development process.

The challenge is that an overwhelming majority of elected officials and political appointees have little or no knowledge of software engineering or user-centered design methods. Even people responsible for ICTs at government agencies may not have any specific training in these methods. It is rare, for example, for government agencies to usability test competing technologies before deciding which one to purchase. 

I saw this first-hand while I worked at the U.S. Census Bureau. At the time, the Census Bureau was planning to use handheld devices to conduct the 2010 Census. In spite of the significant investment to be made, no one in the leadership was familiar with software engineering or user-centered design methods, and they trusted the management of the process to employees with some background in ICTs, but no training or experience in handling projects of such magnitude, and little knowledge of appropriate methods. This resulted in the development of a set of requirements that no one understood, and that came largely from long-time employees, with no feedback or consideration for the fact that those who would use the system would be temporary employees. While there was some involvement of usability professionals in the process it was “too little, too late” and did not have an impact on the methods used. The requirements were turned over to a contractor, and a test of the resulting software resulting in the need to change more than 400 requirements. The project had to be scrapped after spending almost $600 million on the contractor (not counting the resources spent in-house), and meant that the Census Bureau had to spend an extra $3 billion in processing paper forms that would have been unnecessary had the software been successfully developed.

So how can we help? HCI researchers and professionals can contribute to public policy by informing elected officials and the leadership at government agencies of the methods that are most likely to result in usable and useful government ICTs that can be developed on time and within a given budget. This, in turn, can inform how government contracts for the development of ICTs are structured, such that they require iterative processes with a significant amount of stakeholder feedback. If these methods are followed, government agencies stand to save resources, and deliver better quality ICTs. This is an area where ACM, SIGCHI, and other professional associations could play a role. If we don’t do it, no one else will.

Endnotes

1. Charette, R.N. Why software fails? IEEE Spectrum 42, 9 (2005), 42-49.

2. Dada, D. The failure of e-government in developing countries: A literature review. The Electronic Journal of Information Systems in Developing Countries 26, 7 (2006), 1-10.

Juan Hourcade