The dominant narrative within ICT4D associates digital technologies with positive impacts, and has tended to underplay negative impacts. What are the implications for development informatics research?
There has been a recent cluster of global evidence about negative impacts:
- Economic: online retail models are precipitating closure of high street shops. This may be more economically efficient but it is also more ‘efficient’ in terms of employment numbers, it erodes both the sense and reality of community, and large ICT-based firms have been adept at avoiding paying corporation tax. (See attached ‘thank you’ note posted by staff of closed UK photographic retail chain, Jessops.)
- Political: the excitement of the Arab Spring and its supposed twitter revolutions has given way to a situation in which the autocrats have colonised cyberspace. Moving on from the simplicities of blocking and filtering, regimes are now monitoring online communications in order to identify and then arrest, intimidate or attack opponents. Paid commentators are spreading misinformation and pro-regime messages.
- Military: killing by drone is on the increase as are the concerns about autonomy, civil use, and accountability. It is now possible to manufacture your own gun using a 3D-printer. An undeclared cyberwar is already underway between global powers.
- Social: ICTs have propelled a hypersexualisation of young people and pornification of sexual relations.
We can begin to understand this via the ICT impact/cause perspectives diagram shown below.
Unless we adopt an extreme perspective, we can recognise that in terms of impacts, it would have been equally easy to pull out a set of positive evidence about ICT. But it is positive and negative together that tell the whole story. And in terms of causes, there is no simple relationship between the technology and the impacts identified above but, instead, a socio-technical foundation.
This leads to a number of implications for the academic field of development informatics:
Balance: are we balanced enough in terms of the impacts we associate with ICTs in our work? Pushing a largely positive narrative can have the effect of making our work seem like hype; a relentless monotone buzz to which those working in development become habituated, and start to ignore.
Preparation: are the policy makers and practitioners who use our work prepared for what’s coming? Development informatics research needs to engage with the negative impacts, providing research users with an understanding of those impacts and, where possible, some strategies for amelioration.
Analytical Tools: do we understand what is behind these ICT trajectories? ICTs are not the direct cause of the impacts outlined above; they are an enabler of particular economic and political interests. Development informatics needs to ask the age-old question: cui bono? Who benefits when high street shops close? Who benefits from cyber-repression? Who benefits from printed guns? Who benefits from pornography? Cui bono is answered by the analytical tools of political economy. We need to be answering those questions and using these tools a whole lot more in development informatics.
Advocacy: how do we engage with ICT4D innovation trajectories? Even as it becomes more open and more decentralised, the trajectory of innovation can still be shaped by debate, by advocacy and by activism. Development informatics has always been an engaged area of academic endeavour, not stuck in the ivory tower. We have often worked with those seeking to deliver the positive impacts of ICT4D. The challenge now is to work more with those seeking to avoid the negative impacts of ICT4D.
If you see other implications, then let us know . . .Follow @CDIManchester
Why has M-Pesa been so successful in Kenya, yet mobile money initiatives in other developing countries much less so? Recent Centre for Development Informatics research can help provide a systematic response.
M-money services have two core functionalities. Registered customers can convert between e-cash and real cash (typically at the physical premises of an m-money agent), and can transfer e-cash from their account to that of another account holder via SMS. They might use this to send money to family members or friends, or to pay a provider – anyone from a taxi driver to a local school – for goods and services.
M-Pesa was launched in Kenya in 2007. It has grown spectacularly: in mid-2012, there were 19.5 million m-money users in Kenya (83% of the adult population), transferring nearly US$8 billion per year (equivalent to 24% of GDP) – M-Pesa is responsible for more than 90% of these transfers. Transfers are growing at nearly 40% per year.
It’s not that m-money initiatives in other developing countries have failed: there are an estimated 250m users of m-money services in emerging markets. Just that they have not – yet – succeeded on anything like the scale of M-Pesa, with Kenya accounting for 30% of all emerging market m-money transactions in 2011. For example, a recent survey in South Africa found only 16% of respondents with a mobile money account. In Nigeria, only 3% of adults use mobile money. And Africa is the lead continent: outside the Phillipines, m-money has been very slow to catch on in Asia. In India, for example, Nokia quit the m-money business in 2012 after two years of failing to build a critical mass.
How do we explain the differences? University of Manchester research, based on six months of primary fieldwork conducted by Chris Foster, analysed the reasons M-Pesa has grown so fast in Kenya; reasons summarised in the model shown below:
Ongoing support from government – liberalisation of the mobile market; investment in infrastructure; light-touch regulation; facilitation of the initial pilot, etc – combined with strong consumer demand across all strata of society (itself partly fed by the instability and disruption following the disputed 2007 elections). These drove a virtuous circle:
- Competition between mobile sector firms pushed them to seek profits beyond the traditional middle-of-the-pyramid; answering the demand from the majority market of the country’s poor.
- The service was delivered via atomised distribution networks that reached right down into poor urban and rural communities; a network of nearly 50,000 agents by 2012.
- Those embedded intermediaries – essential in scaling any innovation to reach the base-of-the-pyramid – were given the flexibility to adapt business models, retailing patterns and service offerings so they met the specific and heterogeneous needs of their local customers. Effective knowledge channels allowed these innovations to filter back up to the lead firms, which then scaled those they found most useful; fuelling yet further growth.
Armed with this model, we can analyse the m-money weaknesses in other emerging markets. For example:
- Much lower levels of customer demand (put down to both culturo-institutional factors and more effective functioning of and access to existing financial services) combined with a more stringent regulatory regime are behind the slow growth rates in India.
- A much smaller number of intermediaries (agents) and a lack of innovation (e.g. to address cash float problems) is restricting growth of m-money in Uganda and Tanzania.
- Tighter regulation and the much small number of intermediaries has held back expansion of mobile money services in South Africa.
We are not the first to try to understand the different performance of M-Pesa vs. other countries (see e.g. Wolfgang Fengler, Amaka Okechukwu who both also note the value of Safaricom’s market domination). However, we hope that our model provides a clear and transferable framework for comparison, that can be used alongside more in-depth evidence from other countries to help understand their relative success or failure in mobile money.
If you see ways in which you think the model should be modified – based either on experiences in Kenya or elsewhere; then let us know . . .Follow @CDIManchester
If you don’t already know it, Raspberry Pi is not a low-cost computer. It’s an ultra-low-cost computer (see photo below). And it was the subject of a recent demonstration and discussion workshop (see links for video) for CDI members in Manchester. This focused on the development-related potential of Pi and its add-on interface ”Pi-Face”, which is being developed at the University of Manchester by Andrew Robinson.
Although credit card-sized, Pi is a fully-functioning computer. Hook up a keyboard, mouse and monitor and away you can go with Linux and, for example, OpenOffice. And, as noted, it is ultra-low-cost. The actual production costs will depend on scale, with the economics catching even Raspberry Pi Foundation – the non-profit creators – by surprise. Expecting they might eventually ship around 10,000 Pis, they have already shipped more than one million.
At those sorts of production scales, costs for Pi could be reduced to around the US$15-20 mark. Adding a keyboard, mouse and Pi-Face will stack less than US$2 on top, and looking at similar products it is likely that a small screen can be produced for US$15. Of course, cost is not the same as price but we are talking of a complete computer system that will likely cost less than US$35 to produce and perhaps US$50-60 to buy. Just the Pi-plus-Pi-Face combination could be supplied to developing countries for as little as US$25.
In many ways, its key attributes are those of a mobile phone (not surprising since it runs with the same ARM chipset you’ll find in many mobiles):
- Very low cost puts it into the category of “semi-disposable” device, and a ready addition to many other innovations without breaking the bank.
- Its robustness and low maintenance requirements make it particularly suitable to harsh developing country environments.
- Its small size and portability make it suitable for applications that other computers can’t reach.
- It has very low power consumption, so can work more easily in electrical off-grid environrments.
But it’s not a mobile phone, and you can’t use it for calls and text. What it does do is connect readily to a host of other devices. And, unlike a mobile phone, it is easy to customise, using common open source software and “tinker-able” hardware components. All run by a .org not a .com organisation.
Raspberry Pi may just fizzle and die, without much effect on international development. But the potential is certainly there for it to paradigm shift ICT4D. The mobile phone explosion has shifted ICT4D’s emphasis towards the “C”, with widespread acceptance that “m-development” models will dominate. Raspberry Pi could shift us back towards the “I”; towards the computing and data processing and automation that were the origins of ICT4D in the 1970s and 1980s but which have fallen by the wayside.
At present, Pi is a solution looking for development problems, but three application areas spring to mind:
a) Micro-enterprise and household computing: providing access to standard computing applications not for the community but for the individual enterprise and household. Add an Internet connection and we might call it not OLPC (the One Laptop per Child initiative) but OTPH: a one telecentre per household approach that moves us beyond community computing models.
b) Technical education: the prime motivation behind Pi was to reignite interest in computing as a subject among schoolchildren. There’s a great thirst for IT education in schools, colleges and universities in developing countries but budgetary constraints are a major barrier (see earlier blog entry on revising computing curricula in Africa). Pi can help to overcome those – the possibility is that it could do all the OLPC does at half the price, and allow kids to open the box and play about much more, learning how IT works.
c) Data collection and automation applications: there’s a trickle of new electronic applications for development – smart motor controllers that save power and extend motor life, low-cost health monitors, water quality and climate change measurement devices, field-based agricultural sensors. Raspberry Pi could turn that trickle into at least a stream if not a flood.
The promise of Pi, at root, is to enable a new ICT4D innovation paradigm: one in which Pis are widely used and understood within developing countries, and in which grassroots innovation is really possible for the first time in the ICT4D domain (see earlier blog entry on grassroots ICT4D innovation). There’s no reason the same informal sector micro-entrepreneurs who now fix mobile phones can’t also work with Raspberry Pi. But they can customise and adapt this technology much more than they can a mobile phone. It can therefore be appropriated far more by the base of the pyramid.
Pi also allows a new model of collaborative innovation: that done working alongside base-of-the-pyramid consumers. Large firms, university departments, social enterprises can now afford rapid, mass prototyping – trying out and iterating quickly through many different models until they find one that works.
As yet, of course, this is promise not reality, and one can foresee plenty of issues around everything from distribution through support and training to growth in e-waste. But the international development impact of Raspberry Pi – good or bad, large or small, paradigm-shifting or incremental – is up for grabs. Over to you.
How do you turn a relatively unsuccessful e-government (or ICT4D) project into a relatively successful one?
There’s not a lot of guidance on this question. Lists of success and failure factors are generic rather than specific to any one project, and need to be analysed before the project starts. Evaluation methodologies focus more on impact than implementation, and generally apply only after the project has ended.
What is needed is a “mid-implementation toolkit”: something that will both analyse where you’ve got to in the project, and recommend an improvement action plan for the future. Researchers working alongside an Ethiopian e-government project have recently published the results of testing just such a toolkit.
Using the “design-reality gap” framework, the researchers gathered data from four different stakeholder groups involved with the e-government project, which had introduced a land management information system into one of Ethiopia’s city administrations. The system was only partly operational and was not yet fully integrated into city administration procedures: it could therefore be described as a partial failure.
The design-reality gap framework helps measure any differences that exist between the project’s initial design expectations and current implementation realities. It does this along seven dimensions (see figure below).
Where large gaps are found, these highlight the key and specific problem areas for the project. In this particular e-government initiative, significant design-reality gaps were identified in relation to:
- Management systems and structures (a failure to set up an ICT department and to hire permanent IT staff).
- Staffing and skills (hiring only five of the required nine IT staff, and undershooting the necessary qualifications and experience).
- Project objectives and values (allowing some culture of corruption to remain among lower-level administrators).
- Information systems (absence of one core system module and of digitised documents).
These gaps demonstrated that the e-government system had not yet institutionalised within the city government. The gap analysis was therefore used as the basis for a discussion with senior managers. From the analysis and discussion emerged two things.
First, identification of small gaps that had lain behind the partial success of the system – the commitment of project champions, process re-design being conducted prior to introduction of new technology, and stability in the information that was digitised onto the e-government system.
Second, identification of an action plan that would close the main extant gaps between design and reality: creating the proposed new ICT deparment, hiring additional IT staff, and setting up permanent positions with clearly defined salary scales and promotional criteria. These, in turn, would provide the basis for implementing the missing module, and scanning the missing legal documentation.
Not all the gaps can readily be closed: it will take a much longer process of cultural change before the last vestiges of corruption can be eliminated. Nonetheless, design-reality gap analysis did prove itself to be a valuable mid-implementation tool. It is helping steer this e-government project from partial failure to greater success. And the authors recommend its use by e-government managers as they implement their projects: it has helped to focus management attention on key e-government project issues; it digs beyond just technical issues to address underlying human and organisational factors; and it offers a systematic and credible basis for project reporting and analysis.
Feel free to comment with your own experiences of design-reality gaps, or other mid-implementation techniques for e-government project analysis and improvement.Follow @CDIManchester
How can we understand the impact that mobiles are having on the livelihoods of the poor?
We all know that mobile phone use has grown exponentially in developing countries. And that phones are having an increasing impact on the livelihoods of the poor by providing market prices, by supplying health information, by enabling financial transfers, etc.
But we know a lot less about how to conceptualise all this. Can we just pull some development studies ideas off-the-shelf? Or do we need to do more than this?
A new working paper in the Development Informatics series – “Understanding Mobile Phone Impact on Livelihoods in Developing Countries: A New Research Framework” – argues the livelihoods approach is a good starting point. But that it needs modification.
The livelihoods approach suggests four potential impacts of mobiles on the assets that underpin all livelihoods:
− Asset substitution: saving time and costs for journeys, but adding costs for mobile expenditure.
− Asset enhancement: greater efficiency in use of other assets e.g. for agricultural production or relationship-building.
− Asset disembodiment: the conversion of assets to digital form e.g. the codification of social contacts, or digitisation of money.
− Asset exchange/combination: e.g. the exchange of airtime or m-cash.
Important intermediaries – mobile operators, their agents, community-based organisations and NGOs, family and friends – help shape the extent and distribution of these impacts. These are also shaped by the three livelihood strategies to which the poor apply mobiles:
− Maintaining existing livelihoods and mitigating vulnerability: e.g. use of mobiles to maintain social networks that can assist in an emergency.
− Expanding and enhancing existing activities: e.g. using mobiles to obtain greater earnings from existing produce, to save more effectively, or to obtain greater remittances from existing social contacts.
− Diversifying into new activities: e.g. employment in the mobile sector, or use of mobiles to complete micro-work tasks.
These components of the livelihoods approach – assets, intermediating organisations and institutions, strategies – are therefore very useful in understanding the role of mobiles in development. But the approach also has four shortcomings.
i. Reconceiving assets. The assets pentagon was developed within the context of traditional agriculture, and it underplays recent understandings of the importance of networks, agency and capabilities in development. It would be better replaced by a three-way categorisation of assets:
− resource-based assets (RBA) that are tangible (physical, financial, natural capital);
− network-based assets (NBA) that derive from connections (social, political, cultural capital);
− cognitive-based assets (CBA) comprising human and psychological capital including competencies (knowledge, skills, attitudes).
ii. Incorporating information. Mobiles expose a truth that information is the lifeblood of development, and yet it is essentially ignored within the livelihoods framework. Information is essential to individuals’ awareness of, and ability to utilise, all assets; and the use of information requires other assets to turn it into decisions and livelihood strategies. Those processes need to be recognised within any understanding of livelihoods.
iii. Recognising bottom-up processes. The livelihoods framework tends to see intermediating processes and structures in macro-terms (government, laws, policies, culture). But diffusion and use of mobile has equally been shaped by more bottom-up processes including the functioning of specific market transactions, and user appropriations and adaptations within poor communities. The latter need to be recognised.
iv. Categorising impacts. If the core interest is impact of mobiles, the homogenising of that impact into a single “livelihood outcomes” box is not particularly helpful. Better to borrow from the ICT4D value chain and differentiate a broadening scale: from direct changes in behaviour, through process-level outcomes, to broader impacts on development goals.
Adapting the livelihoods framework on the basis of these four points, we arrive at the revised framework shown below, for use in conceiving and researching the impact of mobiles on livelihoods in developing countries:
The framework immediately helps to identify possible research questions:
− What is the effect of contextual factors – processes of globalisation, processes of technological innovation, population migration, etc – on the livelihoods impact of mobiles?
− How are markets and market processes shaping the impact of mobiles, including the tension between seeking to make markets more inclusive, and markets’ tendency towards exclusion and inequality?
− What exactly is the impact of mobiles on the substitution, enhancement/diminution, disembodiment, exchange and combination of livelihood assets at the household level?
− Are mobiles forging new forms of connection to the intermediating structures and processes that govern the enactment of livelihood strategies?
− What new livelihood strategies are mobiles enabling; how do they come into being and come to sustain; and what impact are they having?
− What factors mediate the conversion of mobile behavioural outputs into broader outcomes and development impacts?
No doubt there are many other questions that the framework can be used to identify and conceptualise.Follow @CDIManchester
Many ICT4D projects fail. There are various mooted reasons for this, of which I will highlight five here:
- Failure to involve beneficiaries and users: those who can ensure that project designs are well-matched to local realities.
- Rigidity in project delivery: following a pre-planned approach such as that mandated by methods like Structured Systems Analysis and Design Methodology, or narrow use of LogFrames.
- Failure to learn: not incorporating lessons from experience that arises either before or during the ICT4D project.
- Ignoring local institutional capacities: not making use of good local institutions where they already exist or not strengthening those which could form a viable support base.
- Ineffective project leadership: that is unable to direct and control the ICT4D project.
This does not represent an exhaustive list of causes but one can find one or more of them in many failed ICT4D projects. And they are deliberately selected because – if we turn them around to their mirror-image project enablers – they become the five key components of the “process approach” to development projects: beneficiary participation; flexible and phased implementation; learning from experience; local institutional support; and sound project leadership.
The process approach arose during the 1980s and 1990s as a reaction to the top-down, “blueprint” approach. The blueprint approach was particularly associated with use of foreign technologies in rural development projects. Perhaps, then, it is no surprise that it has filtered through into ICT4D practice.
Equally, though, one can see elements of the process approach in action in successful ICT4D projects:
- Beneficiary participation: the M-PESA mobile finance project in Kenya incorporated the views of users into project design through user trials and volunteer focus groups.
- Flexible and phased implementation: India’s agricultural information kiosk project, e-Choupal, used a pilot approach for all new services; introducing them one-by-one and planning designs and scale-up on the basis of those pilots.
- Learning from experience: Grameen incorporated the lessons from its microfinance projects into the design and delivery of its Grameen Phone programme of rural mobile telephony.
- Local institutional support: Brazil’s community computing project, the Committee to Democratise Informatics, is founded on the development of local institutional capacity through each of the schools it creates.
- Sound project leadership: returning to M-PESA again, Vodafone put skilled project managers in place in Kenya in order to make the project work.
Each one of these projects – and one can no doubt find many others within the ICT4D field – demonstrates more than one of these five elements. This is not unexpected since the process approach can be understood not as five rather arbitrarily-categorised, separate components but as an integrated whole. It can be conceived like a wheel (see figure below): flexible, phased implementation being the tyre that absorbs the bumps as the project goes along, feeding contextual information to learning from experience: the central axle from which the spokes of participation, local institutions and leadership radiate, giving strength to the whole.
Figure 1: The ICT4D Process Approach Wheel
The process approach also reconceives the notion of success in ICT4D projects. Instead of seeing either success or failure as cross-sectional, final judgements on a project, instead – like a point on the rolling wheel – any judgement must be seen as contingent and passing. Instead of success and failure, we would therefore talk of multiple “successes” and “failures” as the project proceeds. Any overall judgement would rest on relevance of the ICT4D solution, opportunities for capacity building, and sustainability. A process approach contributes to each of these.
And for ICT4D practitioners, a process approach can help pose questions:
- What is the role of beneficiaries throughout the project’s stages?
- What is the mechanism for changing direction on the project when something unforeseen occurs?
- What is the basis for learning on the project?
- What local institutions can be used for project support?
- What is the nature of project leadership?
And so forth – these and other questions can lead to concrete plans, schedules and roles which incorporate the lessons of the process approach into future ICT4D activities.
This blog entry is a summary of the online working paper “Can a Process Approach Improve ICT4D Project Success?“, published in the University of Manchester’s Development Informatics series.
If you have experiences of ICT4D project failure or success to share, please do so via comments.Follow @CDIManchester
 Good data on success/failure of ICT4D projects is embarrassingly limited, and more historical than recent. See: “Information Systems and Developing Countries: Failure, Success and Local Improvisation“
 A foundational paper is David Korten’s article “Community Organization and Rural Development: A Learning Process Approach“
 Source: Bond, R. & Hulme, D. (1999). Process Approaches to Development: Theory and Sri Lankan Practice. World Development, 27(8), 1339-1358
