Categories
Humanitarian principles

Use of Proprietary Software in the Aid Sector Perpetuates Racial Injustice

Photo: Chris Morgan

Proprietary software is a barrier for African people to participate as equals in humanitarian and development work in their own continent. It helps perpetuate a monopoly on well-paid aid jobs enjoyed by people from wealthy, majority-white countries.

I’ve been working with colleagues in Tanzania to create elevation models for flood modeling using drone imagery. It’s an incredible project, and my Tanzanian colleagues are brilliant. However, there is an unexpected obstacle to the meaningful inclusion of my African colleagues, and to the project’s success:

Our European-based technical supervisor has demanded the use of proprietary software, despite the availability of free and open source software (FOSS) alternatives.

Our European supervisors are baffled as to why we object to this. They know that we want the highest quality output, just as they do. Why, then, would we be resistant to using “the best tools?” One of them wrote:

“I know you favour open source, but I would recommend [using X proprietary app]. The quality of the [FOSS function] is quite low compared to the [proprietary function]. As a consequence, you will need far more manual editing to clean up the [FOSS] result than you would need to clean up the [proprietary] result. For any serious project, I expect the costs for additional manual editing to be much higher than the costs for a [proprietary] license.”

This reflects a colossal misunderstanding of the African context. Our European colleagues on this project cost thousands of dollars per day[1]The cost of a European expert is not just salary; this includes institutional costs of their employers such as universities or consulting firms, which are often considerably more than the actual … Continue reading. The non-profit license for the proprietary application is $3,000. This represents a saving if it avoids as little as two days’ work by a European expert.

A brilliant, passionately motivated young Tanzanian professional costs on the order of $40/day (including institutional costs, and well above the median salary). The cost of this proprietary software license is equivalent to full funding for 3.5 working months of one of our African colleagues.

One of my Tanzanian colleagues training local government officials and university professors in a technical seminar. A great deal of his expertise arises from self-directed use of FOSS software, which of course he can access without limitations.

People from wealthy, majority-white countries cannot easily grasp the magnitude of the inequality that puts such tools out of reach for most African people.

A Tanzanian from a low-income family who is struggling to get through university will have almost no disposable income. And once they graduate with a master’s degree in a technical field, they can hope to receive a salary between $250 and $1,000 per month. A software package costing $3,000 might as well cost a million, for all that it’s practically available to them[2]Some tools may be licensed to their university, but most specialized ones are not—the proprietary tool used in the project I’m discussing here is fairly specialized, has a $2,000 educational … Continue reading.

Equal access (the same price for everyone) is meaningless in the context of vastly disparate incomes. Equity could be achieved by steep discounts or subsidies for people in low-income settings, but FOSS tools offer the possibility of justice; barriers to access are simply not present.

