Information and Communications Technology for Development (ICT4D) - A Design Challenge?

In this paper, we make the case that ICT projects in the developed and developing world often lead to partial or total failures due to the incomplete assessment of the problem being solved and the metrics used to evaluate solutions. While in the developed world the success of ICT solutions are often determined by the market, with available infrastructure and market mechanisms, in the developing world this ecosystem does not exist thus requiring an understanding of the ecosystem in which ICT solutions are to be applied. Using literature from the design space, and experiences in ICT for development, we elaborate the dimensions of design such as incorporation of stakeholders, incentive structures, and design participation that are critical to successful deployment. We examine some successes and failures in product/solution development in the ICT area to identify the dimensions of good design incorporated by these products and services. With the perspective that ICT for sustainable development issues are ill-structured and "wicked problems" that have to incorporate all the defined dimensions of design, we propose a model of product and service identification and development that is based on insights from asynchronous computational agent problem solving. We claim that new methods such as the one proposed need to be identified, developed and tested for their effectiveness in the development of products and services that satisfy the needs of human development


I. INTRODUCTION
Information and Communications Technologies (ICT) have become a new tool in the path towards development, one that has garnered increasing visibility (but also hype). The old debate of bread vs. computers has moved from competition towards complementarity. 1 However, many of the discussions have focused on narrow interpretations of the "digital divide" and the full scope of ICT, spanning new embedded devices or sensors, databases, and algorithms, has not been developed to meet human development needs. Like the fable about the five blind men describing an elephant, ICT and development has often been looked at in parts. There are various technological and operational components that go into design of these development initiatives. There are multiple stakeholders, some of whom may be indirect. There are different innovators and solution providers, sometimes focusing on only one aspect of solution. There are different contexts and frameworks for development, including regulations and funding. The varying stakeholders may also have different objectives, incentives, metrics for success, and initial conditions. Until all of these are considered in a holistic manner, as an ecosystem, the full potential of ICT for development will remain elusive, and many projects will fail.
We posit that if development is the desired goal, stakeholders' incentives and metrics must closely align. This means that worrying about ICT price-performance is not suitable as a standalone metric, nor complementary metrics such as throughput or even scalability/replicability. 2 These are all important components of any solution, but global metrics must be focused on the intended beneficiaries or end-users, in whom we should look for development benefits.
The ill-defined nature of ICT for development (ICT4D) complicates the space significantly, and much of the literature is ad-hoc or anecdotal. In this paper, we frame ICT4D as a design problem, and use several cases to analyze failures and successes. We analyze these cases in terms of asymmetries of information in terms of inclusion of stakeholders, poor design processes and misaligned incentives mechanisms. These failures reflect the inability to solve the right problem of needs of development and a technology driven tendency to solve the wrong problem optimally, as is often the case in many design problems [2].
Following sections of this paper go through the issues of stakeholders, metrics, incentives, and design, followed by select case studies. We subsequently present a new ICT4D model, based on commonalities and shortcomings gleaned from the case studies and literature.

