Humanitarian feedback & response: 4 comments on how to improve
I’ve received some great feedback via email and twitter to the Client voices in the humanitarian data steam post, and in the spirit of practising what I preach, I’d like to share some thoughts in response.
Who are we listening to: clients, beneficiaries, rights-holders, affected populations?
Several people have queried terminology — why ‘clients’?
The use of ‘client’ is deliberate, because it jars slightly and our intention was to shake people out of everyday assumptions and habits. To be honest, I don’t think there is a ‘perfect’ term that works for all humanitarian interventions. Here’s some reasons why:
- Beneficiary: this assumes that people benefit from what we do, when in fact this is precisely what we ought to be enquiring about. This term has a lot of patronising baggage and we’re trying to disrupt this.
- Client: on the upside, this just implies that we’re providing a service and there is a nod in the direction of people power (“the client is always right”). On the downside, it can imply that the people we are providing a service to have greater choice to go elsewhere than is often the case in humanitarian interventions. There are also translation problems. Nevertheless we’ve settled on this term, at least in English and at least for now (if it breeds laziness, we’ll disrupt again).
- Rights-holders: the upside is that it reminds us that people have the right to be heard. The downside is that this is industry jargon and while I agree with the sentiment, it is clumsy in a range of languages.
- Service-users: perhaps the most accurate, but also doesn’t trip off the tongue very well.
- Constituents: has political connotations which could cause problems in many humanitarian interventions.
Then there is a related question of why we’re not emphasising listening to the wider affected population and instead focusing on the sub-set of clients whom we are (already) serving. As I’ve said elsewhere, we should be doing both, but we’re beginning with a focus on within-implementation feedback (i.e. existing clients) for two reasons: the relatively weak habits of communication during implementation phases (as opposed to during needs assessment) and the tactical need to focus on introducing changes to business processes in which there is time for staff to reflect and adapt. For more on these points, see my response to Samer M Saliba:
Samer M Saliba raises two great questions in response to my recent post on client responsiveness on the International…medium.com
What about improving information flow to our clients?
Some respondents raised the importance of information flow from humanitarian agencies to clients and affected populations:
For the uninitiated, the hashtag #commisaid is short for “Communication is Aid” (rather than some sort of scary Aid Commissariat) and gets at the important idea that in many settings the timely provision of accurate information can save lives, restore dignity and help achieve a whole host of other important outcomes.
Some quick observations:
- There is a clear need for interventions that are focused on delivering timely appropriate information to affected populations. We’re following some of these with interest, such as ServiceInfo in Lebanon and Refugee.Info in the Balkans, as well as more low-tech ‘traditional’ protection programming providing information through drop-in centres or mobile teams.
- Done right, listening and responding to our clients should actually increase the opportunities for better information flow to them. By routinely engaging in dialogue to check our interpretation of what we think we’re hearing, we can create regular opportunities to find out what people know, don’t know and want to know more about.
- Just because you give out information instead of blankets doesn’t give you a free pass on listening to your clients. This is really important: in a few instances we’ve seen teams that deal in information be less receptive to client perspectives because they assume that they already know what people think and want. I was surprised to find that the business of information provision is no less subject to technocratic aid assumptions and behaviour than any other. It remains important to check whether information services remain relevant over time and whether clients experience them in the way that is useful, respectful and appropriate.
So while I am a fan of better communication with affected populations, I am also a little wary of this being used as an excuse not to listen to clients, especially once interventions are up and running.
Why is progress slow?
Yes! But why?
For me, it’s all about incentives and how these play out in the habits and practices that constitute aid business as usual. I touched on several of these in the original post, such as how aid managers define, reward and communicate ‘success’, and there are further thoughts in this briefing paper.
This isn’t about bad intentions or laziness, it’s a question of competing priorities, finite time and resources. The solution rests on making the choice to value and emphasise client voices in the routines that constitute our daily work. To drive towards that solution, it needs to be a non-negotiable normal part of our work.
Which brings us finally to a really important incentives issue…
What are the donors doing?
Some donors stipulate in their aid agreements that fund recipients should demonstrate that they have listened and responded to the people they are serving with those funds. The US and UK governments have been leading the way in this regard.
But they’re at an early stage of implementation of these stipulations so I don’t think that this yet qualifies as “demanding this routinely”.
Hopefully they will. For this to work as a driver of change, donors need to demonstrate that they care about it as much as (if not more than) whether we’re spending money at the speed we originally predicted or religiously following the original project design.
As with other posts, I’d love to hear your observations on these ideas, whether in comment here, via Twitter or email: alyoscia.d’firstname.lastname@example.org (with or without the apostrophe).