Image source: (https://twitter.com/RaeHughart/status/1018310985164214273/photo/1)

Thus the African participant arrives on a project with absolutely no experience using the tools[3]A software license is often provided so that the African participants are able to use the software during the project. What they lack is the opportunity to work with it before and after the project … Continue reading [4]The use of “Cracked” proprietary software is widespread, even in professional settings. While this does result in a sort of access that allows people to develop skills, there are at least four … Continue reading, and the funding agency concludes that European experts are needed to do quality work on (to quote my colleague’s statement above) “any serious project” while African team members, who have less time to learn the tools, are seen as unqualified. This protects the ability of Western experts to continue consuming the lion’s share of development funds in Africa[5]This includes what is sometimes known as “circular aid”, whereby donor country funds ostensibly for poor people mostly get disbursed to citizens of that same wealthy donor country..

One of my colleagues in Tanzania designed and constructed a highly functional mapping drone using Free Software tools; he participated in a huge global community of drone experts who share knowledge using those tools. His drone costs less than 1/10th the price of a proprietary product with equivalent capabilities.

Tweet: https://twitter.com/WVol_/status/1226071618943930368

The use of proprietary products creates a vicious cycle whereby charitable and public development funds are effectively channeled to proprietary software companies, who improve their products[6]Or invest in their marketing and strategies to discourage the use of competing options. while FOSS developers struggle to find time and money, further widening the gap—and the barrier to entry[7] As a rule, the more a proprietary application in a technical field gains a quality edge over the free alternatives, the more their price goes up. Consumer-facing applications sometimes become … Continue reading, entrenching the Western monopoly on well-paid jobs in Africa.

This Tanzanian team’s motto has been “Local People, Local Devices, Open Knowledge.” FOSS tools, a form of open knowledge, have been fundamental to their approach.

What shall we do?

The entire development sector, from donors on down, should make the use of Free and Open Source Software tools whenever possible a default requirement.

  • The use of proprietary tools should require specific justification based on urgent need, and explicitly not be budget-driven.
    • “It’s cheaper because it’s faster” should not be considered a sufficient justification when the savings is predicated on massive salary disparities between Western and African workers.
  • All required use[8]Please note we’re talking about situations where the contracting agency requires or encourages the use of proprietary software, either explicitly or implicitly. Mandating the use of a spreadsheet … Continue reading of proprietary software[9]Freeware, proprietary software monetized by ads, surveillance, or the expectation that some users will buy premium versions, has problems including privacy, the risk of data being locked in, and poor … Continue reading should include a mandatory, verifiable strategy to ensure that it is meaningfully available to local people (and not only those already employed in the relatively high-paying aid sector[10]African UN and World Bank employees can easily access proprietary software. They are, however, a small fraction of the African population, and often not from marginalized groups (it usually requires … Continue reading).
    • For example, any proprietary software required by donors to execute projects should be made available freely (or at a cost proportionate to local incomes[11]If a software package costs $3000, that represents 6.7% of the median income in, for example, the Netherlands, where the average person earns $44,668 per year. In Tanzania, where the median annual … Continue reading) to local people and institutions wishing to bid on or participate in the work (this should include all those interested, not merely those shortlisted for contracts, and include students; the inequity is in access to gain the familiarity and skills to successfully bid on projects or get jobs, not access to required tools once contracted or funded). This would—in addition to reducing the tilt of the playing field—go some distance to revealing the true cost of proprietary software to the aid sector and society as a whole[12]A single donor-funded project requiring a proprietary software package may very well account for the cost of the purchase by the successful contractor. It does not account for the purchases by … Continue reading.
  • If and when proprietary solutions are used despite the existence of FOSS alternatives, donors should provide grants to the maintainers of the alternatives to mitigate the market distortions arising from aid money funding their competitors[13]The Public Money Public Code movement advocates for the products of public funds to belong to the public; assets paid for by tax money shouldn’t be directly captured by private interests and … Continue reading.
  • Donors should plan ahead; if a project requires a specific functionality that a FOSS product does not have, the cost of supporting its development should be factored into the decision whether to use a proprietary competitor to it. If the cost of developing a FOSS feature is within a visible distance of the cost of the proprietary application for a given project and is useful for other aid projects, basic fiduciary responsibility dictates that the FOSS alternative must be developed to avoid waste of aid funds by multiple projects buying the same proprietary product.
  • If and when proprietary solutions are used despite the existence of FOSS alternatives, the resulting products (data, algorithms, and processes) should be made available using an open technology standard[14]Often proprietary products produce by default outputs that can only be read using proprietary software (and sometimes only by products from the same vendor). These proprietary formats block access … Continue reading, so that future projects can use and build upon the work using FOSS tools.
A Tanzanian team uses open-source hardware (FOSS aficionados will note the Raspberry Pi and Arduinos here), Free Software, and a lot of hard work and expertise to perform high-precision (<5cm error) surveying for a fraction of the cost of proprietary equipment.

We can replace the vicious cycle of exclusion with a virtuous cycle of inclusion and human development. We work with FOSS tools, we invest in and share those tools, and more people can participate. More participation leads to better technical outcomes, a wider spread of knowledge, more reduction of poverty, and therefore more investment in those tools. 

Anti-Racism in Aid Tech

The aid sector, both in the humanitarian and development sub-sectors, is increasingly aware of the racial inequities that pervade it. The aid sector must face its own inadequacies in light of the Black Lives Matter movement and philosophy. The technology niche within the humanitarian and development sector is even more steeped in white male privilege and exclusivity. The use of proprietary software amplifies and perpetuates this. We can—and should—stop using it.

Today, a Tanzanian colleague told me that since our team began emphasizing FOSS software several years ago, he has grown more skilled and more fully included as a participant in the global tech conversation. He specifically thinks this was made possible by the adoption of FOSS tools in the larger community around our team, in part due to our advocacy for those tools. The positive effects of making FOSS a priority are significant for individuals.

The stereotype of deep, complex technology being the exclusive domain of geeks from wealthy countries does not reflect reality. The African Hacker is alive and well.

Much more work and fundamental change are necessary to remove the barriers to the meaningful inclusion of people of color—and break the monopoly of white Western people—in the aid sector. Lowering the barrier to technical work by using FOSS tools is a positive step that is well within our ability to implement now. 

Thanks to the many friends who commented on or contributed to this essay, including Hawa Adinani, Iddy Chazua, William Evans, Chris Houston, Godfrey Kasano, Steve Mather, Freddie Mbuya, Dorica Mugusi, Immaculate Mwanja, Bornlove Ntikha, Kristen Tonga, Hassan Valji, and Hessel Winsemius. All errors are mine. Not all of the people listed here necessarily agree with everything said here; please blame me, not them.

References

References
↑1 The cost of a European expert is not just salary; this includes institutional costs of their employers such as universities or consulting firms, which are often considerably more than the actual salaries
↑2 Some tools may be licensed to their university, but most specialized ones are not—the proprietary tool used in the project I’m discussing here is fairly specialized, has a $2,000 educational license, and is not available in the Tanzanian universities my colleagues attended (or any others that I am aware of).
↑3 A software license is often provided so that the African participants are able to use the software during the project. What they lack is the opportunity to work with it before and after the project (it is almost invariably withdrawn or expires after the funding ends and the project concludes).
↑4 The use of “Cracked” proprietary software is widespread, even in professional settings. While this does result in a sort of access that allows people to develop skills, there are at least four problems with it: a) users of “cracks” are technically committing a crime in most jurisdictions (though many in Africa are not aware of this), b) it only works for popular applications; there are usually not “cracks” available for technical software in narrow specializations, c) the “cracked” software often doesn’t work right, and d) this helps entrench the proprietary application as fewer people use the legal FOSS alternatives. Speaking of the legality: if you believe that the use of “cracks” is justified or suggest it is how low-income people should learn, then either you don’t think using it is a crime (and therefore you don’t really believe in proprietary software, welcome aboard), or you think that the inequitable access justifies this crime (in which case read on; there is a better solution)!
↑5 This includes what is sometimes known as “circular aid”, whereby donor country funds ostensibly for poor people mostly get disbursed to citizens of that same wealthy donor country.
↑6 Or invest in their marketing and strategies to discourage the use of competing options.
↑7  As a rule, the more a proprietary application in a technical field gains a quality edge over the free alternatives, the more their price goes up. Consumer-facing applications sometimes become more affordable as companies attempt to attract a larger user base, but this rarely happens with technical packages that have a small set of potential users and therefore relatively inelastic demand. There’s no incentive to lower the price unless it would attract more users.
↑8 Please note we’re talking about situations where the contracting agency requires or encourages the use of proprietary software, either explicitly or implicitly. Mandating the use of a spreadsheet is fine, provided it doesn’t specify if it should be Microsoft Excel or LibreOffice Calc and doesn’t explicitly make the use of exclusive features of Excel necessary (there are a few Excel functions, particularly around macros, that don’t work in LibreOffice, but the overwhelming bulk of Excel’s functionality is present, and files can usually be seamlessly passed between the two systems).
↑9 Freeware, proprietary software monetized by ads, surveillance, or the expectation that some users will buy premium versions, has problems including privacy, the risk of data being locked in, and poor functionality in low-income settings due to bandwidth requirements. However, it doesn’t contribute much to the problem we’re discussing here: a barrier to access that perpetuates a monopoly on well-paid jobs. Therefore for the purposes of the current discussion we are not suggesting eliminating the use of Freeware (there are other reasons to consider this, but that’s for another time).
↑10 African UN and World Bank employees can easily access proprietary software. They are, however, a small fraction of the African population, and often not from marginalized groups (it usually requires substantial resources to acquire the credentials and connections needed to land such jobs). Genuine inclusion reaches beyond those who already have highly-paid internationally-funded positions.
↑11 If a software package costs $3000, that represents 6.7% of the median income in, for example, the Netherlands, where the average person earns $44,668 per year. In Tanzania, where the median annual income is $848, this software is 353% of the median income; the average person would have to refrain from spending a penny on food, shelter, or other items for 3.5 years in order to purchase it. To provide equitable access based on median income, the price in Tanzania should be $56.95, and would, therefore, require a discount or subsidy of $2,943 per purchase. Median income from the World Bank.
↑12 A single donor-funded project requiring a proprietary software package may very well account for the cost of the purchase by the successful contractor. It does not account for the purchases by unsuccessful bidders, or those by students and job seekers who need to be up to speed with the required tools before they can even enter the market. The aid sector as a whole pays many more times for proprietary software than just the licenses used on projects. This doesn’t even begin to account for the opportunity cost to beneficiary societies of bright, motivated local people not participating in the market at all because they can’t get onto the first rung of the ladder.
↑13 The Public Money Public Code movement advocates for the products of public funds to belong to the public; assets paid for by tax money shouldn’t be directly captured by private interests and withheld from the public that paid for them. Since a lot of aid money is public, and in any case should help beneficiary societies in the broadest way possible, a similar principle should apply.
↑14 Often proprietary products produce by default outputs that can only be read using proprietary software (and sometimes only by products from the same vendor). These proprietary formats block access not only to the tools, but also to the results and therefore much of the benefit of aid work.
Categories
Humanitarian principles

