humanitarian.info

A warm welcome to the blogosphere to Robert Kirkpatrick, scion of Groove and Microsoft Humanitarian Systems. With the formalities out of the way, I can tear apart his first post to get at the raw meat inside.

Robert is bang on the money when he says that “In every disaster zone and every rural development environment… paper is still king” and equally on the money in suggesting that this is because paper has a range of natural advantages over digital formats. Despite this he also predicts that “One day, hopefully soon, we won’t need paper in the field”, which seems a strange thing to wish for – the disappearance of a technology which is better than anything else we’ve yet developed.

The usual motor for such wishes is commercial: we’re sold new technologies which aren’t really better than the old ones mainly because somebody wants to make a buck out of it. This approach has a surprisingly successful track record for the obvious reason that people just aren’t that good at rational thinking. We’re more resistant to the sales pitch when the object is right in front of us and appears to work pretty well. Exhibit A: the bicycle. Few people even try to persuade us that they have something better than the bicycle to sell us, because it quickly becomes obvious that they don’t.

Unfortunately in the world of ICT, this natural check often doesn’t apply – it’s not immediately obvious that the novel solution isn’t any better because often the product in question isn’t as tangible as, say, a bicycle. This becomes a real problem when commercial companies approach non-profit organisations, offering them what looks like a free gift. Important to remember: whenever a commercial company offers you its product for free, it’s still a sales pitch.

Having said that, Robert’s offer is more interesting than my skepticism might allow. If “paper is the weakest link in your information supply chain”, then strengthening that paper will strengthen that chain – right? Well, sort of. In my opinion, in the humanitarian sector the weakest link in an information supply chain is more often to be found at the far end – the decision-making end. That’s tangential, because I do agree that there paper is a weak link, if not the weakest, taking us back to Robert’s point:

Data entry is not only a juncture where errors tend to be introduced; it’s also the point that tends to contribute most heavily to latency in the flow of humanitarian information. When critical information needed to match needs to resources reaches decision-makers too late, coordination breaks down, further delays are introduced, resources are misallocated, and too little arrives too late to help a population in need.

Again… sort of. Note to self: future post on how the humanitarian sector may suffer from serious whiplash effects in its supply chain because of the uncertain nature of most of the material requirements, the rapid turnaround required in procurement and the shifting conditions on the ground. This problem means that truly “efficient” supply chain management is not really what’s needed – as Michael says more eloquently, it’s better supply chain visibility that makes for better coordination, since it means that managers can make earlier decisions. WFP, for example, doesn’t order food based on precise headcounts, and nor would more precise headcounts cause WFP to re-think its logistics.

I could be wrong.

As a result of this dynamic, the forms designed to assess population needs at the outset of a response soon become inadequate. Questions must be added. Others must be removed. The schema of the data being collected has changed, impacting form and database design.

Surely this isn’t a technology problem – that it is, it isn’t a problem with the schema, the databases or the processes used to populate those databases? This is a political problem. The basic fields required to respond to a humanitarian crisis are almost invariant no matter what the specifics of that crisis are. The main requirement is to take into account local technologies (e.g. do we need to look for boreholes or surface water supplies), terminologies (e.g. what words do people use to describe their situation) and ontologies (e.g. what are the administrative boundaries).

We can argue about my reservations, but Robert’s post is still based on one major assumption:

As long as paper is used for data collection, error and data loss will continue to reduce the effectiveness of humanitarian coordination, and unless someone invents self-validating paper, it’s hard to see ways that technology can help here anytime soon.

Unless Robert has access to research that I don’t, my personal experience gives me no reason to believe that the levels of error in paper-based data collection are sufficiently high to significantly reduce the effectiveness of humanitarian coordination.

This project sounds interesting – but is the problem it seeks to resolve one that warrants such an investment? Does Robert make the fatal mistake of assuming that certain key processes needed to make it work (for example, people actually cleaning up data in a collaborative workspace) will somehow materialise as soon as the technology is developed? I worry, I worry, I worry…

In the last post in this series, many moons ago, I listed five practitioner-based approaches to successful innovation – but are there any concrete examples of innovation? In the first post in the series, I said that I’ve been involved in at least five projects that I believe demonstrate innovation in the sector, and regular readers of this blog will recognise most of these names. Naturally these projects generally involve technology, but that’s not what makes them innovative – so what does?

