AAP Principle V: Design, monitoring and evaluation
Leaders of humanitarian organizations will design, monitor and evaluate the goals and objectives of programs with the involvement of affected populations, feeding learning back into the organization on an ongoing basis and reporting on the results of the process.
This principle is definitely the last one to be considered when discussing AAP, both in terms of the importance given to its application and the actual effort to apply it. I will talk about Monitoring and Evaluation later on, but here I want to focus on the part of this principle that everyone tends to ignore completely. Design.
The way project design works is normally the following: donors identify problem/issue with the support of local office (mostly citizens of the donor’s country, not local). Once the donors is satisfied with the articulation of the problem, the call for proposals is sent out. Sometimes donors actually send out a draft call for proposal to ask NGOs and other stakeholders to give them inputs on the problem articulation before the final call for proposal is sent out. This allows organizations to input into it, often with a lot of feedback from their local/national staff or partners.
Once the call is out, NGOs/UN agencies/CSOs start the design of the “solution”. If they have already a country office in the country where the project is supposed to be implemented, they will start hammering the local office asking for inputs and ideas for the project proposal.
Whatever the local office suggests is than normally discussed, bargained or completely changed, because of the conflicting dynamics inside the agencies/NGOs – normally business development knows what the donor wants; technical experts want the technical side of it done in a certain way; finance and accounting want to make sure the money can be spend and tracked; local office wants to minimize problems and maximize impact; etc.
Somehow the design of the project ends up being a Frankenstein of ideas from different people, and highlighting different priorities within the teams of the organization that drafted it. If the organization drafting the project has time and resources, they will send a couple of experts in the field to talk to possible stakeholders – normally not more than 2 weeks, for a country wide project. If they REALLY are ahead of the curve, they will even do a survey of the possible beneficiaries to support their proposal (To support their proposal, not to discuss it with them).
In my 10 years of experience I have seen more or less this same process, regardless of the size of the organization, with little differences, mainly due to having resources on the ground or not.
So, let’s be honest here. This AAP principle could, if implemented, revolutionize the entire way we do humanitarian and development work, when is states that “Leaders of humanitarian organizations will design the goals and objectives of programs with the involvement of affected populations“. Why? Because this has never happened and it is still not happening (unless we think that doing a survey, or having a focus groups with community leaders is a proper way to involve the local population).
So why are we not doing it? If you ask to any development and humanitarian worker and they will tell you that the application of this principle is impossible. The most common reasons used to sustain this argument are:
- Humanitarian work is about responding fast to life threatening situations. Community engagement for the design of the project will take too much time and will delay the process, with associated costs in terms of lives;
- Humanitarian and Development work are about applying rights and systems that, while regulated internationally, like the Sphere Standards, are not known by the local communities, so there is need for “experts” to design effective projects;
- The solutions identified by the local population may lack the inventive or innovation, or simply the expertise that international actors can bring, and therefore will be less efficient;
But are these reasons actually valid for this argument?
For example, in the past 10 years working in emergencies I have worked in literally 0 emergencies that did not protracted itself for at least 1 year. None. Almost every single humanitarian mission that you will find today, from Bangladesh to Yemen, to Syria to South Sudan, has been existing for years. Not only that, most of these humanitarian emergencies are recurring or chronic. So, there is absolutely no urgency in the design of humanitarian projects, except for the so-called natural disasters that occur with no warning. So, we could have humanitarian projects being designed by local communities, to have them identify the solutions to their problems. But we don’t.
On the need for expertise, I agree that sometime there are fields of work where the help or support of an external expert is super beneficial. But why can’t this happen in a collaborative way too? Why can’t the WASH engineer sit down with the community to explain them why latrines need to be build in a certain way, and design the plan with the community? I can tell you why: because it will take double the time he will take to just design the entire plan himself and then leave the burden to change it or upgrade it to someone else once the problems arise (like you have built latrines too far away, and women are scared to go there, so they do not use them, which will be discovered months after the latrines have been built, and another expensive expert will be called to “find a solution” to the new problem).
On the existence of rights and standards, well, the reality is that I also have very rarely see a refugee camp that respects the Sphere standards. A response that can provide as average water use for drinking, cooking and personal hygiene in any household at least 15 liters per person per day is, and continues to remain a dream in most response – we could define utopia the idea that we can have a maximum of 20 people using each toilet!
The reality is that designing with affected communities is hard, very cumbersome and takes a ton of time, mediation and willingness to compromise. Everyone knows that, including donors, and this is why they never really look for the existence of real co-design methodologies in project proposals. This is also why res ponders don’t do it: it will always be more profitable (in term of money), easier, and faster to design projects yourself, than to involve communities into it. As simple as that.
The lack of incentive here is also linked to the need that NGOs have to spend money: we have to remember that agencies and NGOs make money out of what they spend, so the more you spent, the more money you make. The fallacy of this system is therefore not in the substance but in fact in the DESIGN the system: the system is created to make co-designing with communities not profitable.
In the long run, after the project is implemented, the implementing organization will have to spend more money to adapt it, to repair possible deign flaws due to the lack of community buy in. In fact, the entire existence of “community engagement” systems is a result of this: why does a community that is benefiting from a project/service need to be “engaged”? Would they not be engaged already if they owned the project, like for example if they designed it as they wanted it? If they were at least part of the process that led to the design of the project?
The reality is that while respondents may benefit in the long-run from an inefficient system, the decision to not co-design with communities does not come from greed. It comes from a design flaw, where we have created a system that is still based on the mentality that “we know better”. The result of this is damaging for respondents as much as for communities, with the former having to continuously re-adjust projects, frustrating the hell our of its own staff; and the latter getting more and more angry and suffering the consequences of badly designed projects. The increasing violence against humanitarian organizations and staff in most of the emergencies around the world is but one of the symptoms of this dynamic.