My Do’s and Don’ts for Humanitarian Innovation Proposals

Co-written by Ivan Gayton and Hassan Valji. For some reason WordPress does not display Hassan’s name on the byline; trying to sort this.

I’ve spent time reviewing proposals for humanitarian funding mechanisms lately. I’d like to offer some advice for people creating funding proposals, and for funding agencies!

Do’s and Dont’s. Actually Mostly Don’ts.

  • Don’t build portals unless there’s already a strong, specific demand for them.
  • Don’t make something that only has an impact if someone else does the heavy lifting. Corollary: don’t assume that if you provide information or coordination capacity someone will use it to save lives.
  • Don’t worry about helping everyone a little bit. Help someone profoundly.
  • Do choose a hard, nasty problem. I don’t mind if you’re likely to fail. I mind if your success wouldn’t change anybody’s life.
  • Do tell me who it’s for, how they are helping people, and why they need your innovation. Extra points if it’s for you! If you are already saving lives and you have a stone in your shoe, tell me how you are saving lives, how that stone is impeding you, and how you’re gonna try to get it out of your shoe.
  • I don’t care if you have a blockchain, machine learning, social media strategy, or drone. I like all of those things, but I care if you have a real humanitarian problem to solve, a connection to the context, and a good team, not a cool new solution.
  • Don’t tell me you’ll get a partnership with a telecommunications company that will provide you with free Internet, SMS, USSD, or any other kind of freebie. Unless you already have a deep engagement with one or more telcos, an understanding of their interests, and role for them beyond providing your project with free stuff or special treatment, you won’t get such a partnership. Telcos rarely provide such things, even more rarely to small initiatives, and only then if the national telecommunications regulator allows them to. For the most part, if you can’t work with the infrastructure that everyone has access to, you can’t work.
  • Don’t tell me a particular operational agency will work with you unless they’ve said so. Securing a partnership with a credible humanitarian agency involves navigating interests, gatekeepers, politics, and bureaucracy, and above all developing meaningful engagement with their mission. Planning to pitch them after you’ve been funded or developed your solution is not a good approach.
  • Challenge the limits of the possible. Don’t, however, challenge the laws of physics in a humanitarian innovation proposal. If your plan involves an AI passing the Turing Test, energy from crystals, a permanent magnet motor, or homeopathy, I’m gonna give you a zero.
  • Mentioning that a new technology or product exists, and then saying “…but for refugees!” might not be as innovative as you think it is. Yes, solar power, the Internet, and mobile phones exist. Yes, that huge refugee camp or hospital you read about does exist. Bringing something from column A to column B because it seems like it would work might not be such a bad idea, but the demand or need should come from column B. You’d better explain exactly who needs and wants it, and why.