Effective use of ICTs in Africa requires a step change in local skill levels, including a step change in ICT-related university education. Part of that process must be an updating of university computer science degree curricula – broadening them to include ICT and information systems subjects, moving them from the theoretical to the applied, and introducing modern teaching and assessment methods.
International curricula – such as those provided by organisations like the IEEE and the ACM – offer an off-the-shelf template for this updating. But African universities are going to face challenges in implementing these curricula, which were designed for Western (typically US) rather than African realities. And when curriculum change is introduced, African universities and Education Ministries need a systematic means to evaluate progress, to highlight both successes and shortcomings, and to prescribe future directions.
A recently-published case study – “Changing Computing Curricula in African Universities: Evaluating Progress and Challenges via Design-Reality Gap Analysis” – investigates these issues, selecting the case example of Ethiopian higher education. In 2008, Ethiopia decided to adopt a new IEEE/ACM-inspired computing curriculum. It moved from three-year to four-year degrees, introduced a new focus on skills acquisition, more formative assessment, greater diversity in teaching approaches, and a more practical engagement with the subject matter.
Most literature and most advice about changes to ICT-related curricula has tended to focus on content rather than process. As a result, there has been a lack of systematic guidance around the implementation of curriculum change; particularly in relation to evaluation of change.
In the Ethiopian case, the design-reality gap model was brought into play since it has a track record of helping evaluate ICT-related projects in developing countries. The explicit objectives and implicit expectations built into curriculum design were compared with the reality found after implementation. This enabled assessment of the extent of success or failure of the change project, and also identification of those areas in which further change was required.
The gaps between design and reality were assessed along eight dimensions – summarised by the OPTIMISM acronym, and as shown in the figure below.
Using field visits to nine universities and interviews with 20 staff based around the OPTIMISM checklist, the evaluation process charted the extent to which the reality – some 18 months after the curriculum change guidance was issued by the Ministry of Education – matched the design objectives and expectations.
For example, the new curriculum expected a combination of:
- Specialist computer classrooms to support advanced topics within the subject area, and
- General-purpose computer classrooms to teach computer use and standard office applications to the wider student body.
Yet in most universities, there were no specialist computing labs, and ICT-related degrees had to share relatively basic equipment with all other degree programmes.
Similarly, the spotlight focus of curriculum change on new student skills had tended to throw into shadow the new university staff skills that were an implicit design requirement for change to be effective. The evaluated reality was one in which a largely dedicated and committed teaching community was hampered by the limitations of their own prior educational experience and a lack of computing qualifications and experience.
But progress in other areas had been much better. The national-level environment (milieu) had changed to one conducive to curriculum change. Formally, two new Educational Proclamations had been issued, supporting new teaching methods and new learning processes; and two new public agencies had been created to facilitate wider modernisation in university teaching. Informally, Ministry of Education officials were fully behind the process of change.
Similarly, university management systems and structures had been able to change; assisted by the flexible approach to structures that was particularly found in Ethiopia’s new universities, and by a parallel programme of business process re-engineering within all universities.
Evaluation using the design-reality gap model was therefore a means of measuring progress, but it was also a means of identifying those gaps that continued to exist and which needed further action. It thus, for example, led to recommendations of ring-fencing a capital fund for technology-related investments; some redirection of resources from undergraduate to postgraduate in order to deliver the necessary staffing infrastructure; and a reconsideration of some curriculum content to make it more Ethiopia-specific (in other words, changing the design to bring it closer to local realities).
There were challenges in using the design-reality gap model for evaluation of curriculum change: allocation of issues to particular OPTIMISM dimensions, and drawing out the objectives and expectations along all eight dimensions. Overall, though, the model provided a systematic basis for evaluation, one that was assuredly comprehensive, and one through which findings could be readily summarised and communicated.
The full case study can be found here. Other pointers are welcome to materials on computer science curriculum change in developing countries, including specific materials on the evaluation of such changes.