Navigating A Crowded Landscape: Digital Tools in Humanitarian Response


12 minute read

In November 2014, CDAC Network spoke with Laura Walker McDonald about using technology in humanitarian situations. We’ve reposted it with their kind permission. You can find the original here.

More than ever before, those responding to humanitarian emergencies have new and innovative tools out there that can help them do things they wouldn’t have been able to do before. Many of these are software tools that harness the power of the internet for speed and efficiency gains as well as manipulating and moving data in new ways, for example when capturing data from affected communities quickly for needs assessments. This trend has been documented recently in OCHA’s Humanitarianism in the Network Age report and the Red Cross World Disasters Report 2013.

In this article, we ask Laura Walker McDonald from CDAC Network Member Social Impact Lab (SIMLab) how humanitarian responders can navigate this crowded landscape and work out what sort of tool they need as quickly as possible, including what questions they should be asking, and when.

Hi Laura, thanks for taking the time. What is the problem that humanitarian responders face when looking to find a technological solution to a problem in the field?

Online software tools and platforms are in vogue right now. Every company and organisation claims to have the next best app that can do all the things a humanitarian responder could possibly need. The problem is that this isn’t really the case. When humanitarian responders are out in the field and they need to get something done quickly, like capture information from hard to reach communities, they are faced with so many options for software tools that it becomes hard to determine which is most suitable for the job. Sometimes the providers over-market their tools, other times it’s hard to find the critical information that can help the responder decide whether one tool is suitable over another. Quite frequently though, the problem is that the humanitarian responder doesn’t really know what they are looking for. This means that organisations working in technology and their associated partners need to help inform and educate practitioners, and make it easier for the humanitarian community as a whole to navigate its way through this landscape and ask the right questions.

So what kind of challenges are we talking about? And what approach should be taken to tackle these challenges?

The issues are wide and varied, but it doesn’t take a technological mind to work these out. More often than not, users have certain preconceptions and assumptions about which technology they would like to use. This means they are starting with what they think the solution is, rather than the problem, which is unhelpful. They first need to think about what they want to achieve, rather than about which tools might be the best fit. Responders would be better looking at their overall objectives and asking critical high-level questions.

What specific questions and issues relating to technology should those working in humanitarian response pay attention to?

The first question to ask is usually ‘What kind of information management am I doing?’ This refers to the capture, manipulation or movement of data – the essence of the task at hand. Following this primary goal, important questions exist around how this is done, before solutions are explored. Here are six questions that may help build rounded requirements in advance of choosing a tool:

  • How fast do things need to be done? When working in a disaster affected area, users need to think about the speed of their operation and how quickly data needs to be transferred. This overall ‘need for speed’ affects the type of connectivity that will be suitable for them. Connectivity is often the lowest common denominator. People can only go as fast as their connection will allow them to go. In the field, it is common to go for a couple of days without a connection. Does a responder need to transmit this data in real-time or can he/she wait until they hit the next Wi-Fi point to synchronise the data? Answer this and it will be easier to work out which tool is most suitable for the task. It may even be possible to combine the two, providing some data over SMS which is common, and then supplementing it with extra data over Wi-Fi/mobile data when next connected.

  • How much needs to be budgeted? Speak to any technology manager working in humanitarian response and frequently they will explain that the amount allocated to technology, as part of projects, is nowhere near what it needs to be. When looking at tools, it is important to take into account all the different associated costs and make sure the budget can cover all aspects required to implement a tool correctly and comprehensively. This could include software, hardware, maintenance, training, airtime (for SMS messages or mobile data) and the human resources for running and managing the tool. What might seem to be a nice cost effective tool may have high implementation costs and these need to be considered during programme planning.

  • How suitable is it for this local area and how easy is it to use? It is important to think about what kind of users will be using the tool. Does it require a software developer to be able to decipher the user interface or can anybody step into it, just like they use google or facebook? If it’s difficult to use, it will be hard to ensure uptake and will add to costs in training and roll-out in general. Costs can spiral in the long-term as specialised personnel leave and are hard to replace. On top of this, those working with the tool could be unfamiliar with English. Can the tool be localised in the language(s) of the country where it is being used? Does it support non-latin characters?

  • What sort of licensing model is most appropriate? When starting up a technology project in a humanitarian conflict, the instinct for many managers is to immediately look towards open source software, sometimes without really understanding what that means. Open source means the code is available to modify, under certain conditions depending on the license. It doesn’t mean it’s free, although often it is. It doesn’t mean it’s more suited to social change, either. In reality going ‘open source’ brings with it its own set of disadvantages as well as advantages. Despite the promise that open source brings with it a budding developer community, for many humanitarian projects there isn’t a large community of developers ready to help expand and develop the rather specific code base, or to support a  project pro bono. User support may be hard to get, and the code may not be maintained or updated as operating systems move on. Despite not being able to freely use the code, some paid-for services can be more reliable and provide guaranteed support, customer service and long-term sustainability. On the other hand, if something is open source and the provider of the service goes out of business or stops working on it, the code base is available to use and continue working on it. Each option has unique advantages and disadvantages and these need to be weighed up when embarking on a project.

  • How compatible does the data need to be with other platforms and software? What is more important than the open source question is whether the platform supports common data standards. This sounds complicated, but it’s not. It just means that data can be downloaded in a common format like comma separated values (CSV) or extensible markup language (XML), or as an Excel doc. If proprietary file formats are used, check there’s a good export function. Without this, it’s very difficult to move data around, share it and push it to other systems and platforms. Application programming interfaces (APIs) can also help with moving data between platforms and systems, whether or not there’s a download option, but make sure that exports and APIs allow access to ALL the data – not just a selection of the fields the provider thinks are needed.

  • What sort of user support is needed? Finally, before using a platform, try and start a conversation with the people offering it. If it is difficult to get a conversation going, it’s probably a good idea to walk away. A service provider needs to be able spend time with users and it is something that isn’t usually considered by those signing up for a tool. Imagine trying to undertake a one-off survey and all of a sudden the tool stops working. If it is difficult to get somebody on the other end of the phone to help with a query, the project is scuppered. Good practice would be to open with questions directly to service staff and actually test out their user support. It’s important and is something that differentiates professional software organisations from talented well organised amateurs.