Coordination Might Not Save Lives

Humanitarian coordination generally boils down to an attempt to steer aid actors to the greatest unmet needs, reduce duplication and waste, and turn a bunch of disparate actors into a cohesive effort covering needs efficiently and effectively. In a humanitarian emergency this is mostly a mirage; it seems like something you should aim for, but when you walk to the horizon there’s no water. The idea that there’s a bunch of effective capacity just waiting to be pointed in the right direction is simply wrong. There is often a lot of money around, and a lot of people milling about, but the core of people and projects that are actually improving and saving lives is rather small, and they are busy.

The people, agencies, and projects that are truly effective already know what they need to be doing, they are aware of one another, and they know their beneficiaries. They don’t need your coordination meetings. They don’t need your Web-based coordination portal. They don’t need your SMS platform, new social media network, or app.

Nobody is sitting in their field office in North Kivu thinking, “Gee, we have all these doctors, nurses, medicine, food, water, and ability to protect people from violence. If only we had a machine-learning blockchain SMS social-media solar drone portal, we’d know where to deploy them!”

The people who are able to help are already helping. They need money, staff, insulation from political interference, the ability to work safely, reduction of customs and immigration obstacles to import their people and stuff, less donor paperwork and more funding continuity, hardware and software that work in hot, dusty, Internet-challenged environments, hugs, more time with their families, and acknowledgment.

