Ulrike Rivett, Melissa Loudon
Most e-Government projects end either in partial or total failure . When the reasons for this are investigated, we are told that systems have failed because they try to force unwanted or contentious change in organizational processes, or because the technology requirements, such as hardware and connectivity, did not exist or were not maintainable due to limited human, technical, and financial resources. In general the literature on information and communication technology failure suggests that failure occurs because some aspect of the system contextsocial, technical, or politicalis inadequately understood.
While such reasons are valid, our view is that the stubborn persistence of this failure in the government sector hints at a broader systemic problem. The technological “ecosystem” in its current formfrom technologies, implementation, and development processes to research and teachingdoes not provide adequate support to public-sector projects.
As researchers, designers, and professionals how can we orient our work to promote success in e-Government? Our experience with two e-Government projects in South AfricaCellLife and Aquatestmay provide an answer.
Cell-Life and the iDART System
Cell-Life started in 2001 as a research collaboration between staff of the engineering faculty of the University of Cape Town and the Cape Peninsula University of Technology (CPUT). As the prevalence of HIV grew, it became clear that the primary health sector would need extensive support, particularly in under-resourced and rural areas. Cell-Life investigated the use of readily available technologies (particularly mobile phones) to support the provision and distribution of medication, continuous patient monitoring, and the communication of relevant administrative and evaluation data. Our research focus was the development of appropriate tools in new settingsfor example, a large-scale rollout of antiretroviral drugs, which have strict compliance and treatment-education requirementsas well as understanding work processes and information flow.
In 2006 Cell-Life became a not-for-profit organization and was spun out of the University of Cape Town. This coincided with a shift in focus from being primarily a research organization to a mix of research and implementation support, prompted partly by the growing number of sites using the software. For example, iDART, a pharmacy management system for government clinics dispensing antiretroviral drugs (ARVs), currently manages the dispensation of ARVs to approximately 110,000 patients, representing one-sixth of South Africans on state- or donor-sponsored antiretroviral treatment (ART).
Mobile Phones and Drinking-Water Quality: The Aquatest Project
Aquatest is an international collaboration to develop a low-cost water test for the developing world. Our work in the project involves investigating the potential uses of mobile phones in drinking-water quality monitoring, including communicating test results and providing emergency warning and follow-up in case of water-quality problems. Like the earlier projects at Cell-Life, this is undertaken as a participatory action research, with functional prototype software being developed, used, and evaluated in iterative and incremental process.
Particular emphasis has been placed on supporting evaluation and design by software users themselves. To do this, we are using unstructured narrative interviews (“tell me a story of how you have been using the system”) and actively and opportunistically soliciting input into the concept and design of software features. Currently there are four local municipalities participating in the project, with about 35 municipal foremen, environmental health professionals, and community borehole caretakers reporting water-test results on a regular basis.
E-Government Projects as Communities of Practice
To sustain momentum through the entire life cycle of public-sector projects, diverse groups need to be involved from an early stage. In addition to immediate target users, multiple levels of government must be involved to ensure the current project is understood in relation to other systems and likely policy directions. Where aspects of the system are new, or where stakeholders’ exposure to implementation of technology is limited, a research group may be better placed than a private company to initiate the design process. Even so, early engagement with the private sector is vital to establish support and viability beyond the exploratory stage. Business, government, and academia operate on differing assumptions, often with quite different worldviews and ways to work together.
The concept of communities of practicegroups whose common interest and regular interaction result in shared learningprovides a lever to understanding success in multistakeholder e-Government projects. Productive engagement takes time; relationships must be built, and trust is established slowly in diverse groups. Thinking about e-Government projects as communities of practice rather than as individual contracts acknowledges the necessity of long timelines. It also guides us to prioritize activities that help members develop a shared understanding of their goals, and the work they must do to achieve them. Crucially, we need to move away from a situation in which the reality of financing is based on delivering a one-size-fits-all system, which assumes a homogeneous user base.
Developing communities of practice in e-Government requires a far wider range of expertise than is found within the disciplinary boundaries of information systems and computer science. The notion of expertise is in itself limited. Rather, our role as researchers is to engage with other stakeholders in a continuously evolving process.
Research in a Learning Community
Academic work on failed e-Government projects is often highly critical, particularly where questions of expenditure and returns are concerned. This may be useful in terms of accountability (although perhaps not, given the persistence of expensive and contentious failures), but it does little to promote mutually influential relationships between researchers and policy makers. Researchers’ interpretations of cases can be unhelpful in the constricted world of government policy, which in turn fosters negative perceptions of the potential contribution of academic research. Long-running projects that build relationships, and in which the researcher has a stake in delivering a solution that works for all participants, may provide more useful incentives in this regard.
To accomplish this, a shift is required: away from a closed system of expertise, with the researcher as the expert and research participants as subjects, to open collaboration and co-ownership of the research process. In the same way that participatory design democratizes the design process, our aim is to democratize the setting of the goals in the first place. Instead of setting the agenda, deciding on the survey methodologies and post-processing research data using analytical tools, the emphasis would move to a shared learning approachthis fundamental shift results in any one party giving up control and becoming a facilitator rather than a “principal investigator.” It also requires that the attitude of extracting information from a research subject becomes an engaging attitude that results in benefiting both the researcher and the community.
Just-in-Time Design and Development
Working as part of a community is an unusual experience. Developers, schooled as technical experts, must accept guidance by people whose perspectives are often profoundly different from theirs. Users, whose previous experience with ICTs has usually been as passive recipients, need to work with concepts that are often poorly defined or explained. They must also balance their involvement with existing work responsibilities.
In resource-strapped government departments, there is little time for dedicated user-feedback sessions. This has led us to use a technology-probe approach in which we create working prototypes that allow users to form opinions based on actual experience of the system. These in turn can feed into iteratively revised design. Where software users experience the system as malleable, they are more likely to provide constructive feedback on changes to the initial design. For many of the passive users, it comes as a shock just how malleable the technology can be.
In providing high-fidelity technology probes, we find that interesting solutions are given space to appear. For example, one of the borehole caretakers involved in the Aquatest project is visually impaired and has difficulty sending test results via SMS. His solution is to ask his school-age daughter to type the messages for him. In the same project, supervisors initially used a Web interface to view results but elected to start collecting data directlypreferring to simply receive an SMS with the results of tests taken at the boreholes. This system has worked so well that the SMS system, initially an interim measure at best, is now seen as the more important data output. Without a “just in time” technology-probe approach to system design, these kinds of solutions are almost always overlooked.
Similarly, designers and developers who have spent time with system users, soliciting feedback with a mandate to respond to and explore their needs, have become an important proxy for users in prioritizing problem areas. This is a balancing act and can be difficult to maintain against considerations of scale. In the iDART project, for example, pressure to make small, individually requested changes to the system to protect personal relationships combined with the need to maintain the technical integrity of the code base and to align development priorities with funding all places significant strain on the development team. At the same time, relationships have immense value in building and maintaining communities of practice, which can sustain learning far beyond the software itself. In short, building the community of practice can be more important than software-engineering imperatives.
Teaching for e-Government Success
Developing communities of practice in e-Government requires a far wider range of expertise than is found within the disciplinary boundaries of information systems and computer science. The notion of expertise is in itself limited. Rather, our role as researchers is to engage with other stakeholders in a continuously evolving process. Accordingly, we need to reconsider the skill set of researchers and practitioners. This means reviewing what is currently taught, as well as taking critical consideration of areas in which disciplinary boundaries are limited in their ability to promote socially responsive approaches.
A dose of realism is important here. Attempts to redefine curricula based on local needs face immense barriers, not least in the attitudes of students. The term “world-class” epitomizes the pressure on educators to keep up with global advances, regardless of what is most appropriate in the local context. Accreditation processes, which specify fixed requirements for curriculum content, impose additional limitations. Fortunately, our experience has been that students who are exposed to socially responsive research, even in a small way, often continue to incorporate a development orientation in future work.
E-Government projects are prone to fail, and do so expensively. It is the shared responsibility of ICT professionals and governments to cultivate an environment that promotes success. Doing this requires taking a broad view of the ecosystem, encompassing but also looking beyond issues of design and implementation. The model of an e-Government project as a community of practice can help us to think differently about who should participate and how a supportive environment for a system develops. Expertise, whether as a researcher or designer, is not always an appropriate mode of engagement, and finished products are less likely to reveal interesting local adaptations than malleable ones. If the role of universities is to serve the public good, sensitizing students to the development potential of their field is also extremely valuable, and an investment for success in years to come.
1. Heeks, R. “Success and Failure Rates of eGovernment in Developing/Transitional Countries: Overview.” eGovernment for Development. http://www.egov4dev.org/sfoverview.htm/
Ulrike Rivett originally studied land surveying in Munich. She has been in South Africa since 1995 and is today an associate professor in spatial data management in civil engineering at UCT. She was one of the founders of Cell-Life and is the principal investigator of the Aquatest team in South Africa. Rivett has learned the assumption of e-Government research should always be that the government is not necessarily responsible for its failure.
Melissa Loudon is a research officer in Spatial Data Management at the University of Cape Town, where she works on the Aquatest project. From 2006 to 2007, she was a software developer at Cell-Life.
©2010 ACM 1072-5220/10/0700 $10.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2010 ACM, Inc.