Myanmar: The urgent need for communications and collaboration

Everyone’s got their knickers in a twist about Myanmar. No laughing matter this. Tens of thousands already dead, a casualty count that could go up to a mind-boggling 100,000, tens of thousands missing, millions displaced and a brutal junta that governs the country to boot. A disaster within a disaster. 

I’ve been forwarded or CC’d into literally dozens of emails this week by those who want to do something. Anything. INSTEDD sent me intimation of Sahana they’ve now got up and running on one of their servers. They are working hard to localise it in Burmese and though most of the modules are up and running (the SMS / email module is not), I sadly haven’t seen any real data on it as yet. INSTEDD’s also working on deploying some interesting technology that can support and strengthen collaboration. Eric and his team I have no doubt will play a significant role in coordinating and collaborating the disaster response. I’ve been sent some amazing KML files of medical and other logistics locations and hubs. Amazing because they are as comprehensive as one can get in a black-hole of a country where no one really knows anything for sure.

However, all the emails I’ve got have are littered with might, may, possibly, if, by chance, hopefully, could be, not sure, I think, last time I checked. Few are certain about anything other than the monumental challenge of addressing the urgent humanitarian needs of affected communities with a regime that’s not exactly helpful. Fewer have actually any experience of dealing with a repressive regime that’s as bad as the Burmese junta. By coincidence I came across an article today on the World Socialist Web Site that notes:

Since the cyclone engulfed Burma on May 3, there has been an incessant campaign in the international media to push for foreign militaries, along with aid officials, to be allowed into the country. Article after article contrasts the paranoia, incompetence and callousness of the Burmese junta with the supposed willingness of the US and other major powers to generously provide humanitarian assistance.

The Burmese junta has clearly demonstrated once again its repressive methods and callous disregard for human life. But the claim that Washington and its allies are acting purely out of concern for the Burmese people is simply a lie. 

The article goes on to make a simplistic case against US intervention that I don’t agree with, but I was partial to the essential critique of aid dynamics. Restraining myself to the dozens of emails I’ve got from some actors who want to do something in Myanmar and their ideas for information and communications technology support, I recall what I noted during Strong Angel III in 2006:

Given the paucity of bandwidth on the wireless networks and the intermittent connectivity in general, much of the information on-site has migrated from the world of bits to the world of atoms. I Information markers in the form of billboards, butcher paper, ribbons, printed maps, cardboard cutouts and scraps of paper have taken the place of the sophisticated information exchange and social networking built into the SA III website, which is by and large inaccesible on-site. This, in and of itself, is a valuable lesson.

For around a week, we had in the staging grounds of SA III more bandwidth that I could have commercially mustered in Sri Lanka. Theoretically, that is. In reality, we couldn’t even connect to the internet. The conflicts between the myriad of system, each in and of themselves offering the promise of connectivity yet together offering only confusion and conflict, was incredible. Collaboration remained a great idea, simply because models of collaboration based on ICT collapsed. We were reduced to physical meetings and Post-It notes. 

I have noticed that some of the same people involved with SA III (and for the record, they are good people with good intentions) are now agog with ideas on communications provisioning for Myanmar. Everyone wants to go guns blazing – which during SA III was precisely what brought down comms for everyone. Spectrum allocation and technical disputes that could have been easily resolved by advance planning and moderation simply did not occur or post facto, were too complex to manage. 

I am not alone in my frustration that the desire to do something often trumps the need for collaboration and a more robust understanding of just what we want to do, how we want to go about it, with whom, why, where and the context we operate in BEFORE we parachute in with money, equipment, love and fresh air. There are others who have expressed their disquiet with what are essentially marketing strategies in the guise of humanitarian relief. 

It sounds cruel, but perhaps people need to die for change to occur. Perhaps we should have taken the word of the junta that all was hunky-dory with its disaster response. Perhaps we should have left it to manage on its own and concentrated our efforts to maintain the fickle interest of global media over the longer term. 

But if that’s not really an option, what can we do? 