Humanitarian Information Centres.The original concept of the HICs was that they were a field-based focal point to deliver a range of information services, especially introducing Geographic Information Systems to actors in the field. While the Kosovo HCIC wasn’t the first information centre, the HCIC’s innovation was to package this delivery in a coherent way yet still serve people at different levels – from individual refugees to UNMIK. The HICs in general started to fail as soon as they lost sight of that, in my opinion.

NetHope. In their own words, NetHope is a “nonprofit IT consortium of leading international NGOs”, but their innovation is in their approach – creating “the ability to collectively solve common problems and leverage their technology investment to achieve higher levels of efficiency, quality and reach for their organizations’ programs so that communities in need can be better served.” What this means in practice is sharing the burden of e.g. testing and deploying new communications equipment, leveraging economies of scale to get better deals on hardware and software, and – perhaps most importantly – encouraging open discussion about how to solve common organisational IT problems. This works because IT departments are non-competitive – unlike Programme Units, they are not competing with each other for funding – and because IT staff are often isolated within their own organisations. NetHope’s innovation was to create the space for these people to network with each other – everything else is built on that.

Sahana. As everybody should know by now, Sahana is an open source platform for disaster management, originally intended to enable developing countries and organizations to manage disasters more effectively but now seeing wider application (for example, it’s being used by organisations as diverse as New York City Council, Huridocs and Uncle Tom Cobbley) despite the serious limitations of open source as a model for crisis response. Sahana’s innovation was to harness the open source model to the needs of humanitarian response – a natural fit, in my opinion.

Aid Workers Network. Still crazy after all these year, AWN is a web-based community of practice to enable aid workers to share expertise. This project has never had it easy – Mark Hammersley was frankly way ahead of his time, and many of the principles that he espoused when developing the project are now commonplace in the sector.¹ AWN’s innovation was to use the web to connect aid workers, the most geographically and culturally diverse professional group that has ever existed – a similar principle to NetHope but a completely different approach. AWN has never taken off the way that it should have – not due to the technology, but due to the inability of its guiding committee to market the service successfully.

I’d be interested to hear whether people think I’m wrong, but it should be obvious that I don’t think that any of this innovation was technology innovation. In fact none of these projects were technologically innovative in themselves – their innovations were introducing or applying existing technology and techniques for the benefit of the sector. Looking back on these projects, the common denominator that made each of them more or less successful was their construction and use of networks amongst their target market. It was this network – whether more or less formal, composed of individuals or organisations – that made it possible for their impact to spread through the sector – in other words, to become both enduring and widespread.

However as soon as that focus on or leverage of networks lapses, success starts to disappear. For my money, we can see this most clearly with the HICs – as their focus shifted from supporting the entire humanitarian community to supporting OCHA and/or the Humanitarian Co-ordinator’s office, they gradually found it more difficult to be able to leverage network effects to act as an information broker. Without that role, it was increasingly unclear what their added value was to the bumanitarian community, at the same time as other actors were starting to provide similar services (notably GIS). OCHA, meanwhile, mistakenly assumed that it was the technology that was the innovation – in fact, that it was the technology that drew people to the project in the first place, which I would contest vigorously.

However what made it possible for each of these projects to create their networks in the first place was technology – and it is here that the humanitarian community needs to focus if it is to innovate successfully in future. Technology has created the possibility of overcoming many of the organisational problems that plague the sector, from organisational silos to staff turnover to insecurity in the field.² It is not that technology will solve these problems, but it does offer us the possibility of working together more effectively to solve them ourselves.