What solutions are out there to support people making a decision about what tools to use and address some of these important issues?

Broadly the approach that has been taken is to create online directories that aim to dig out useful information about tools and provide an overview of what they do. These are usually objective and try to give the most useful information for a user. There are lots of existing directories such as Humanitarian Nomad, Kopernik’s Technology Marketplace, Nethope’s Solution Center and the CDAC Network’s Service Directory.

There are limitations that sometimes affect these directories. Firstly, it is difficult to keep them updated with the most useful and relevant information. Good software products are updated frequently and for the directories to be useful, they at least need to provide current and up-to-date information. Some of the directories out there have fallen out of use as initial funding was not followed up and the organisation creating it was not able to provide ongoing support.

In some directories, companies and organisations are able to outline their tools’ capabilities themselves. This can lead to self-promotion and the overselling of features and specifications.

On top of the issues with the concept of a directory, there are also issues with implementation. Some are simply badly designed or too hard to navigate. Others don’t categorise the information or make it difficult to find the relevant bits for each section. Some are no more than a list. Often less tech-savvy managers are the ones making decisions on tools and they may need to get down to brass tacks quickly. If the directory is tedious and requires dredging through, then maybe the most appropriate solution won’t rise to the surface.

Although it’s actually from a tools provider, I quite liked a simple comparison chart on the Datawinners site. The specifications are honest (their own tool doesn’t always come out on top) and they checked with the providers featured when creating it to ensure the information was correct at the time of published. FrontlineSMS sent in comments and they changed it straight away. This type of transparent and objective approach is rare and appreciated as it helps to inform the community at large. On top of this the format of a comparison matrix is quick and effective.

What is SIMLab doing to help people make sense of it?

SIMLab’s Frontline platform is actually going to be a separate company from the end of [2014]. That makes us ‘recovering platform providers’, with nine years of experience making technology and helping people to use it. We want to help tackle some of the problems we’ve noticed over the years, and navigating this technological expanse is one of them. Rather than enter the foray of tool directories ourselves, though, we’re taking a slightly different approach. We are planning to host a community site, joined by colleagues at think tanks, NGOs, consultants, and providers, where people can directly engage with others using these tools, and the developers who create them.

Many tech providers we spoke to confirmed that they wanted to offer this type of support but didn’t have the resources to do it alone. Pooling resources, we can build a central place to debate the merits and pitfalls of different tools honestly and openly, and receive support and assistance from the developers and communities using them. Our site will be cross-sector, bringing in many actors beyond humanitarian users, along with their unique insights and shared challenges.

What role can the CDAC Network Service Directory play in making it easier for people to find the right tool?

The CDAC Network’s approach on the directory format with their Service Directory provides a simple entry point for organisations looking at technology tools for responders communicating with disaster affected communities.

Curated directories such as the CDAC Network Service Directory aim to dig out the information on tools and services that users need at the beginning of their search to allow them to make an informed choice. The Directory acts as a gateway or ‘first step’ to becoming more engaged on a community site such as the one envisaged by SIMLab.