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.