A. Defining Stakeholders -Divides in ICT4D
At a high level, the stakeholders can be thought of as: • Development beneficiaries (general or targeted population) • Development / Services providers (government, utilities, NGOs, commercial entities) • ICT developers and providers (commercial, nonprofits, entrepreneurs) • Funding entities, regulators, purveyors or enforcers of social/legal norms Inherently, many of the targeted beneficiaries are "disconnected" from the mainstream. The underserved lack not only physical connectivity but social or political avenues for participation. This is has been a major challenge in not only meeting their needs but also in bringing them to the table in development projects.
There is mixed evidence regarding democracy and development [3], but studies have shown that order and accountability are strong determinants of development [4]. Democracy itself has limitations when it comes to development, not necessarily in theory but certainly in practice stemming from bureaucracy, segmented disempowerment, factionalism, etc. India is considered a vibrant democracy, and China has much more authoritarian control, but there are significantly fewer people lacking basic human needs in (a measure of "development") than in India. For example, over 98% of Chinese have in-home electricity [5], but in India almost half of homes are not connected to the electricity grid [6]; the authors indicate governmental policies are a prime factor for such variance. This disconnect extends to the limits of using markets and market signals to spur new solutions-many people are outside markets, let alone efficient markets. DeSoto [7] argues that the informal economy and lack of liquidity towards formal economic systems limits participation and empowerment of the underprivileged. Cobb and Daly [8] refer to economics especially suffering from a "Fallacy of misplaced concreteness" because of issues with markets, measurements, human rationality, and resources. In ICTD, there is a parallel tendency to assume that the main challenges are developing the "optimal solutions" at the "right cost." The term "digital divide" is popular to describe divides between groups of people, but this is recognized by many as being a symptom of underlying divides and of capabilities, not merely differences between "haves vs. have nots." [9] Unfortunately, a (narrow) focus on the digital divide has distracted if not hijacked many ICT4D efforts. Bringing a computer into poor, rural areas is unlikely to help education significantly, at least not on its own. But such projects garner significant media attention and funding. The real space of development is vast, spanning infrastructure, food, healthcare, education, economic growth/jobs, governance, and empowerment.
Another divide in the ICT4D space is that between ICT professionals and development professionals. 3 Heeks [10] argues that ICTs may or may not be relevant to the Millennium Development Goals (MDGs), and the MDGs themselves must be examined critically. On the other hand, Tongia, et. al [9] conjecture that ICT can help with the MDGs or at least development broadly if we think of alternatively designed technologies and solutions than today, in short advocating innovation and new R&D and not trickle-down. Today, development professionals rarely interact with ICT R&D professionals; at best they know of select technologies that are available today. However, given the dramatic speed of technological innovation in ICT, there is especially greater need for interactions by development professionals and endusers to help guide ICT R&D. This divide often parallels a geographic divide, termed East/West or North/South. A third divide exists in ICT4D between different groupings of stakeholders: academics, industry, government, funding groups (which may not be the government), field professionals (including NGOs), and targeted beneficiaries. For starters, the users of the ICT-based solutions may not be the desired end-beneficiaries; NGOs often play the role of intermediary, required given literacy and logistical constraints amongst much of the population. Funding groups often have statutory or charter constraints, and they often seek "visible solutions" that limit longer-term ICT4D solutions that are not readily deployable. Industry is often pushing solutions driven by "market" expectations, which may be understandable given their shareholder obligations. Work recognizing the bottom (or, the more politically correctly, "base") of the pyramid as an untapped market [11] has not yet resulted in major, fundamental innovations by the ICT industry, though they are working on improving the size, scale, costs, and robustness of their offerings. Academia is often accused of acting in a vacuum (the "ivory tower"), and limited scholarly analysis of ICT4D works self-limit the short-term value of academic research. Academia also suffers from time lag issues, in that many rigorous studies require data over time series, and the publication and dissemination process itself can take 1-2 years. 4 In the middle, you have the governments, who ostensibly have a development focus. While there are a variety of responses and roles governments have taken in this space, from being a consumer of ICT, spurring R&D, setting legislation and regulations, deploying e-Governance programs, etc., given limited government budgets and ICT skills, it is unlikely they can be more than an enabler for other stakeholders.
These divides are important when we remember that ICT4D is a work in progress, with substantial innovation and effort required to achieve development goals. Many experts believe the true needs of development require not all-purpose computers per se, which are powerful but expensive, but specialized ICT devices to meet specific needs, e.g., soil condition monitoring or a biomedical "lab on a chip." There are limited "off the shelf" solutions, and the need for customizing the ICT solutions for specific classes of needs is central. The need to balance cost, usability, scalability, maintainability, recyclability and relatively long life cycle of the solution becomes critical in the context of development.
Without the understanding of the overall ecosystems of the product operation, the products will often fail, and such an understanding is not achieved through isolation of the technologists from the people for whom solutions are targeted.

B. Incentive structures
ICT usage in development is a means, and not an end. ICT may or may not be cost-effective on its own (e.g., saving transaction or transportation costs) but it may improve development outcomes in non-monetized forms. It may be more straightforward to account for ICT costs benefits only in direct monetized terms, but on such grounds, it may fail in terms of opportunity costs. For example, a dollar spent on distributing condoms may have hundreds of dollars of return (disease and unwanted pregnancy prevention); ICT for healthcare is unlikely to produce such returns. However, ICT infrastructure would have multiple benefits, usable across many development themes. One challenge is of determining appropriate boundaries and transactions between stakeholders and beneficiaries, especially as we straddle the public and private domains. For this reason, the government is often cited as an appropriate shepherd for, say, ICT infrastructure. However, many professionals feel it is best for the government to step in only in specific cases where there are issues of size, scale, or market failures, as was the case in rural electrification in the developed world. Governments, especially developing country ones, are also not going to innovate at the cutting edge of ICT; their role is more one of diffusion and deployment.
Easterly [13] posits that (lack of) incentives are a key reason for failure of development projects, and externally imposed solutions are predisposed to failure. If we consider ICT4D, some consumer products have been successful specifically because consumers are able to "vote with their wallets." However, the incentive (or barriers) to innovate in fundamental technology creation is not the same as that for service provisioning or deployment. In addition, if we consider the 4Cs of ICT (computers, content, connectivity and (human) capacity), different components have different barriers to entry and profitability. Mobile phone providers in the US routinely give away free handsets in return for annual contracts. Google, Yahoo, Microsoft, etc., make an enormous number of services available online for free. Of course, they make their money from advertisements, product tie-ins, and paid versions with enhanced services. However, if we consider ICT usage for development, e.g., e-Governance programs, similar models would likely face troubling privacy implications, equity concerns, and potential conflicts of interest.