Speaking of acknowledgment, the people who are saving lives aren’t all (or even mostly) expats. They don’t all (or even mostly) work within the formal aid sector. When they need information, technology, or coordination they’ll ask for it.

Help Someone, not Everyone.

I see many proposals predicated on the idea that if the proposers build a portal to aggregate and analyze information, help agencies coordinate and communicate, visualize and Big Data-ify information, and build a website or app, a bunch of aid actors will adopt it, use it, become more effective, and save more lives. Often these proposals don’t identify a very specific user.

The odd proposal actually has a specific customer in mind, and occasionally that customer is already aware of the idea and seems to want the product. A small proportion of proposals are from agencies already directly helping people, requesting support to build something that they feel they need for their own operations; a good sign that the need is real. But far too many proposals seem to be predicated on the idea that “if we build it, they will come,” often providing a list of well-funded agencies that will be pitched once the product is ready.

If you are the agency that writes a proposal to build something to coordinate, inform, direct, advise, communicate with, or assess aid agencies, you should look to meet a specific, urgent demand from someone (ideally yourself) who is demonstrably (or at least plausibly) saving or improving lives. If you have a customer in mind, try to verify that they want and need your product before you start writing the proposal, or better yet, see if they’ll partner with you on it!

While I don’t generally advocate applying business principles to humanitarian aid, a Silicon Valley venture capitalist named Paul Graham wrote an essay called Do Things that Don’t Scale that I find incredibly useful. I had to think about it for a while to translate the idea into humanitarian terms, but it boils down to helping a specific agency or person get something they urgently need, rather than many agencies or people get something they might sorta want.

