In my previous post, I mentioned how of the NGOs who have digitalised their needs assessments processes, many of them will use a completely different system for beneficiary tracking and the two different systems don’t ‘talk’ to each other causing unnecessary duplication and inefficiencies.  Often what happens is one group of staff, usually some form of DME staff, once a disaster has been declared internally, conduct rapid (and not-so rapid) needs assessments using paper or tools like SMAP, KoboCollect, or another service.  Let’s say these staff conduct the assessment talking to households affected by the disaster in communities A, B, C, and D. The assessment usually contains information about who has been affected, what the impact of the disaster is, what the priority needs are, etc. and sometimes will have information about specific households (names, size, ages, etc.)

The response team leadership of the same uses many different sources of information to decide which communities to work with for their response.  In this scenario, let’s say they decide to work with communities A and C, but not B and D.  As, but usually before, operations teams implement activities in communities A and C, a team of staff (different to the DME staff above) are sent to the communities to ‘register’ beneficiaries, which includes collecting specific data on each household (names, size, ages, etc.).  These teams often use paper, but in some agencies use tools like LMMS, WFP’s SCOPE, or UNHCR tools.

So in this case what in essence happens is communities A and C are visited by two different teams from the same organisation asking for the same or similar information before they even receive any Aid. There are many reasons for this duplication including classic management problems such as silos, turf wars, etc., however in those agencies employing digital mechanisms for both processes, there must be a better way.

In other areas of our lives where we apply for things, we often register our interest giving various information about ourselves (think about applying for a course) and then if approved that information is brought “across” to our profile.  If we are asked to input the same data again, we get annoyed as we’ve already provided that information so why do we need to do it again!

So why can’t we employ the same principle to aid?  Going back to our scenario, the NGO should be able to take the household data collected by the assessment teams in communities A and C and convert it into beneficiary data at a click of a button. Staff should then be able to see where the gaps are and send teams back to the communities to fill the gaps rather than collect duplicate data.   This may require a small shift in some of the data collected through the assessment process, such as ensuring they collect basic household data from the people they talk to.  From a system perspective it requires the digital tools used for the assessment to be able to store the household data in a database, which then can be accessed by the digital beneficiary tracking system – in essence a shared database or an API should do the trick.  Some agencies may want to use one digital tool for both the assessments and the beneficiary tracking, however this isn’t necessary in my view as long as the systems ‘talk’ to each other.

Frankly, we need more people within NGOs who can stand outside of the silos and ‘see’ how things link together as this idea could also be expanded to include more than just assessment data and beneficiary tracking, but also project M&E systems and perhaps even aspects of accountability.  Sometimes I think we need to press the pause button and do a stock take on all the different processes we demand our response teams to complete and disaster affected communities to tolerate and see where there is overlap, so we can achieve much more effective data management and analysis.