• From an ICT perspective, we can stop marketing our products and start figuring out how to work together. Everyone brings value to the table – the question is how to build synergies, strengthen complementarity, ease conflicts and augment interoperability and best practices.
• Business can help humanitarian aid, but the questions I raised at Strong Angel III on commercial enterprise and its engagement with relief work and the guidelines drawn up by UN OCHA need to be taken into consideration. There’s a delicate balance between in-country ad hoc solutions and pre-planned international best practices that can feed into deployments. Often, the best laid plans go awry minutes into deployment.
• Collaboration helps. A powerful transmitter able to provide blanket coverage to a wide footprint but buggers local communications isn’t all that helpful. Spectrum management, bandwidth allocation with multiple pipes, clients both mobile and fixed, data security and P2P network transports are just some of the headaches deployments will have to plan for as much as possible. Strong Angel III’s communications team may be able to help along with others. 
• Marketers with little understanding of and no interest in collaboration should shut up and bugger off. 
• Global media, when more robust ICTs are deployed in-country, must take care to not hog the bandwidth better used to save lives. 
• Sadly, nobody on the comms side is talking with Burmese socio-political experts to bounce off ideas whether plans for in-country collaboration with government and NGOs will actually work. Surely there must be more than a few in the West who can offer this kind of vital feedback? Western assumptions about aid and relief rarely gel with local cultural, social, political and religious contexts.
• We also know that multiple wifi / wimax deployments without any kind of technical management and spectrum dispute resolution almost guarantee that no one gets connected at all. So why are we still talking about a hundred and one different ways of getting wireless connectivity into the country with little interest in harmonisation of available bandwidth?

The case is often made with great passion and vigour that we must do something to help Myanmar. That’s good. But the responsibility to protect is not just about going in without host nation support to do good. If it comes to that, the international community and the ICT community in particular need to be certain that they don’t add to the choas, are able to provide vital comms support for relief operations from the get-go. 

I doubt that this confidence exists. Is it a case for doing nothing? Clearly not. But I just wish that those who want to help today remember that the same desire led, ironically, to severe communications breakdowns in the past.

Lessons identified perhaps, but not learnt?

Sahana SMS Module – Thoughts and suggestions

I was invited by Lirneasia to a presentation on Sahana’s new SMS module yesterday. Lara’s live blogging of the event is available here. The module works well and looks nice and is particularly well suited for sending early warning messages to the disaster response network of Sarvodaya around Sri Lanka (there’s an acronym for this that I can’t remember). Scalability of the module to deal with a larger constituency (thousands of journalists and millions of citizens) is very suspect, but that’s not what it was designed for. As was explained to us, it’s also a problem of the sequential nature of sending SMSs out from the system.

But as was noted, no tests to date have been made on the actual performance of the system that for the moment runs on Dialog. My experience with SMS communications last year after a bombing close to home suggests that SMS is also prone to congestion that can last for hours, though a technical agreement with Dialog may possibly address this by prioritising message delivery for a specific set of numbers.

Cost was whatever the cost of sending an SMS within or through the Dialog network. It was clear that setting up this module needed to be done in consultation with (or at the very least, adequate notification given to) the mobile telecoms provider it used for message delivery. Else, as was pointed out, warning messages to hundreds could easily be shut down by automated SMS spam guards, which would defeat the purpose of the system.

One suggestion I had was to simplify their three character survey response code. My suggestion was to limit the characters to the first key press of a mobile keypad (a,d, g, j, m, p, t, w and *, 0 # if necessary) since multiple key presses to get to the other letters could lead to, particularly when also dealing with a chaotic context, high levels of stress and possibly sleep depravation, higher levels of error in input. 

The suggestion was also made to made the UI a bit more like Twitter, with notification of how many characters had been used in a message and how many there were left. 

It would also be necessary for Sahana to encourage the best practice of the most urgent numbers at the top of any group list, given the sequential nature of SMS delivery, ensuring that they got the message first. It would be useful then to also encourage the creation of groups based on geo-location – so that say in the case of a tsunami alert, disaster responders along the coastal belt most likely to be affected could be alerted as first and then others. Extrapolating key numbers from a group that contained a whole bunch of numbers at the time of sending the message out would be next to impossible. 

It would be interesting to see if the Government Information Dept. or National Disaster Management Centre takes this up as a means of communicating disaster early warning and subsequent information to journalists and other key actors. A key conversation in this regard was facilitated by an article of Chamath Ariyadasa from JNW news on Groundviews, well worth reading even today.

One feature I would like to see in the Sahana SMS module is an automated keyword response mechanism, akin to what FrontlineSMS already has. For example, someone in the field types “emc colombo” which could be a short-code understood by the system as a request for emergency contacts for that particular location / district / GN division. Those managing the module would be responsible for updating responses with current information. So in this example, “emc colombo” could result in as SMS like “N.D. Hettiarachchi, dndmc@sltnet.lk, +94112431590 T, +94112431593 F”.

It would be interesting if the system actually logged the delivery time of messages to the extent made possible by delivery receipts with Dialog and Mobitel (maybe with Tigo too). It would be interesting to get a a baseline on a normal day (a dry run of the system with Sarvodaya’s network) and another during an actual disaster warning / early response context to compare how the system deals with stress placed on it and on the larger mobile network. 

I wonder if Sahana can and will provide this module as a web service delinked from the larger Sahana system? I can see far broader applications for this than disaster early warning and a web services approach or at worst a thin client approach would allow it to be used by those who don’t necessarily want or need the full blown Sahana system.