This blog is now defunct, deceased, dead as a dodo.
It has been superseded by my new ICT4D website appropriatingtechnology.org
and all post have been coped across.
This blog is now defunct, deceased, dead as a dodo.
It has been superseded by my new ICT4D website appropriatingtechnology.org
and all post have been coped across.
Ken’s point was that just because technology makes it possible for us to work remotely it doesn’t make this the most efficacious way to work. A commercial company wouldn’t normally make an investment in product development without first doing significant market and customer research, yet in the ICT4D field it is not at all uncommon for techies to develop cunning technology solutions and then go out in a vain search for a problem to solve with it. Involving users in project design and development is not just good business sense, it’s an essential part of doing international development well.
In August, I went to the Development Data Hackathon at The Guardian - great people, great ideas, and unlike most of the hack events I’d previously attended it was not numerically dominated by spotty white men; there was real diversity among the participants, who brought a wide range of relevant experience and skills to the table.
For the uninitiated, a hackathon is an event where a bunch of people volunteer to turn up at a particular time/location to see if they can hack together a solution to a problem. The hackathon at The Guardianwas devised to see if we could use public information recently released as open data to create new knowledge/solutions for international development challenges.
One enterprising team hacked together a map locating all of the known clean water sources in a particular province of South Sudan using data released by the United Nations Development Programme (UNDP). A second team mapped geo-tagged data on aid by sector in Malawi (hover over the circles to see who’s making their data open). Yet another team worked on trying to understand the relationship between media coverage of humanitarian emergencies and aid donations using information scraped from news sites such as BBC, CNN and Channel 4.
Ingenious as these hacks are, they also reveal how we view aid from the perspective of development actors in London rather than from the perspective of people in rural Africa – we set ourselves managerialist problems. It is an understandable consequence of running a hackathon in London that technical fixes are developed without any real input into the setting of priorities or into the research and development process from the intended “beneficiaries” of development. This is true to some extent even if the hackathon takes place in one of the 50+ technology and innovation hubs now active across the African continent. Barely a week seems to pass without a new mobile apps competition or hackathon taking place but perhaps there is a need to hack the format of these events?
“We wanted to trace the money allocated for rural development to discover what percentage is actually spent in rural communities in Africa, but no data has been released in a format and sufficient details that would make such transparency possible”.
If development is conceived of as a geek event that takes place in the capital city how can it practically be informed by the perspectives and priorities of those marginalised communities that it is intended to benefit? Paulo Freire, who worked for many years on agricultural reform in Chile, said that it was important that the intended beneficiaries of development should be lead participants in the conception and production of innovations. He argues that the intended beneficiaries of development should at the same time be its authors and feel ownership of the process. This serves equally well as a definition of agile software development and of human development.
I have been working in the field of ICT for development (ICT4D) since 1988 and technology has a positive role to play, but I still have to struggle against the urge to put the technology before the people processes. I know that hackathons can and do result in ideas that can make a positive contribution – such as the M-Farm online marketplace, for example – but there is room to improve the format so the voices, innovative ideas and development priorities of the intended beneficiaries of development, are better reflected and better served by such events. I don’t have the answer, but I am confident that if we put the right heads together we could hack a solution.
Incidentally, the team that I was in at the Open Data Hackathon was trying to map the flow of millions of dollars of public funds from the World Bank and other agencies. We wanted to trace the money allocated for rural development along its route, via various international funds, development agencies, government departments and implementing organisations to discover exactly what percentage of the initial amount is actually spent in rural communities in Africa. And – you will never guess what – no data has been released in a format that would make such transparency possible.
Where the data represents the accounting of public funds derived from tax revenues, as is the case with the World Bank, United Nations and the UK government’s Department for International Development funds, or where the funds are derived from public appeals, there is really no defence for not publishing how our money is spent in a format that makes this analysis possible.
Only when agencies release data in a format that makes it possible to produce this level of accountability will it be fair to say there is a genuine commitment to openness and transparency in aid spending.
N.B. This post originally appeared in my column in Computer Weekly.
Some software developers swear by Agile methodologies. Agile is a group of techniques for developing software that pro-actively involves a team of intended users and staff from the commissioning organisation in a collaborative design process, which is able to accommodate people’s changing requirements. Agile recognises that operating environments are dynamic (and that shit happens!) so uses a participatory development process with short iterative development cycles to ensure that the project can adapt to reflect changing realities.
Agile software development shares some features in common with participatory development practices that are commonly used in international development projects including participatory rural appraisal (PRA) and participatory action research (PAR). Like Agile, PRA involves groups of ‘intended beneficiaries’ and other stakeholders in collaborative team discussions to inform the unfolding design and management of development projects. PAR involves participants as co-researchers in a collaborative process in which they have co-ownership of the research process and its findings.
Several people have independently seen the logic in bringing these approaches together in the field of ICT4D. Last year Alan Jackson from Aptivate had the inspired idea of inviting Agile guru Alistair Cockburn & participatory development champion Robert Chambers for a fireside chat at Cambridge University. Participatory development is rooted in the theory of Paulo Freire and in the innovative practice of popular social movements in Latin America, India and elsewhere, but it was Robert Chambers that popularised them in the English-speaking world.
The Cambridge event was an enthralling discussion between two leaders in their fields who knew nothing of each others’ work, a fact which only went to make the similarities in their approaches all the more remarkable.
However this event was by no means the first attempt to explore whether Agile techniques would lend themselves to ICT4D. Field research was conducted at least as early as 2006, and tentative research was published by Andy Dearden and Haider Rizvi in 2008.
Much more recently Anahi Ayala Iacucci has been blogging on the subject. In the first post she assesses the utility of The Agile Manifesto for guiding the work of ICT4D practitioners. I certainly agree with her that involving ‘end-users’ from the outset in determining the objectives and specifications of ICT4D initiatives would be a significant advance on current practice. Imagine a world in which the development ‘customer’ was King, and where development agencies were in humble supplier roles as co-producers of development outcomes determined by their users!
Agile methodologies also have the potential – by virtue of the process of keeping the project plans/design/budget on the table and under constant collaborative review – to make the process of control and decision-making in development significantly more open and transparent.
Prince2 & LogFrames are not Agile!
In her second post Anahi moves on to consider the utilty of Agile methodologies for ICT4D project management. As all development actors know the blueprint approach of LogFrames and Prince2 is entirely inadequate for representing the dynamic social realities and constantly changing operating environment of medium-to-long term projects. For this reason funders and NGOs engage in an elaborate charade where everyone pretends that the project is going exactly as it was planned several years ago, whilst in reality everyone actually knows that this could not possibly be the case.
Anahi convincingly argues that moving to Agile development methodologies would make it possible for teams to frequently-update plans to reflect the unfolding reality. Online collaborative tools could be used to make the whole process open and transparent to the ‘intended beneficiaries’, ICT4D agencies and funders alike.
My only point of departure with Anahi (and I may be misreading her intent?) is where she argues for ‘real and independent M&E not quarterly reports’. I agreed entirely with ending the charade of existing quarterly reports, but neither would I support handed over effective control of monitoring and evaluation to ex-pat M&E consultants (if that is what Anahi means?).
To stay true to the philosophy of Agile software development – as well as to that of principled participatory development – the logical approach is participatory M&E where the ‘intended beneficiaries’, who originally co-developed the project objectives and specifications, provide their evaluation as to whether their hopes and aspirations for their own development have been fulfilled, and the job well done.
If you commission Agile software development for your business you don’t need external consultants to come in at the end to tell you whether your expectations have been met. Neither do community members participating in ICT4D projects.
As Linda Raftree has recently written there are an increasing number of ways that ICT can facilitate M&E so that funders and their ‘expert’ advisers can monitor and evaluate remotely should they feel unable to rely on the community feedback. Neatly, for our purposes, Linda concludes her post by saying that ‘donors need to support adaptive [project] design’ processes.
It looks like we are all singing from the same hymn-sheet here. It seems that Agile deserves further consideration from others in the ICT4D community. It may be that by talking Agile, ICT4D geeks and developmentistas can forge a common language with which to transform ICT4D theory-practice. Guaranteeing ‘intended beneficiaries’ voice as co-creators of ICT4D initiatives, from initial concept design to implementation and evaluation – would be certain to improve the success rate of ICT4D projects.
As Anahi says, Agile could be a game changer; it could be used to give ‘intended beneficiaries’ a genuine stake in ICT4D project development and could make ICT4D implementing agencies and funders genuinely accountable to the communities that they exist to serve. Such a sharing of power would be more just.
If used consciously to put the ’intended beneficiaries’ in positions of power and influence in the design and implementation of ICT4D then Agile could be transformational. If, following Paulo Freire’s original intent for participatory process, the objective of Agile ICT4D was that, the ‘intended beneficiaries’ of development become, at the same time, the authors and lead implementers of that development; if ICT4D process was assessed by the extent to which it enhanced the agency and capabilities of all participants then Agile could contribute to a radical transformation of the theory-practice of ICT4D.
What do you think?
In 1854, John Snow plotted cholera deaths on a map of London’s Soho district to diagnose the cause of a deadly outbreak that was ravaging the community. By mapping the geography of cholera incidence Snow was able to locate the local source of the outbreak and determine its root cause. The handle was removed from an infected water pump and it was revealed that the offending water company was drawing its supply just downstream of a major sewage outlet. His actions led to important changes in public health and epidemiology, but not before hundreds of people had died horrible deaths.
If the same Soho community were to be hit by a disease outbreak today they could set up an online map themselves and within an hour be crowdsourcing incident reports submitted by community members themselves. Texts and tweets could be used to plot incidents directly onto the map. Free and open source tools such asCrowdMap and Open Street Map now mean that anyone can quickly create an online map to visualise the issue they most care about and use it to build a compelling case for action. The availability and ease of use of the software means that we all have the ability to map the issues that we most care about and promote the change that we wish to see in the world.
Maps are extremely popular with news media as they provide a quick and effective way to depict complex issues visually. CrowdMaps are used during tsunamis and earthquakes to guide emergency services to the location of vulnerable populations and functioning healthcare facilities. Community groups are making increasing use of crowd-mapping to monitor issues like election fraud or racist attacks; in order to spotlight issues and to collect evidence of the need for change. Crowdsourcing is used to build up a graphical representation of the issue on a map, data is crowdsourced from the public in the form of text messages or tweets indicating where incidents are happening and the map effectively illustrates events unfolding on the ground.
Community generated maps can be powerful tools to monitor issues of real public concern and can provide graphic evidence to support a case for social change. CrowdMaps are most effective when used by existing organisations as part of a broader strategy, as in the cases of map.occupy.net or the stop-the-shootings siteCeasefire Chicago. When used well crowdsourcing can help build communities of shared interest. Mapping projects can provide a focus around which to stimulate debate and provide a platform for otherwise voiceless communities.
Recently I attended the Free Elections Hackathon in London where activists from professional election monitoring organisations teamed up with coders and experts from Ushahidi and One World UK. Their objective was to improve existing software previously used in Senegal and Zambia to better enable citizen monitors to report and map fraud and intimidation at polling stations, to communicate incidents to official observer missions and the media.
In the case of electoral fraud, citizen election monitors are not necessarily able to rely on the independence of their government or police – think Zimbabwe or Russia – and foreign observers may not be best attuned to local dynamics. Whether communities are monitoring elections or racist attacks, mapping provides a way to actively resist, gather credible evidence and build a compelling case for justice and social change. Building self-reliance and local resilience in this way is a key benefit of CrowdMapping.
What I like about crowdsourced mapping is that, when done well, it builds on the active participation of community members who themselves monitor and report information. People who may have been feeling powerless in the face of incidents, are empowered to take action around an issue and work toward producing the change they want to see. The evidence collected in maps can add substantial weight to a campaign; an interactive and visually attractive graphic can be worth a thousand words.
An important way of judging whether technology has played an important role in social change is whether the process left people with greater or less capacity for self-determination, i.e. how well equipped are they to deal with the next thing that life throws at them. While flying in external experts might be designed to deliver quick results, it can also be disempowering for local people, who may learn to view themselves as incapable of looking after themselves.
In 1854 community members in Soho died horrible deaths while waiting for the external intervention of an expert like John Snow. Today communities have the ability to create their own maps and produce evidence to support their calls for social change. The availability of CrowdMap and other free and open source tools provide valuable new opportunities for communities to reduce external dependence and to act together to produce the change they want to see in the world.
This article was first published in my column in Computer Weekly in June 2012
Most IT projects would be an unmitigated success if only it wasn’t for humans.
Humans have an annoying habit of resisting change and refusing to conform to the often rigid requirements of a database ontology or software application.
Corporate IT projects have a high failure rate, the multibillion-pound UK health service patient record system being just one high-profile example.
In Africa the failure rate of ICT projects in the field of international development (ICT4D) is at least as high. The reasons are often all too human.
It has become commonplace to say that only 20% of the challenge is technical and that 80% is people, but what does this actually mean in practice for technology project management?
In Zambia, as elsewhere in Africa, development is often done “at” rather than “with” local people by external “experts”. This technocratic approach to development often meets user resistance, and sometimes plain indifference, that ultimately compromises the success or “sustainability” of the project. In the face of such resistance external “experts” are often quite incredulous at the ingratitude of intended “beneficiaries” who they believe have failed to appreciate the enormous opportunity that they are missing.
The reality is that if, throughout the project cycle, people are not regularly asked what priorities they have for their own “development” there is no compelling reason why they should demonstrate enthusiasm for the latest technical “solutions” thrust upon them. It is not the job of technocrats to determine what is in anyone’s best interests; people need to be given the regular opportunity to determine their own interests and priorities, and then projects need to deliver against them. Anything less is not authentic development.
Corporate IT projects are often designed top-down by technical experts to solve problems which they conceive of narrowly as engineering issues. This technocratic emphasis fails to understand the social nature of the enterprise and the fact that all change processes involve some loss of continuity, loss of security, and, for some, loss of status and benefits. Wherever there is loss we must expect resistance. In IT projects the losers are often those who in the past had derived power from being the traditional gatekeepers of information and communication.
In international development it is accepted wisdom that if local communities do not get to participate in all key stages of project conception, definition and implementing then projects fail.
There is also an ethical issue here. People are the objects of human development – not institutions or technical infrastructures. So it is critical that they are the authors and architects of the process, their capacity for self-determination enhanced. When there is authentic participation people are not the passive objects of the cunning development projects of external “experts”, but are instead active subjects transforming their world for the better. As such they tend to be enthusiastic project champions, not sites of resistance.
In corporate IT projects the motivation to replace legacy systems is often to secure institutional efficiencies as cost savings, but “legacy humans” need to be considered too. Investment in genuinely participative staff consultation about how new technology might benefit them too can be a means to build local project ownership and avoid expensive user resistance to imposed change.
There is also the potential to harness the wisdom of the crowd. Consultation can be a mechanism to crowdsource intelligence from front-line system operators about potential system and workflow improvements that may not be apparent from a merely technocratic viewpoint.
Empowering users through participative project management processes offers the potential to deliver benefits at the human level and on the bottom-line. Turning recalcitrant “legacy humans” into project champions through genuine participation gives intended users a real stake in project success and results in technical progress, as if people mattered.
This post originally appeared in my Computer Weekly column in May 2012
Is the $25 Raspberry Pi – a basic computer on a single printed circuit board – capable of transforming the sorry state of IT education in our schools?
Produced in Cambridge, the explicit aim of the Raspberry Pi is to re-popularise programming in the UK in the way that the Sinclair Spectrum and BBC Micro did in the 1980s. The initial production run of 10,000 units sold out in minutes as early adopters fought to get themselves a piece of the Pi. Such was the demand that the Raspberry’s website crashed as the Pi proved momentarily more popular than Lady Gaga.
Geek demand is clearly extremely high, but are mainstream schools really equipped to make effective use of this opportunity? Is the arrival of a box of printed circuit boards really going to make a difference?
Lessons from the dawn of time
Launched to coincide with the Department of Industry’s “Year of Computing” the BBC Micro computer found its way onto desks in 75% of UK schools in the 1980s. The BBC Micro is still remembered fondly by many silver-haired geeks, now in their fifties, as having sparked their computing careers. The computer’s launch was part of the BBC’s “Computer Literacy Project”‘ and was accompanied by an educational TV series imaginatively called, “The Computer Programme”. The first 10-episode series was broadcast terrestrially in 1982 and was reproduced in various formats and names until 1987.
This sustained promotion of computer education produced a generation of coders that, among other things, built the world’s most successful computer games industry here in the UK. Over the last decade Britain’s has fallen to sixth place in that particular league table and universities report a continuing decline in the skill levels of UK applicants to computer science degrees. Teaching of IT in our schools is now woefully inadequate according to the Royal Society.
Lack of digital vision
The current school IT curriculum aims no higher than producing drones proficient in using Microsoft Office. However there are an increasing number of exciting not-for-profit initiatives underway that aim much higher. Apps for Good and the <GoTo> Foundation are great examples of initiatives that enable young people to build mobile phone apps to solve problems they see in the community and actively shape the digital world they live in. The Raspberry Pi and Arduino projects use open software and open hardware as platforms to enable learners to be producers of new information and communication products and services, future digital entrepreneurs and employers.
Initiatives such as these provide a real opportunity to reorientate computer education to empower learners to go beyond being passive consumers of shrink-wrapped products and become active producers of new information and communications technologies. But this possibility is jeopardised by the absence of any integrated or coherent programme of support. Without this, determining who gets to benefit from these new initiatives will be, at best a postcode lottery, and at worst end up merely affording new privileges to the already advantaged. So far the majority of school orders for the Raspberry Pi have come from the UK’s most privileged schools.
It is very early days, but so far these initiatives have been geek-led and geek-fed. The kind of national programme of educational support that was the backbone of the BBC Micro success is conspicuous by its absence. Coordination with government and the teaching profession is needed.
A printed circuit board is not enough
It is entirely possible that, with the right support and imaginative teaching, use of the Raspberry Pi could inspire a new generation of coders and software engineers. However, providing a printed circuit board is not enough. To make optimum use of this technology it will be necessary to train teachers, modify the curriculum, fund the essential peripheral equipment not included in the advertised price, and generate the necessary will among politicians and the teaching profession to invest in a sustained programme of learning support to nurture the creativity, digital literacy and technology entrepreneurship that school learners need, and society lacks.
Fertile soil for Raspberrys
One place that is already fertile soil for Rasperrys is in the growing number of hackerspaces that are springing up around the country.
Hackerspaces are places where technology enthusiasts gather to hack, mash-up and collaborate on their latest technology projects. It is where geeks go to share their experience and expertise and to incubate innovative new projects and start-up initiatives. Here skills and experience are shared among a community of people who enjoy nothing more than hacking hardware and software to innovate exciting new products and services.
As well as providing fertile ground for Raspberrys, hackerspaces are proof there is a real thirst for technical knowledge and opportunity to experiment that is not being met in the formal education system. By studying how people self-organise in hackerspace to learn new skills and collaborate on projects we might even be able to steal a few ideas about how to reinvigorate classroom learning.
This post originally appeared in my Computer Weekly column in April 2012