If you write a proposal that doesn’t obviously aim to help a huge number of people or agencies but feels like a determined shot at solving a hard, deep problem, I won’t fault you for any lack of ambition. Convince me that you’ll save or profoundly impact one life rather than vaguely improving one thousand, and I’ll back you (in part because I think if you save one life, we can worry about scaling your innovation to save more lives later).

I’m not saying forget about helping a lot of people, I’m saying get the “helping” part right first, then worry about the “a lot of people” part.

Don’t Show Up with Solutions Looking for Problems

An even worse example of the Hypothetical Customer™ variety of proposal is the idea that some cool new tech—which happens to be your product in non-humanitarian settings—would be great for refugees, victims of conflict, populations facing outbreaks, or rural hospitals in Africa. Worst of all are those whose primary benefit is not for the beneficiaries.

Someone is always writing a proposal of the basic form:

A) Solar Power / Mobile Data Collection / Biogas / Efficient Stoves / The Internet exist and are good for people. We have a great product to provide that.

B) Refugee Camps / African Hospitals / People Affected by Conflict exist, have problems, and are served by Agencies with Money. They would be better off if they had our product.

We propose to bring A into B because A is awesome and there are lots of people in B who could use it. It’ll be sustainable because the Agencies with Money will pay for it!

These proposals often don’t make the case for a specific demand from people whose problem they understand deeply. When they list multiple receiving contexts (a list of conflict-affected countries, for example), or describe a context in terms of the population size and general context alone as if it were a commercial market survey (i.e. “There’s a big refugee camp full of people who could use X!”), it’s clear that the emphasis is on the solution, not the problem.

I’d rather hear “People in context B, who I am one of or I know them very well from years of work alongside them, have a huge problem that affects them—specifically them—terribly and, after much thought, I have come across or invented A that could solve it.” The emphasis here is on the specific problem and people enduring it, not on the solution and the people providing it.

If the Agencies with Money want to swap out their diesel generators for solar systems, the refugees want to use biochar stoves, or the public health agency wants geotagged mobile data collection, someone from within that context should be making the case for it because they really want it, rather than someone from the outside trying to sell it.

In many cases, the justification for bringing A into B is not direct benefit to the people in A. Replacing diesel generators with solar panels in refugee camps is justified by the reduced impact on the climate. There’s nothing wrong with this impulse, but it’s not putting the immediate needs of the beneficiaries first, which is going to hamper adoption. Humanitarian innovations should address the immediate needs of the users and beneficiaries who use them if they are to have much hope of being adopted. Incentives are important.

Incentives Matter. Innovation Should Serve the User.

Someone is always thinking that if only everyone would report their symptoms to a central portal, we’d be able to control an outbreak much better. Or that if medics would provide better information to epidemiologists and researchers we’d be able to stop future outbreaks more effectively. This is basically true. What’s missing in both cases is the incentive for the user!

Why would I download and install an app on my phone to report my Ebola or COVID-19 symptoms or determine if I’m a contact when the only benefit is better overall outbreak control, but nothing to help me personally? Why would I risk being forced into quarantine, my family bankrupted, my community invaded, and being ostracized unless these risks are counterbalanced by a tangible benefit? Hint: I won’t. I may be willing to report my symptoms if I am confident that doing so will result in me personally receiving better services or some other benefit.

Why would a medic in an Ebola clinic spend extra time recording detailed observations for epidemiological and scientific analysis if it doesn’t immediately help the patients they are fighting to save right now? Hint: they won’t. Or at best they’ll do it when you are watching, and as soon as you go away they’ll return to focusing on their patients.

To convince me that your innovation has a chance at being adopted, you’ll have to show me why the user will benefit, not just why it would be great for everyone if users cooperated.

Self-reporting of contacts or symptoms must lead to desirable assistance for the reporter, and medical data collection must lead to immediate benefit for the patients. Otherwise it’ll be all but impossible to get enough people to use it to be useful. Any other innovation that requires users to actively participate for a larger community or global benefit is subject to the same rule.