1. Although those principles are honoured more in the breach than in the observation. [↩]
2. It is worth noting that these issues need to be addressed on their own terms as well, and that some initiatives are already trying to do that. Collaborative efforts such as the Emergency Capacity Building Project (http://www.ecbproject.org) and UNGIWG (http://www.ungiwg.org/unsdi.htm) are two that are relevant here. [↩]

After much thought and a bowl of noodles (udon not ramen), I decided to clarify my thinking. Online platforms come in five flavours:

1. Response management – for the immediate information needs of an emergency. Example: Sahana.
2. Collaboration space – for both emergency and non-emergency. Example: Google Groups.
3. Community of Practice – for developing and maintaining professional networks. Example: ShelterCentre.
4. Knowledge base – for creating institutional and sectoral memory.Example: WaterWiki.
5. Capacity development – training and other development requirements. Example: various under development.

These five functions can be combined, although not necessarily successfully, but all the web-based work I’ve seen or done fits these functional descriptions. There seem to be three main areas which cause problems in terms of implementing these platforms:

• Setting up a platform without clearly identifying which function it fills, or combining different functions without working out how they’ll relate to each other within the platform;
• Creating multiple platforms that overlap, without reference to each other and without considering interoperability issues, thus increasing user confusion, workload and migraine;
• Building platforms without consulting end users, assuming they’ll welcome yet another chance to spend hours at their computer.

It’s impossible to build the perfect platform, even within a single organisation; user expectations and capacities are simply too diverse; avoiding these three elementary mistakes is a good start, however.

Professor Jeff Sonstein has contributed to discussions about Sahana in the past, and I’ve found those contributions to be very useful. His approach is very much from the user side rather than the developer side, which to be perfectly honest has been a big gap in the Sahana community. He sent around a message on the sahana-user mailing list, with a link to this page of feedback on the Sahana UI.

One of the classes I am again teaching this term here at RIT is called Website Design & Implementation… Sahana was conceived during a real emergency to meet real needs. Over time, the great work done by the initial and follow-up development teams has fleshed out the system to add needed functionality. This is a great start, but one major area needing work now that Sahana has grown so is that of the “user experience”. I wanted to comment on four (4) areas which came up in today’s in-class discussion of Sahana, all of which pertain to the “user experience” encountering Sahana.

All of these comments are worth considering – very specific to Sahana, but rooted in good practice in usability. We could use more feedback like this which can help developers to move towards a more usable version of Sahana – so if anybody out there has anything like that, then please feel free to join the community at sahana-user. It’s difficult to engage non-technical people in the Sahana effort, but this kind of feedback can be a useful contribution from anybody.

UPDATE: another good example of non-technical contributions to Sahana is the translation process, which has a home at Sahana Online Translation, thanks to the astonishing commitment of Dominic Konig – thanks Dominic!

(This post is cross-posted at TalkSahana.)

I spoke last week with Conor Foley, who’s looking at innovation in the humanitarian sector for the next ALNAP annual report. As any fule kno, innovation is a particularly interest of mine, particularly technology innovation, but I wasn’t surprised to hear that most of his interviewees shared my perspective: that the humanitarian community is not much good at innovation.

I should qualify that. The humanitarian community is built on innovation – on just getting things done despite a lack of resources – but successful innovation is very hard to come by. I define “successful” in this context as innovations that become widespread and enduring – that is, that they spread widely and last over time. I should probably qualify that as well:

1. All innovations have a distinct lifespan, and are often superceded by a new innovation (or more rarely a completely new invention). So if an innovation endures over time, that is evidence of its success; but if an innovation doesn’t endure, that isn’t necessarily evidence of its failure.
2. All innovations are context-specific, and sometimes don’t translate into other contexts. So likewise, if an innovation spreads geographically / organisationally, that is evidence for its success; but if it doesn’t, that isn’t necessarily evidence of its failure.

These two qualifications makes successful innovation sometimes hard to identify – but not impossible. In terms of projects that I’ve been involved with inside the sector, I think the Humanitarian Information Centres, the ECB Project and NetHope all qualify without any doubt (although the innovation in each project is exhibited in very different ways). What interests me more is innovation outside the sector.

I’ve been involved with Sahana for a long time now, and I wouldn’t hesitate to identify it as the single biggest innovation I’ve seen – potentially revolutionary. You can also point to projects like Ushahidi, FrontlineSMS and so forth – projects that, while not “humanitarian” in themselves, have definite humanitarian applications – but the strange thing about all these is that they haven’t managed to get significant traction inside the “traditional” humanitarian sector.

The question is, Why is this the case? What makes the humanitarian community unable to recognise and replicate innovation? And that, my friends, will be the subject of the next post…

UPDATE: To my eternal guilt and shame, I forgot to mention a fourth project that I was involved with, Aid Workers Network – again, work that was well ahead of its time, mainly thanks to Mark Hammersley.