C. Metrics
Stakeholder goals can be in explicit or implicit conflict; a cheaper product may mean lower profits for a supplier. Classical economics labels equilibrium points where no stakeholder would change their position (price, quantity, etc.) as being Pareto optimal (any one's improvement results in a deterioration of utility for the other(s)). As is known Paretooptimality does not necessarily produce a just solution as it depends on initial endowments of the stakeholders.
Even if we have a common goal, with aligned incentives, we must determine what is or isn't failure outside of the Pareto nature of the solution. Heeks [14] segments projects as total failures, partial failures (goals partially met, unintended consequences, or sustainability challenges) or successes. ICT4D projects often lack rigorous analysis or metrics, not to mention baselines, and without analyses that move beyond the level of case studies, it is difficult to obtain a clearer picture. This is further complicated by ICT4D being a dynamic process, with goals that can not only shift over time, but also are inherently dependent on the goals of stakeholders and their ability to participate in defining the right development problem to be solved. In the rural US, the digital divide has moved from merely accessing the Internet (widely available through dial-up) to having broadband. Consumer groups and municipalities interested in providing broadband have often been restricted due to regulatory statutes that confer a monopoly or rights of first provision to the incumbent service provider. An additional challenge in metrics is one of granularity; most data (and even analysis) are based on national numbers -this says nothing about, say, rural or region-specific deployment. Indian Government data indicate teledensity approaching 10%, but this is based on urban penetrations approaching 30%, and rural penetrations under 2%.
ICTs find greater use in developed regions, often for use outside the traditional "ICT4D" moniker. Heeks [14] states that there is no evidence or theory why failures would be higher in developing countries, but we conjecture there may greater failures in developing regions be because: (1) ICT is not just an incremental improvement in efficiency, but can represent or catalyze enormous social shifts; (2) Infrastructure is worse developed; (3) Complementary institutions are less developed (courts/rule of law, regulators, etc.); (4) stakeholders have lower familiarity with the solutions; (5) the initial conditions (baselines) are often worse.
In spite of these, there are still many failures in ICT projects in developed regions, largely because of design issues. Examples include the iridium satellite constellation, which failed as a business venture, or the deployment of customer relations management (CRM) solutions by enterprises. In the latter, roughly 80% of projects fail or are over budget and/or over time [15], largely because of hidden or unbudgeted (secondary) costs.

III. ICT4D INNOVATION CHALLENGES
The traditional model of R&D as a sequence of steps is one of generating a number of ideas from large scale and expensive fundamental research that is detached from end uses, and then adaptation of the research to needs by isolated inventors leading to marketing and adoption of products through the early adopters and subsequent diffusion. von Hippel [16] in his studies of product innovation makes the case that the users are often the leading innovators as they are the ones who understand their particular needs and their inclusion removes the information asymmetry that inherently exists between the technologist and the user. This asymmetry extends beyond the user-technologists divide but also the social and political context in which the product is expected to operate.
There is a widespread belief that fundamental research is expensive and risky, with many steps of potential failure, because of the serialized model of innovation that is assumed in the current models of R&D. Thus, "big R&D" is best left to national labs or well-funded groups, who may (pharmaceuticals) or may not (bell labs, CERN) be aiming to appropriate their innovation. On the other hand, innovation in the ICT4D space has several components beyond just devices; the 4C framework spans Computers (devices); Connectivity; Content, and (human) Capacity. While the capabilities in building a mobile phone may be with only a handful of entities, creating content or human capacity is certainly within the scope of many stakeholders. Even device and network innovations are possible at the edge, e.g., through community wireless mesh networks using ~$50 commodity wireless routers for city-wide networks (1-4 per sq. km) [17]. 5 However, when we consider ICT for specific development needs, e.g., the so-termed medical "lab on a chip," such new solutions will require fundamental advances in technology, which translates to extensive R&D. Given the long lead times and risks inherent in such innovation, how do we classify what are important problems in the ICT4D space? Several scholars have advocated determining the "Grand Challenges" of the space, but this will not be as easy as, say, in Computer Science. Not only is the field nascent, there is the need to integrate various stakeholders operating under different assumptions, thresholds, and initial conditions.

A. ICT4D Innovation -Trickle Down, Watered Down, or Upside Down?
Generalizing ICT innovation is difficult if not impossible, given the range of the ICT space (the 4Cs). However, there are several commonalities seen in ICT usage in development scenarios. One mode is trickle down, where solutions from developed countries make their way to developing regions over some period of time. PCs, mobile phones, or digital cameras are common examples, where everyone benefits from continuous innovation, and the volumes initially came from developed countries. Trickle down solutions may or may not also have reduced feature sets or functionality. Part of this may be driven by cost differentials, but part of this is driven by market segmentation and a desire not to cannibalize more profitable markets. Microsoft's Windows Starter Edition is a useful portfolio expansion at a more affordable price, about an order of magnitude lower than full versions, but it is ironic that it cost extra money to "innovate" to reduce its features and functionality versus the normal Windows XP. 5 Even after adding in antennae, weatherproofing, etc., such systems can be as low as ~$100/node. Computers can find good use in many developing regions, often in educational institutions or some businesses. However, visit any government office in developing countries, and one may also find a PC in the office, especially if the official is senior. However, what applications are running? Is it more than a glorified typewriter? Is the machine networked, (and if so, used for more than reading the sports score)? Backed up? Until the end-user and related stakeholders are involved in the ICT decision making process, ICT's use or integration will be limited.
Can we turn the innovation framework upside down, with user needs driving innovation and design? For this, we must start with a clearer understanding of the needs space, as well as understanding the ICT space overall, itself a complex ecosystem with hardware, software, content, connectivity, access/usability, maintenance, security and other components.

B. Design, Participatory Design and Open Standards
In engineering of products, we have seen over the last century and a half a complete cycle in the understanding of how products should be designed. We have moved from products often designed by the user for the user, and often manufactured by the user in the world of artisans, to the world of mass manufacturing where designer, manufacturer and users were divided as sequential actors in the process of product creation and use. The failures during use by early users were the impetus for product refinement, and mass usage goals drove mass production. The sequential model of product design was challenged in the 80s and 90s by movements such as concurrent engineering and simultaneous engineering [18]. In ICT field the incorporation of user in design was defined as user centered engineering [19]. However, many of the goals of incorporating user requirements and preferences were within the framework of Human-Computer Interaction (HCI) design, which relates to human usage factors instead of human needs driving ICT design. The supplier still has a mental model of what the need is, and works to optimize the delivery of such needs.
These trends were due to the recognition of existence of information asymmetries in the product design process as a purely top-down process. The limitations of the top-down processes have become apparent in the globalized world where accommodation of variation in customer needs and social context is important to success. This can be seen in every aspect of product design both in physical and information products [20] and hence the move by even technology companies like Intel to employ anthropologists and sociologists to understand cultural contexts of use for generic technologies [21]. While these are a clear indication of the acknowledgement of information asymmetries in the product development arena the question remains are there general methods for addressing these information asymmetries for design of products and solutions, especially those that are directed at development?
The banner of participatory design and the involvement of the user in design has emerged as a mantra in the product 6 design area. In many cases, while this participation may be limited, it has provided a means to limit uncertainty in the adoption of the product. von Hippel [16] has advocated for larger participation of the user either directly or indirectly through user representatives who become translators and bridges to overcome information asymmetry. Such models for product design have found use in select contexts, often in high-cost products such as commercial aircraft design; userdriven specialized design in fields such as pharmaceutical or high tech industries are less common. In his work on democratizing innovation, von Hippel makes the case that participation should be extended as innovation is often local and user driven, e.g., in the case of surfboards and irrigation systems. In many cases the users create these innovations due to the lack of commercial products to satisfy their needs. This is not surprising because as Petroski [22] points out innovations take place by design and as recognition of failures by the products that are in the market or non-existence of the same. Importantly, innovators are not often these large conglomerates but the users themselves. It is in this context that Reich et.al [23] argue for exploring varieties of participation in design and the use of ICT in the participation process itself.
The participatory model of product design attempts to addresses the information asymmetries identified by von Hippel as the basis for his case for democratizing innovation. The overall social cost of not addressing these asymmetries at early stages of design reveal themselves in costly adaptation and adoption processes by the users. Engineering design studies indicate that 70% costs of product development are committed in the design stage of the product whereas the cost of the design stage accounts for 5% of the overall costs of product development. It has also been observed that changes later in the product design are an order of magnitude more expensive than changes during the early part of design [24]. Early and continuous feedback from all the stakeholders is critical to the success of the design of a product. The goal of participatory design is to recognize that communication among the stakeholders early and frequently is the key to successful products.
Free/Libre Open Source Software (FLOSS, aka FOSS-sans Libre) is one popular example of participatory design, and is considered a useful ICT model for developing countries. There are pros and cons to FLOSS solutions, with the latter especially based on steep learning curves for adopters (total costs of ownership, instead of just upfront), limited local availability of specialized talent, and also limits to how such software can be used in proprietary solutions. We must also recognize that true end-users (e.g., in the development space) are very unlikely to guide the design of FLOSS, except in niche solutions where the end-users are IT savvy. In reality, FLOSS solutions have a relatively small core group of designers and system architects. A parallel and perhaps more useful development has been the emergence of open standards, which may not be user driven but are driven by select stakeholders, often competing. The WiFi specification (based on IEEE's 802.11 standard) is a good example of open standards driving innovation (often as a means of differentiation) and cost reduction. In under 10 years, the solutions have fallen in cost two orders of magnitude, and the speeds have increased 52 times.
In the ICT and development space, we can already see the split in innovation, where end-users often innovate around deployment, applications, and business models (e.g., Grameen Phone), while designers innovate to expand their market (e.g., rugged PCs). Our initial analysis indicates that the link between users and fundamental design will not be bridged all the way in the short term, rather across some layers only. Hardware will still be expensive to design, but once designed, many products will become closer to a commodity. They will also be more modular and expandable, often via software or firmware. An example of this is the use of commodity WiFi chipsets in inexpensive wireless routers that are sometimes "hacked" by end-users with new embedded software (firmware) to enable community mesh networks [17].

IV. DIMENSIONS OF ICT4D DESIGN
Based on the notion of ICT4D being primarily a design challenge, distilling from our experiences and those found in literature, below are characteristics or markers we need to consider for "good" designs. Naturally, there are tradeoffs involved. In the IT world, a common adage is "Cheaper, faster, better -pick any two" (derived from NASA usage). Solutions that can "revolutionize the world" or lead to dramatic improvements are more prone to failure, but smaller projects, which may indeed significantly improve local conditions or provide incremental benefits, may not be applicable across wider or different areas. Some of the best examples of ICT based solutions are those with very low barriers to entry or usage-the solution can spread by word of mouth, almost "virally." Skype, the VoIP solution, was such an example. It typically has 4-5+ million concurrent users online and the software has been downloaded over 220 million times. 7 Metrics do not necessarily mean a cost-benefit calculus, let alone a positive one. Some projects are true experiments, e.g., studying the user adoption rates for new technologies, where there is no expectation of cost-effectiveness. However, even in such cases, chosen metrics must be stated up front to determine "success" or effectiveness.

V. CASE EXAMPLES OF ICT, DEVELOPMENT, AND INNOVATION
Given the ICT4D design outline, we present case examples of some ICT projects especially as applied to development. These are shown not as full case studies but to convey select design aspects; some of these are ongoing or even proposed solutions. Table I summarizes these cases in the ICT4D Design Outline.

A. Mobiles and the Digital Divide
Mobile phones are a runaway success, especially in developing countries. Landline growths are only a few percent per annum, but mobiles have grown by an order of magnitude more, and, e.g., African mobiles teledensity is now ~10% [25] from nearly zero a few years ago.
Mobiles clearly filled a need, for people to communicate and share information, and they responded by spending a fair amount of their income on this solution. Mobiles' average 2003-04 revenues per user (ARPU) in Africa were ~$25/month, approaching the average income [26]. This was more than double the ARPU in India. Of course, average numbers are misleading, a major shortcoming of most studies of the digital divide. E.g., both income and infrastructure availability are concentrated in urban or richer areas.
Mobiles grew in part due to technology improvements, but also because they were offered by efficient and (often) competitive operators. Most initial African deployments (per country) were by private operators, who had almost no waiting list. In addition, the innovation to use a pre-paid card overcame financial credit limitations. The mobile phone replaced desire for a landline as it could be used at home, work, and on the road -a single device sufficed. Mobiles were easy to use, with the design overcoming end-user limitations of literacy, education or infrastructure. We posit mobiles also succeeded in that they were not an interim solution, or watered down from developed country solutions (often, they leapfrogged ahead). Under the 4C framework, ease of use by end-users can be framed in terms of contentanyone can produce as well as consume content, unlike the Internet where even skilled, literate users are more likely to be consumers than producers.
Mobile phones provide value to users. Studies show an increased 0.6% GDP growth rate for every 10% higher mobile penetration [27]. But this is correlation, not causalityperhaps operators picked the more economically favorable regions for deployment?
Moving beyond voice, there are mixed results for extending mobiles to other uses. If we consider use of mobiles for data connectivity, the bandwidth is limited, claims of 3G wireless systems notwithstanding, and the costs are very high. 8 Alternative wireless and community networking solutions may be superior, but need regulatory approval. The problem is one where the mobile operators in developing countries have become the equivalent of the landline incumbents in developed countries, entities who want to restrict competition and aim to expand into new services, often relying on weak regulations. Such limits on new entrants are reinforced by the incumbent carrier also typically having control over key aspects of connectivity, such as the international gateway.
Other needs for which mobiles are considered a possible solution or facilitator include inexpensive financial transactions. But the countries that lead in "mobile wallet" deployments are Japan, Korea, and W. European countries, where the back-end (banking) system is well developed. In contrast, in many developing countries, informal banking systems are the norm, and the postal system handles more savings than any other traditional bank; e.g., in India it has ~$85 billion in deposits [28]. 9 While mobiles can and do work for economic transactions, they are a closed system, 10 requiring the active participation of the mobile provider to enable the system and the transactions (indeed, the mobile provider may be taking a cut from all the transactions). A more open but still trusted solution, even using mobiles, might grow faster.

B. ICT for Education
Knowledge relates to education in fundamental ways, and information can be considered a stepping stone towards knowledge. ICT for education is fundamentally about content, and one of the unspoken goals is to mitigate the unavailability of teachers in developing regions. Due to limited interconnectivity, most ICT for education has not been realtime interactive, relying either on unidirectional broadcasts (including TV) or content on a CD or disk (nicknamed "broadband by station wagon").
EduSat is the Indian governmental initiative to use satellite connectivity for interactive ICT education. 11 It is driven the by Indian Space Research Organization (ISRO), and enjoys significant central government support. However, it is unclear to what extent teachers have been integrated into the schema. In addition, on a price-performance basis, the scheme appears wanting. Satellite connectivity is inherently expensive, especially if we want high bandwidth bi-directionally. ISRO states the capital cost per school to connect will be ~$3,800/interactive node, excluding computers or A/V equipment that can cost more, a very high barrier to scaling.
One Laptop Per Child (OLPC, formerly the $100 Laptop) is MIT's Prof. Negroponte's vision for a cheap computer for education. 12 It is geared towards developing countries, with a hand crank for power and mesh-based connectivity options. However, like EduSat, it appears to be a top-down solution, to be sold (on a non-profit basis) to Ministries of Education in a minimum order size of 1,000,000 units. 13 While standardization has its advantages, it also limits the ability to iterate. This also represents a major barrier to adoption in poorer regions, where per-primary student (not capita) education expenditures can be ~$20/year or lower. How much of the cost reduction is due to innovations, and how much due to the non-profit status (and attendant "free" innovation from co-developers), and how much from the economies of volume? There have been other critiques of this model as well, including the physics of battery charging based on a crank aimed for a 1:6 charging:usage ratio [29]. 14 In addition, the mesh-networking itself is a new design that may not work as well without line of sight, and certainly requires neighboring nodes to be on simultaneously (affecting power requirements). Of course, at some point nearby, there needs to be a viable uplink to the Internet.
Will the hardware last in hot, humid, dusty, and generally unprotected environments? Ruggedness is part of the design, and calculators certainly are robust, but they are built for less continuous usage. More importantly, they are built as closed systems. OLPC systems are designed to be interactive, with new content and interconnectedness. What happens when there is a virus loaded onto the OLPC? Who creates (and controls) content? The OLPC is visionary (with real innovation in the display proposed), and if it performs as advertised, at $100, many people in richer communities will want one. 15 But what problem is it solving, where, and for whom?
The problems of ICT and education are deeper than content (un)availability, extending to teachers, funding, and value of education in society (parents find competing "uses" for their children). One common failure is ignorance of lifecycle costs, or total costs of ownership (TCO). Studies in developed countries indicate that the initial hardware is only about a quarter of TCO or less. Developing countries may have cheaper labor, but other infrastructure is often unavailable. Also, skilled ICT personnel for e-education are difficult not 12 http://laptop.media.mit.edu/ 13 Such a move can overcome some of the reasons for the Simputer's failure, where consumers chose to stay away from the product en masse, which offered perhaps too little, too late, and didn't consider integration of the technology into the development ecosystem.
14 Battery lifespans are fickle, especially for less expensive (e.g., NiCad or even NiMH) batteries. 15 There are extensive fears about a secondary market being set up for these.
only to train but also to retain; e-governance projects can bring with them government perks, while e-commerce solutions imply potential upside earnings.

C. e-Governance and Land-records: Bhoomi Project
India has several state level e-Governance projects, some focused on land-record digitization. Metrics for success are a key issue in such programs. Heeks [10] finds usage of Gyandoot (in Madhya Pradesh) limited after the initial program. Financial sustainability of many programs is in doubt, e.g., Akshaya in Kerala. 16 The Bhoomi project of Karnataka is celebrated as a success, often cited by the World Bank (a funding agency). While the transactions may have been quicker and with less direct corruption, such metrics were based on surveys of users of such programs (people in the line). This failed to measure those outside the system, or unintended consequences: increasing dispossession of land from marginal farmers [30]. The systems not only lacked security mechanisms to prevent such abuses, they also lacked feedback to modify the solutions quickly enough.

D. e-Choupal
Indian multinational ITC Ltd.'s e-Choupal initiative is regarded a success in ICT for development, winning the 2005 Development Foundation's ICT and Development Prize. The high-level business model is one of removing the middleman between the farmer and the grain procurer (such as ITC) using ICT infrastructure for price-discovery and trading, with both ends benefiting from the improved efficiency and lower transaction costs. Kumar [31] calculates an estimated 3.9 year payback for ITC for their investment.
ITC's design was important in its success. Central to the model was the selection of a local farmer (Sanchalak) to operate the system, as an entrepreneur. He would help overcome literacy issues amongst farmers, and also help build up trust in the system. Related to trust is the design geared around empowerment-the farmers could gain free information using the system, and ITC (and the Sanchalak) would only get paid if a transaction was fulfilled. ITC, learning from earlier trials, also integrated the ICT into their physical supply chain, with receiving warehouses within tractorable distance-ICT was not enough in and of itself.
The e-Choupal model is not revolutionary from a technology perspective, but it is highly replicable and sustainable. It already covers roughly 5,000,000 farmers in India, and they are leveraging the infrastructure for additional services including e-commerce (with higher quality goods than previously available), e-health, and women's empowerment. However, this solution will not easily work in many other regions. Many other countries don't have the supply chain set up for such systems, and officials at the Food and Agricultural Organization (FAO) of the UN believe the entrepreneurial model will not work in much of Africa (as per personal discussions).

E. Google
In just a few years, "Googling" has joined the dictionary as a verb, speaking volumes of the integration of the search engine into society. While many studies have been written about Google's technology and the rise of the company, there is less written about the design perspective. Of course, Google is not an ICT4D solution per se, but, being free and virtually synonymous with searching, it has trickled down even into development uses and is illustrative for several reasons. It began its earlier life with a focus on just doing search, and doing it well with a clean user interface. It has since expanded, but consumers liked the speed and accuracy of their algorithms. Consumers would often give feedback, but the greater inclusivity was towards application and software developers, who could avail of tools and application programming interfaces (APIs) to build upon Google's technology. Thus, there became an ecosystem of users and developers. Google also pioneered micropayments to content developers, big and small, for advertisements through their targeted advertising AdSense technology. Thus, everyone benefited as Google grew in popularity. There was another element to Google's success -trust. Google refused to intermix paid advertisements with search results, not only maintaining a clean interface, but avoiding conflicts of interest.

F. IT for Smart Electricity Metering
Electricity is considered a primary development need. Indeed, ICT cannot function without energy. Developing countries face significant shortfalls in power, often related to the poor financial and technical state of their utilities. Electricity theft is a major challenge in developing countries, with losses (both theft and technical) as high is 25+% in India and Nigeria [32]. In contrast, China and the US have only ~8% total losses in transmission and distribution, mainly technical losses.
Earlier, electromechanical meters are now being replaced by more accurate, digital meters, and there are proposals to incorporate communications and control into meters to reduce theft and allow better operations (such as load reduction during periods of shortfall) and improved power quality [33]. Unfortunately, there are no standards for such ICT, and most solutions are proprietary and expensive.
The ecosystem is also disparate with a variety of stakeholders. Appliance vendors also envision a "smart home" but are developing proprietary or independent solutions. Utility personnel may be resentful of such technologies as it reduces labor requirements (and also cuts off a source of illicit income).
Breaking this chicken and egg cycle may require regulatory intervention, but electricity regulators are often risk averse and are typically unaware of ICT's potential for fundamental transformations in the power market. It is unclear who should drive the process-utilities, vendors, regulators, or consumer groups, etc.-but it is clear that without open standards, solutions will be geared towards niche markets (high margins but low volumes). 17 The few scenarios where such solutions have been deployed or are under development, such as the Italian utility Enel with blanket deployment, there is a single strong stakeholder driving the process [33]. This is similar to many ICT4D or even development projects overall, where there is a champion required to shepherd the process through political and bureaucratic barriers, e.g., a village elder or an NGO. Champions often display one or more of the following characteristics: respect, goodwill, authority, or a large following.  [9] present a process flow diagram for ICT for development which incorporates feedback from users and posits availability, affordability, and acceptability as key attributes of ICT solutions as used for development. This also includes deployment as a component of the R&D space. We present an enhancement to that model to explicitly allow for stakeholder participation in the problem formulation and design phase.
As Table I shows, every failure had difficulties with one or more step in the design outline, and this holds true for other failures not in the list. E.g., the much-touted Simputer, which was eventually commercialized but has seen abysmal sales, simply didn't provide value to potential users (let alone the poor, the original target users). It wasn't integrated into development needs, and there was no practical ecosystem producing content, applications, etc. Of course, one cannot claim the converse, that adhering to the outline will lead to success.
To overcome the limitations of a technology-centric push, and to improve the design as per the outline presented before, we present a framework and process we have been experimenting with to both aid designing of new products and for the analysis of existing products (services and physical products). In this model of design [34], the basic elements are: 1) Stakeholders 2) Goals 3) Design variables and design space 4) Tests and attendant metrics for goals 5) Starting points (historical solutions) ( Fig. 1) All of these are situated in the context of the ecosystem within which the needs are addressed by the problem. In this model, we stress the importance of formulating the right problem and to create alternative problem formulations in contrast to the classic product design approaches where alternatives to the product solutions and their evaluations are the focus. This process supplants the classic model of the lone designers or technology driven approaches to product and needs addressing. In this model of participation, we use the results from computational experiments with asynchronous distributed agent (stakeholder) problem solving [35] and use it in the context of problem formulation.
The fundamental reason for adopting this framework is that all ICT design problems for development are "wicked problems" and the definition of the problem emerges in the context of identifying the problem and its solution [36]. It is the ill-structured nature of the problem being solved that does not lend it self to assuming that the problem has been defined in terms of perceived needs for which there might exist a straight forward method of problem solving. Other characteristics of wicked problems include [36]: 18 • Wicked problems cannot be formulated definitively • Wicked problems have no stopping rules • Solutions are not true-or-false but good-or-bad 19 • Wicked problems cannot be tested definitively or immediately • Every implemented solution to a wicked problem has consequences • Wicked problems do not have a well-described set of potential solutions • Every wicked problem is unique 18 Taken from: Lesley Seebeck (http://www.itee.uq.edu.au/~lesley/Complex%20Adaptive%20Systems.htm ) 19 We add that there are also shades of grey, with trade-offs.
• Every wicked problem can be considered a symptom of another problem • Wicked problems interlock and overlap and change over time • The causes of a wicked problem can be explained in numerous ways • The planner, or designer, has no right to be wrong In short, ICT4D is a wicked problem! Insights from prior work on asynchronous distributed agent algorithms have directed us to a problem elicitation process that identifies multiple groups of people with each group made up of people with diverse backgrounds (functional, expertise and social) that share their mental models of the problems throughout the process of problem formulation.
Each group uses the framework elicited above by first identifying the set of stakeholders for a given problem statement and their goals and they exchange this information across these groups, ideally through formal mechanisms. Once the step is taken the group identifies the ecosystem in which the problem is to be solved and possibly revises their stakeholder spaces and goals to understand who should be included and what should be outside the boundary defined by the ecosystem. Having resolved these, each group identifies the design and decision variables and goes through the sharing process. In the course of sharing the group of groups identifies a prototypical solution to the problem. The prototypical solution arises out of previous efforts in solving the problem and their failures and successes. This prototypical solution and the formulations by the groups up to that point are used by the groups to develop the metrics and tests to detail the formulations of the problem. Eventually each group presents its view of the problem as formulated and this often leads to multiple formulations of the problem, with different collection of goals, priorities, problem details, metrics, and tests for satisfactory acceptance. Such a scenario of multiple formulations of the problem must lead to not merely a debate on which is the most appropriate formulation for a given context but also the explicit identification of the trade-offs being made in the problem being formulated. Ultimately, the set of decision-makers must converge on a chosen solution to be developed and deployed. Importantly, this model allows for experimentation and continual updating to the processes. Of course, in the real world, some of these steps in our proposed design model are undertaken in implicit or embedded means.

Construct
Personal discussions with ITC regarding their e-Choupal initiative indicates they followed a somewhat similar approach, giving extreme importance to identification of stakeholders and aligning incentives. E.g., for choosing a Sanchalak (operator), they make multiple visits to a village to find an appropriate person based on multiple critera including standing in the village, trust in the community, farming experience, entrepreneurship, and risk tolerance [37]. An early prototype system showed difficulties in closing transactions, so ITC redesigned the system to better link the information to the physical supply chain infrastructure by moving storage and transaction locations closer to consumers.

VII. CONCLUSION
Based on ICT and development experiences, we find a majority of current solutions wanting. Yes, there may be a flurry or activity and even innovation in this space, and there are real-world results being achieved. However, these are often narrow verticals of deployment, driven by the project at hand (and associated funding), and metrics are limited at best. Worse, development needs are often not integrated Into the ICT design space: ICT for development as a wicked problem is not yet recognized. The case examples show that stakeholder roles are key to success or failure, and the overall system design depends on this.
Solving the right problem is much harder than solving a "given" problem. In teaching ICT and design, experience shows students are good at solving problems once structured for them, but teaching them to formulate the right problems is hard, but important. Cultural issues and context are critical for success, but there is evidence that in the education space there is a reduced tendency to learning history and context, perhaps in part due to changing priorities and the very nature of ICTthe Internet offers instant gratification and information is typically presented in small bites, often without rigor, references, or assumptions. Using design methods and practice as well as case examples from the ICT and development space, we have proposed a new model for ICT and Development design and R&D that fundamentally treats the domain as that of appropriate problem definition, and recognizes the central role of stakeholders and feedback. We are currently experimenting in using the proposed framework for ongoing ICT4D projects, but it is premature to expect any results. We firmly believe that greater inclusion of stakeholders in the design phase of solutions itself with formal mechanisms for feedback and trade-off elicitations will lead to far greater success in ICT for development than seen today.