Don’t Mess with James Clerk Maxwell.

I appreciate proposals that challenge the limits of the possible. Great things come from people refusing to believe that they can’t do something.

There is, however, a difference between challenging social norms and stuffy bureaucrats versus challenging the laws of physics and James Clerk Maxwell.

I see occasional proposals that have an idea to solve deep fundamental problems in computer science (strong AI natural language translation, for example), vanquish entropy to create unlimited clean energy, harness the power of crystals, or otherwise make fundamental advances that overturn the current scientific consensus or technological state of the art. These have no place in a humanitarian funding proposal. I’m not saying that these things are impossible (some may be possible), I’m just saying that this is the wrong venue to challenge the scientific consensus.

Don’t try to shoehorn your fundamental theoretical or technological advance into a humanitarian proposal. Take your free unlimited clean energy machine to the academic and scientific community. Take your machine learning model that translates all languages in conversation to one of the venture capitalists investing in pushing the boundaries of AI. If it works, we’ll see you in Stockholm, and then we’ll talk about how to help refugees with it.

It occasionally happens that a project has some genuinely advanced or disruptive technology, but resorts to unscientific language to promote it. That’s even worse, because it’ll cause some reviewers to reject your entire proposal—regardless of any other merit—out of hand. Crystal power and perpetual motion get an automatic zero from me. Don’t do that.

Emphasize Problem and Team, Not Plan.

I’m not looking for great project plans, nor should donors always be looking for detailed predictions of future activities. I want you to convince me that:

  • You’ve found a really good problem (which doesn’t necessarily mean a problem that affects lots of people, though that doesn’t hurt; I really mean a problem that has a profound impact on those it affects)
  • You are intimately connected to the problem and those affected by it (better yet you are affected by the problem), and
  • You have a good team to attack the problem. This means you have diversity, technical strength, well-aligned incentives, determination, you are likely to enjoy working on the problem, you like and trust one another, and you’d probably try to solve it even if we didn’t fund you.

Planning is—in the context of humanitarian innovation—often of relatively little value. If this sounds crazy, please imagine the difference between building a parking garage and developing a vaccine. One activity can be usefully planned in detail, and the other not so much!

If you need to build a parking garage, the materials and methods are well-known. It is possible to precisely estimate the timeline and budget to construct a parkade, and create a plan that accurately predicts the activities. Almost any competent, experienced contractor can be engaged to implement the plan, and should follow it with minimal deviations.

If you need to develop a vaccine for a novel disease, no one knows how long it will take, what paths must be followed, how much it will cost, or what the final product looks like (remember the expectation of a vaccine for HIV in the 1980’s?). A plan, with a budget, timeline, Gantt chart, milestones, Key Performance Indicators, and so forth is a laughably inadequate tool in this context.

What’s needed for a challenge like developing a vaccine is a good team with a broad range of expertise and viewpoints (including those of patients, marginalized people, and non-specialists), guts, leadership, determination, trust, funding, and support. Of course within the larger effort planned activities are needed (you need to begin by hiring people for a specified period of time to explore and work on the problem, as well as securing premises and supplies), but the plan isn’t the key to success; the understanding of the problem and the quality of the team are.

Humanitarian innovation is usually more like developing a vaccine than building a parking garage.

Obviously this argument is one that should be primarily made to donors, not to those of you writing proposals. Donors, you should consider whether a team is proposing to attack a problem that doesn’t lend itself to planning, and adapt your support to the pivots and detours that are necessary for success. Asking people to make detailed plans for months or years down a fundamentally unknowable road is wasting their time—and yours. Are you really supporting work on the hardest problems if you only fund those for which a parking garage-style plan can be made? Why not empower a great team to take on a hard problem without demanding that they predict the future, and walk that road with them, advising, giving feedback, and encouraging them as they go along?

