Earlier this year, I was fortunate to have the chance to research some of Map Kibera’s work over the past 8 years in the area of citizen accountability and transparency. I was interested especially in whether the maps made in Kibera had had an impact beyond the life of each project, since they were available online on OpenStreetMap and our own website, and distributed offline via paper maps and wall murals. I looked at three sectors we’d worked on — education, water and sanitation, and security — and interviewed those who had commissioned, been given, or discovered the related maps in some way. I looked particularly at whether citizens had been able to use the maps to improve accountability and governance. This research has now been published as part of the Making All Voices Count Practitioner Research and Learning series.
The results were surprising. I found that maps had been used for a wide variety of purposes which we hadn’t known about before, including arguing for policy changes and reallocating donor resources in Kibera.
The research process involved first trying to track the maps, which was not easy. The Map Kibera team, working with research assistant Adele Manassero, asked around in Kibera, looked on social media, combed through blog posts, and otherwise tried to find out who used our maps and why. Working with open data can be messy this way. We found a number of people who said they had indeed been working with our data. Some were from various NGOs, others were in government. We also followed up on those we’d handed out the map to directly, like school heads and community leaders.
The schools map in particular, which had been the most widely distributed of our maps by far in paper form, had been used for many purposes. It had even been photocopied by the local education official to hand out to visitors. The local Member of Parliament had used it to reach out to the informal schools and create a WhatsApp group to communicate about key school information — and to petition Parliament for increased education resources for students in Kibera.
Part of the message here is that by sharing information widely, both digitally and on paper, AND with the backing and network of a trusted local team — Map Kibera — you can make room for impacts beyond a narrow project purpose usually associated with data collection. With all of the emphasis in ICT4D on designing directly for the end user, data collection is usually still done for the end user called the donor — or the organization’s HQ, or governmental higher-ups. Sometimes this data doesn’t even get used. In this case, I found that the better we targeted a variety of local potential “end users”, like leaders of local associations, teachers, and CBOs, the more we saw uptake and impact even without intensive chaperoning of the information. Maps wound up being repurposed. This is the way, I believe, open data is supposed to work.
I suppose then the question is, why did it work this way, when so often it doesn’t? I found that collection and sharing of information by trusted local residents helped lend validity to the information, improve trust and communications between government and citizens, and bring informal sectors into the light in a way that benefitted the community. If anyone wanted to know where the data came from, the folks collecting it were right there, visible, identifiable and relatively unbiased. They could also be called upon to make corrections. Schools indeed have reached out, and recently a lot of updates were made to that data by the team. The analog method of change — being able to call someone, who lives in your neighborhood, and refer to a paper visual — is key to local social impact, even if the information collected is digital.
I’ll be blogging about a number of other things I found interesting out of this research in the weeks to come. Stay tuned!
I’ve recently had the opportunity to spend some time learning and thinking about Map Kibera’s work, thanks to a practitioner research grant from Making All Voices Count.
Those who work in the NGO and nonprofit sphere like me might not be surprised to learn that we’ve had precious little opportunity to do evaluation on our work over the past 8 years. So, I welcomed this chance to look into some of the impacts and possibly unintended directions that our work has taken during this time.
While I’ve written about Map Kibera a number of times from the reflective standpoint, I hadn’t had the chance to try to track down some of the specific results. Especially when it comes to who’s using our maps and data, and for what. We have a strong commitment to open data, meaning that you can easily access our information and maps either directly through our website, or through OSM itself. That means it’s hard for us to know who has used them (and if you have, but haven’t been in touch with us to let us about it, please help me out by emailing me!).
I haven’t yet fully analyzed everything I’ve gathered through a series of interviews, focus group discussions, and by reviewing our social media and visitors logs over the years, but a few things have stood out so far. Here is just a sampling:
There were a number of cases we were able to track down of data being used without our knowing about it. For open data, that’s a success, right? It means that there have been changes in actual programming for Kibera, especially in targeting interventions to specific geographical areas, finding local partners, and directing donor resources. Information by itself may not produce systemic changes, but could redirect resources in an uncoordinated way to places that most need it. In other words, it can make aid more effective. With some coordination this might be a stronger effect.
With some support by intermediaries such as Map Kibera, information like maps can help produce larger systemic shifts. But the level of support required is a question – given that this isn’t typically well resourced. We had some impacts particularly within the education system which were large considering the amount of funding we had, but we couldn’t sustain intensive support. A larger question about the appropriate role of such an intermediary came up again and again.
Trust among stakeholders is one major outcome, which has little to do with technology and a lot to do with relationship building. In this sense, information and maps are a kind of tool for getting on the same page, perhaps, or removing some of the bias on either side. There is a lot of mistrust in informal settlements (between citizens and government, citizens and NGOs or CBOs, schools and education officials, etc). This needs to be overcome for improvements in key sectors like education and water/sanitation, two areas I looked into.
The value of “being recognized” or being made visible was something that came up repeatedly. A perceived legitimization through transparency. I think there are two things here: being able to speak out or have “voice” in the sense of self-representation; and becoming legible – that is, transparent – which may have more to do with knowing the facts than giving voice to opinions and perspectives.
Keeping data up-to-date is a huge challenge. And it can hinder scaling up and expansion because of the effort required.
Technology is still a challenge, in that most people don’t use the internet OR may have smartphones but still don’t use them to their full capacity. Offline outreach and printed materials are key, still.
Those taking part in our projects over the years have seen a lot of personal benefit, and some of this has been unexpected (on my part). For instance, the value of contests and credentials – winning an online contest for a news story, even an obscure one without any prize, was a huge highlight, as was gaining press credentials or even a simple ID badge to be identified as a member of the organization.
Clearly there is a lot to unpack in each of the points above, and there are many more topics to explore as well! If this is of interest to you, stay tuned for the publication.
MakeSense was meant to test feedback loops from “citizen-led sensor monitoring of environmental factors” in the Brazilian Amazon, providing structured, accurate and reliable data to compare against government measurements and news stories in the Amazon basin. The project centered around developing, manufacturing and field testing DustDuino sensors already prototyped by Internews, and developing a dedicated site to display the results at OpenDustMap.
It may seem obvious that it was too ambitious to try to create a mass-produced hardware prototype with two types of connectivity, a documenting website, do actual community engagement and testing (in the Amazon) AND do further business development, all for $60,000, not to mention the coordination required. But, it is also true that typical funds available for innovation lend themselves to this kind of overreach.
Good practice would be to support innovators throughout the process, including (reasonable) investment in team process (while still requiring real-life testing and results), and opportunities for further fundraising based on “lessons” and redesign from a first phase. As well, an expectation that the team be reconfigured, perhaps losing some members and gaining others between stages, plus defining a clear leadership process.
Supportive and intensive incubation, with honest assessment built in through funding for evaluations such as the one we published for this project would go a long way toward better innovation results.
Funders should also require transparency and honest evaluation throughout. If a sponsored project or product cannot find any problems or obstacles to share about publicly, they’re simply not being honest. Funders could go a long way toward making this kind of transparency the norm instead of the exception. In spite of an apparent “Fail Fair”-influenced acculturation toward embracing failure and learning, the vast majority of projects still do not subject themselves to any public discussion that goes beyond salesmanship. This is often in fear of causing donors to abandon the project. Instead, donors could find ways to reward such honest self-evaluation and agile redirection.
Introducing new technology in international development is hard. And all too often, the key details of what actually happened in a project are hidden — especially when the project doesn’t quite go as planned. As part of the MakeSense project team, we are practicing transparency by sharing all the twists, turns and lessons of our work. We hope it is useful for others working with sensors and other technology, and inspires greater transparency overall in development practice.
The MakeSense project was supported by Feedback Labs and the project team included GroundTruth, Internews, InfoAmazonia, Frontline SMS/ SIMLab, and Development Seed. MakeSense was meant to test feedback loops from “citizen-led sensor monitoring of environmental factors” in the Brazilian Amazon, providing structured, accurate and reliable data to compare against government measurements and news stories in the Amazon basin. Over the course of the project, DustDuino air quality sensor devices were manufactured and sent to Brazil. However, the team made several detours from the initial plan, and ultimately we were not able to fulfill our ambitious goals. We did succeed in drawing some important learnings from the work.
- Technical Difficulties are to be expected
Setting up a new hardware is not like setting up software: when something goes wrong, the entire device may have to go back to the drawing board. Delays are common and costly. This should be expected and understood, and even built into the project design, with adequate developer time to work out bugs in the software as well as hardware. At the same time, software problems also require attention and resources to work out which became an issue for this project as well, which often relied upon volunteer backup technical assistance.
- Simplify Technical Know-how Required for Your Device
The project demonstrated that it is important to aim for the everyday potential user as soon as possible. The prototype, while mass-produced, still required assembly and a slight learning curve for those not familiar with its components, and also needed some systems maintenance in each location. Internews plans for the DustDuino’s next stage to be more “Plug-and-play” — most people don’t have the ability to build or troubleshoot a device themselves.
- Consider Data Systems in Depth
This project suffered from a less well-thought-out data and pipeline system, which required much more investment than initially considered. For instance, the sensor was intended to send signals over either Wi-Fi or GSM, but the required code for the device itself, and the destination of the data shifted throughout the project. Having a working data pipeline and display online consumed a great deal of project budget and ultimately stalled.
- Prioritize Data Quality
The production of reliable data, and scientifically valid data, also needs to be well planned for. This pilot showed how challenging it can be to get enough data, and to correct issues in hardware that may interfere with readings. Without this very strong data, it is nearly impossible to successfully promote the prototype, much less provide journalists and the general public with a tool for accountability.
It is important to be intentional about technical vs programmatic allocation, and not underestimate the need for implementation funding. It is often the case that software and hardware development use up the majority of a grant budget, while programmatic and implementation or field-based design “with” processes get short shrift in the inception phase. Decision making about whether to front-load the technology development or to develop quick but rough in order to get prototypes to the field quickly, as referenced in the narrative, should be made intentionally and consciously. Non-technical partners or team members should be aware of the incentives present for technical team members to emphasize hardware/software development over often equally critical local engagement and field testing processes, and ideally have an understanding of the basic technical project requirements and operations. This project suffered from different understandings of this prioritization and timeline.
The anticipation of a need for future funding dominated early conversations, highlighting a typical bind: funding available tends to skew to piloting with no follow-up opportunities for successful pilots. This means that before the pilot even produces its results, organizations must begin to source other funds. So, they must allocate time to business development as well, which can be difficult if not impossible, and face pressure to create marketing materials and other public relations pieces. This can also in some cases (although not with this pilot) lead to very premature claims of success and a lack of transparency. During this project, there was some disagreement among team members about how much to use this pilot fund to support the search for further investment — almost as a proposal development fund — and how much to spend on the actual proof of concept through hardware/software development and field testing.
This is a lesson for donors especially: when looking for innovative and experimental work, include opportunities for scale-up and growth funding or have a plan in mind for supporting your most successful pilots.
A consortium project is never easy. A great deal of time is required simply to bring everyone to the same basic understanding of the project. This time should be adequately budgeted for from the start. Managing such a team is a challenge, and experienced and very highly organized leadership helps the process. FrontlineSMS (which received and managed the funding from Feedback Labs) specifically indicated they did not sufficiently anticipate this extensive requirement. Also, implementing a flat structure to decision making was a huge challenge for this team. Though it was in the collective interest to achieve major goals, like follow-on funding, community engagement, and a working prototype, there were no resources devoted to coordinating the consortium nor any special authority to make decisions, sometimes leading to members operating at cross purposes. Consistent leadership was lacking, while decision-making and operational coordination were very hard given quite divergent expectations for the project and kinds of skills and experience. This is not to say that consortium projects are a poor model or teams should not use a flat structure, but that leading or guiding such a team is a specialty role which should be well considered and resourced.
Part of the challenge in this case was that the lead grantee role in the consortium actually shifted in 2015 from FrontlineSMS to SIMLab, its parent company, when the FrontlineSMS team were spun out with their software at the end of 2014. The consortium members were largely autonomous, without regular meetings and coordination until July 2015, when SIMLab instituted monthly meetings and more consistent use of Basecamp.
Set up clear communications frameworks in advance, including bug reporting mechanisms as well as correction responsibilities. Delays in reporting bugs with Development Seed and FrontlineSMS APIs contributed significantly to the instability of the sensors in the field. Strong information flow about problems, and speedy remote decision-making, was never really achieved. At the same time, efficiency in such consortia is paramount, so that time isn’t taken from operational matters with coordination meetings — so a balance must be struck. This project eventually successfully incorporated the use of BaseCamp.
As you probably know, OpenStreetMap is a global project to create a shared map of the whole world. A user-created map, that is. Of course, in a project where anyone can add their data, there are many forms this can take, but the fundamental idea allows for local ownership of local maps — a power shift from the historical mapping process. Now, if I want to add that new cafe in my neighborhood to the OSM map, I can do it, and quickly. And I don’t have to worry that I’m giving away my data to a corporate behemoth like Google — open and free means no owner.
But lately I’ve noticed a trend away from the radical potential of such hyperlocal data ownership, as OSM gets more widely used and recognized, inspiring everyone from the White House to the Guardian to get involved in remote mapping (using satellite imagery to trace map details onto OSM, like roads and building outlines). But remote activities still require people who know the area being mapped to add the crucial details, like names of roads and types of buildings. So why is the trend worrying?
Since first training 13 young people in the Kibera slum to map their own community using OSM, in 2009, I have focused quite a bit on questions of the local — where things actually happen. And the global aid and development industry, as anyone can see who has worked very closely with people anywhere from urban slums to rural villages, tends to remain an activity that begins in Washington (or at best, say, Nairobi’s glassy office buildings) and ends where people actually live. Mapping, on the other hand, is an activity that is inherently the other way around — best and most accurately done by residents of a place. And, I would argue, mapping can therefore actually play a role in shifting this locus of decision making.
More poetically perhaps, I also see maps as representations of who made them rather than a place per se. So if the community maps itself, that’s what they see. And that can shift the planning process to highlight something different — local priorities. After all, a resident of a place knows things faster, and better, than any outsider, and new technology can in theory highlight and legitimize this local knowledge. But just as easily, it seems, it can expedite data extraction.
Even more importantly, as any social scientist will tell you, a resident of a place knows the relevant meaning and context of the “facts” that are collected — the story behind the data. An outsider often has no idea what they’re actually looking at, even if it seems apparent. (An illustrative anecdote: I was recently in Dhaka and we noticed a political poster with a tennis racket symbol. We wondered why use a tennis racket to represent this candidate? That’s not a tennis racket — it’s a racket-shaped electric mosquito zapper, said one Bangladeshi. What you think you see is not the reality that counts!)
So, when the process of mapping gets turned around — with outlines done first by remote tracing and locals left to “fill in the blanks” for those outside pre-determined agendas, that sense of prioritization is flipped. In spite of attempts to include local mappers, needs are often focused on the external (usually large multilateral) agency, leaving just a few skilled country residents to add names to features in places they’ve never set foot in before.
There are degrees of local that we are failing to account for. Thinking that once we’ve engaged anyone “local” (ie, non-foreign) in a mapping project we’ve already leveled the playing field is letting ourselves off the hook too easily. By painting the local with one brush we fail to engage people within their own neighborhood (not to mention linguistic, ethnic group or gender). We underestimate the power of negative stereotypes in every city and country against those in the direst straits, including pervasive ideas of lack of ability, tech or otherwise. This is especially problematic when dealing with the complex dynamics of urban slums, in my experience. But any place where we hope to eventually inspire a cadre of local citizen mappers who care about getting the (data) story right, it’s crucial to diversify.
Having dealt with these challenges nearly from day one of Map Kibera, I’m particularly sensitive to the question “How does a map help the people living in the place represented?” You might say that development agencies and governments have a clear aim for their maps that will help in very important ways. Therefore, a faster and more complete map from a technical standpoint is always better. (Indeed, getting support for open maps in the first place is quite an achievement). But more often than you’d think, the map seems to be made for its own sake or to have a quick showpiece.
Even if our answer is that the map would help if disaster struck, that seems to be missing the point and might not even be true in most cases. Strong local engagement and leadership are said to be “best practice” even in cases of disaster response and preparedness, though they aren’t yet the norm. Since the recent earthquake in Nepal, there has been a very successful mapping response thanks to local OSMers Kathmandu Living Labs. But critically, this group had been working hard locally for some time. And we should see this as a great starting point for widespread engagement, not an end product.
Another problem is that established mapping processes in the field aren’t questioned much, even when it comes to OSM. Since mapping is often something people do who are techies of some kind — GIS people, programmers, urban planners — organizers sometimes seem to forget to simplify to the lowest common denominator needed for a project. Does the project really need to use several types of technological tools and collect every building outline? Does every building address need to be mapped? If not, it just seems like an easy win — why not collect everything? One reason not to is because later when you find you need local buy-in, even OSM may be viewed as an outsider project meant to dominate a neighborhood, a city, especially in sensitive neighborhoods where this has indeed been a primary use of maps. I wonder if people will one day want to create “our map” separately from OSM. A different global map wiki which is geared toward self-determination, perhaps? That would be a major loss for the OSM community.
Perhaps I seem stuck on questions of “whose map” and “by whom, for whom?” Well, that’s what intrigued me about OSM in the first place. We used to talk a lot about the democratizing potential of the internet, about wikis and open source as a model for a new kind of non-hierarchical online organizing. Now, it’s clear that because of low capacity and low access, it’s actually pretty easy to bypass the poor, the offline, the unmapped. And because of higher capacity among wealthier professionals and students in national capitals globally, it’s easier for them to do the job of mapping their country instead. Of course there isn’t anything wrong with people coming together digitally over thousands of miles to create a map. In an idealistic sense it’s a beautiful thing.
But the fact is, we (that is, technologists and aid workers — both foreign and not) still tend to privilege our own knowledge and capacity far and away over that of the people we are seeking to help. We can send messages to the poor through a mobile phone, strategize on what poster to put up where, but the survey to figure out who lives there and what they care about? Still done by outsiders, hiring locals only as data extractors. As knowledge and expertise used to make decisions becomes more data-driven and complex, a class of expert and policy maker is created that is even more out of reach. Access has always been messy. Now (thanks in part to mobile phone proliferation and without much further analysis), we hardly talk about access anymore. The fad has shifted to “big data” and other tech uses at the very top.
To me, OSM was always so much more than just a place where people shared data. It was one small way to solve this problem of invisibility bestowed by poverty.
The possibilities of OSM to empower the least powerful are still tantalizingly close on the horizon. With just a few tweaks to existing thinking, I hope we can tip the scale — we can prioritize the truly local and allow the global to serve it. But to do so we must resist glib and lazy thinking around how those processes actually work. We must pay attention to order of operations (who maps first? whose data shows up as default?), and subtleties of ownership and buy-in, and we must examine who we think of as “local”.
But most of all, and most simply, we have to reorient our thinking in designing mapping projects. It could be quite straightforward, for instance:
- integrating more localized thinking into training courses and OSM materials, suggesting that people on the margins (such as slumdwellers) can and should be learning OSM tools as well;
- training people to think about social context and local priorities not just technology;
- doing more offline outreach and print map distribution; creating new map renderings highlighting levels of local and remote mapping;
- making it the norm that residents of a neighborhood be involved in early project planning;
- engaging with people who have long done offline forms of data gathering and mapping in their communities.
- Considering that first pass on a blank map might matter.
- And considering that leading local technical mappers start to conceptualize their roles more as mentors to communities and to new mappers in those places than as expert consultants to foreign organizations. I’ve seen the light bulb go on when that happens.
Yes, ultimately, we will do best to address the incentive structures of international funding which are keeping us from achieving what we’d all undoubtedly wish to see, which is everyone getting the opportunity to put themselves on the map.
Many will say that it is just too hard, too time consuming, too cumbersome, too expensive, too — something — to really prioritize local in the way I’m talking about. We’ll never hit “scale” for instance. Something needs to be done now. But I would ask you to reconsider. I believe that in fact, sensitive and thoughtful engagement with communities is the only real path to scale and sustainability for many kinds of “crowd-” or “citizen-” based data work that is now happening, and most certainly the only way to reach the real target of any development-oriented data effort — actual improvements in the lives of the world’s poor and marginalized.
This post also appears here on Medium.