Usually, I find myself nodding enthusiastically when reading J.’s Tales from the Hood; his thoughtful mini-essays on humanitarian aid work (with, as he describes it, “occasional digressions toward rock music, motorcycles, and parenthood”) have from time to time even been known to make me belt out a loud “yeessss!!!”, accompanied by fist-pumping motions that look totally ridiculous on a bespectacled, bald, overweight forty-something.
But this time I found myself frowning, and actually disagreeing vehemently. In his latest article on “rules to live by”, he writes:
Don’t overdo “process.” Yessssssssssssss, process is important. But process is not the actual point of aid work. The point is product, output, outcomes, impacts, benefit to beneficiaries… [INSERT PREFERRED AID-WORLD BUZZWORD]. If your process doesn’t lead to one of those in fewer steps than you have fingers, then it is probably useless and should be fixed or abandoned immediately.
Don’t overdo “participation.” Sometimes less is more when it comes to group decisions and group-led processes. If you can make the decision, make it. If you must involve others: Involve the lowest number of people practical for operational decisions. Involve only technicians and/or those with direct managerial authority over the project in question on technical decisions.
Of course, of course J. is right that outcomes are more important than process – but I think he overstates his case when it comes to the simplicity of the process. By total coincidence, I posted a response yesterday on humanitarian.info in which I said, “… if your solution can be written on a postcard, it probably solves nothing”. This was the summation of a four-paragraph argument that silver bullets don’t exist, that we need to look at systems as a whole when searching for solutions to issues, and that consequently those solutions will hardly ever be simple. To put it another way: we don’t live in a Hollywood movie; our problems will not be resolved in two hours in a script that can be gleaned from a one-page summary.
It all comes back to what I wrote in my post about ICT versus systems: if you want progress, you will need to do much more than just introduce yet another tool or another procedure – you will need to tackle the system, and on the whole systems don’t respond too well to short, sharp shocks. And all this with the caveat that, yes, of course there will be complex issues that can be resolved in a simple manner – but not that many.
Similarly, although I agree totally that one shouldn’t ‘overdo’ participation, I think that J.’s rules of thumb (“If you can make the decision, make it. If you must involve others: Involve the lowest number of people practical for operational decisions. Involve only technicians and/or those with direct managerial authority over the project in question on technical decisions.”) are overly simplistic. Yes, of course I keep the final responsibility as the manager in charge, but I can use inclusive process to:
- build consensus, which will make my life much easier when finally implementing what needs to be implemented – and in many cases actually lead to an increase of effectiveness and efficiency, because the time spent on participation is outweighed by the time saved on implementation;
- get feedback in an early stage that can make the difference between doing something stupid or doing something smart – and so improve our product/outcomes/impacts/benefit to beneficiaries/whatever. In other words: sometimes the street sweeper knows more about how to deal with autumn leaves than the dendrologist.
And now go and add Tales from the Hood to your feed reader – because J.’s writing shows that he doesn’t take his own advice on simplicity too seriously and really thinks about what he does; and that is a treat that is all too rare in the testosterone and adrenaline filled world of humanitarian aid.
Back to post  Okay, so I have to admit that I have thrown that one in purely to be provocative. Can I have a bit of fun sometimes?