Proposers, in many cases you will still have to write a project plan to get funded. Furthermore, if your project is toward the parking-garage range of what is plannable—which may legitimately be the case; not all good innovation is sailing uncharted seas—the plan is useful and important. Still, there’s nothing stopping you from putting extra effort into the problem and team sections! I think good donors will appreciate it.

Good luck. Maybe I’ll see your proposal one of these days.

Categories
Field anecdotes

A Little Girl in Darfur

Kalma Camp, Nyala, Darfur, Sudan, 2005.

Seventeen children had died in the MSF clinic in Kalma camp in a single week. I joined a fellow logistician from another agency, and we set out to test every water pump in the camp for bacterial contamination. One of the pumps was on the grounds of the school run by Unicef, and it showed signs of contamination with a quick bacteriological test.

During the first visit, a crowd of kids surrounded us, chanting “OK, OK”—their usual refrain when seeing a “Khawadjia” (foreigner). A little girl, maybe somewhere between four and six years old, hovered at the inner edge of the crowd, watching us intently. I smiled at her, and she made a shy little moue of acknowledgement. One of the school employees approached Adam, the Darfuri man working with me, and he told me “she wants to meet you.” When she came up to me, I took up the little girl without thought or fuss and sat her on my shoulders. I spent the rest of the time in the school that day working with a grin on my face as this little girl went from near-paralyzed with shyness and fear to lording it over the other kids from her elevated perch atop the giant Khawadjia.

Chatting with the teachers, Adam told me that the little one was terrified of black men. Stunned, I asked why, and he replied that the Janjaweed had killed her entire family in front of her. Her father and brothers, the only men she had known, were dead, she feared everyone who looked like the Janjaweed, which basically meant every man in Darfur. Adam himself couldn’t approach her without her whimpering in fear, and when the time came to leave I gave the girl back to a female schoolteacher.

I came back to that school two more times. The little one leapt into my arms as soon as I crossed the gate the second time, and I placed her my shoulders again as I worked, surrounded by a gleeful mob of kids, of whom the girl was temporarily the undisputed queen. The third time, she spoke to the schoolteacher in her tribal dialect, who spoke to Adam in Arabic, who translated to me, “She is asking if you will become her father.” I didn’t even know what to say, so barely responded, other than some non-comittal phrase about the difficulty of adoption. My response was not translated, but the little one gripped me tigher and laughed, clearly thinking that the conversation was going well.

We finished the work on the water point in the school during that third and final visit. After sitting on my shoulders for another hour, and spending some time in the crook of my arm, the little girl wouldn’t let go of me, and a schoolteacher had to peel her off of me, screaming. I walked out the school gate blinded by tears, trying not to let anyone see my face. I said to myself, and to Adam, “we need to carry on fixing the water points in the whole camp. No water, no life.”

I never saw that little girl, or entered that school, again. I may have been told her name, but I don’t remember it.

I thought I had made the right decision to walk away. Safe water for a camp sheltering hundreds of thousands of people is no light responsibility, and the romantic notion of saving a single person is more self-gratification than serious humanitarianism; the “adopt a child” programs marketed by the schlock NGOs that look to me like businesses are the very essence of what I hate in the aid world. I’m not so sure anymore that I had made the right choice to walk away from her. I think sometimes we acquire a duty to a single individual who chooses you, and that duty trumps the arithmetic of the greatest good for the greatest number. I cannot imagine who that little Darfuri girl is now, or what happened to her. The range of possibilities includes a shallow unmarked grave among the plastic bags and desiccated tree stumps in the deforested landscape surrounding the sprawl of Kalma camp, the life of a displaced woman in Darfur, complete with virtually certain abuse, or, at best, an escape back to a Darfuri village, a farmer husband, a few donkeys, a mud hut, and birthing a child every year, some of whom will even survive to adulthood.

I’m not sure that when someone asks you to be their father, you don’t simply become so whether or not you accept it. In some way, that little girl from Darfur, wherever she is, may still be the sister that my daughters Kaede and Sakura, born long after I returned from Darfur will always have, though they will never see or know her.