What follows is the fourteenth in our series of FrontlineSMS guest posts. Here, Kelly Sponberg – a Project Manager at RANET – discusses the challenges of ‘local’ and ‘scale’, and the potential his organisation sees for FrontlineSMS in their work
“For about a decade now I have been fortunate enough to work on a small and niche-focused program called RANET (Radio And Internet for the Communication of Hydro-Meteorological Information for Rural Development). The program has a simply stated goal to make meteorological forecasts, warnings, and observations more readily available to rural and remote communities. It does so through a variety of training, system development, and site deployment activities.
The technologies utilized by RANET have ranged from satellite broadcasts, to satellite telephony, to FM community radio, include HF e-mail networks, a variety of web based applications, and of course mobile phone messaging and data services. We recently began experimenting with and using FrontlineSMS to scratch a particular itch. If you will bear with me, I’ll try to describe the challenge and problem FrontlineSMS uniquely addresses well.
RANET began with the notion that rural communities are often most affected by and vulnerable to environmental changes and variability, yet the information products communities may find beneficial are not easily distributed outside of major cities in developing regions. The quote that somewhat launched RANET came from an Algerian nomad who said when interviewed, “Just tell me where it has rained, and I’ll know what to do.”
A story about a nomad
Such a simple statement is loaded with insights and information. Think of the challenge. The nomad is constantly on the move in remote desert areas to shepherd his herd to food and water. Under the best of circumstances, it is a difficult technical challenge to deliver information to this individual in a timely and sustainable manner. Beyond the physical delivery of information, there are barriers related to language and perhaps literacy. But moreover his statement counters assumptions about what information is valuable. Most meteorological services try to improve forecast quality and generally the science behind weather products. This hard work and dedication often leads to the conclusion that forecasts and newer products are the most valuable to an end user. Indeed this is probably true for most end consumers of meteorological products and services. In this application, however, the nomad wanted a simple observation of where it has rained as that is where there will be fresh water and new vegetation. He cannot afford to follow a probabilistic forecast, no matter how accurate it might be.
The story of the nomad touches on the challenge of scale, which I suspect arises in all ICT4D programs. Scale is the tension between macro and micro. It is regional versus local.
What do I mean here? If you abstract out why we do ICT4D projects, it comes down to solving ‘problems’ of information access and inequality, data management for efficiency, and letting individuals and communities speak in their own voice. In the abstract, the development community, be they foreign or indigenous, wants to be able to replicate local successes across regions, countries, and continents where other people have similar needs. Resources are simply too scarce to not strive for scalable solutions.
Scale vs. relevance
There are two major problems of scale here. One is content, information, or the ‘byte’. If you have a network that can distribute across a region, country, or even continent, the information distributed or shared often becomes less locally relevant and powerful the more widely distributed it is. (The exception to this is of course sports scores.) Certainly, technical or science based information does not change all that much. Information on disease prevention is not going to change in substance from one locale to another, but it will necessarily need to transform how it is portrayed to fit within local cultural, religious, language, education/literacy, economic, and even political contexts. To me the ‘what’ of information in ICT4D is perhaps the most challenging.
I work mostly on the ‘how’, which is simply the movement of information from point A to B in its most basic description. Nonetheless, ‘how’ needs to be cognizant of the ‘what’, and as a result faces its own issues of scale. Communication platforms that cover large geographic areas are often broadcast in nature, and therefore diminish the ability to target or carry information tailored to local needs. Of course broadcast systems are easier and more affordable to deploy than many networked systems, but with a broadcast you lose the ability to receive timely feedback or foster sharing / local production of information. Many point-to-point or networked systems operating over large areas face regulatory challenges, are extremely expensive to operate, or require significant technical competence. Community based systems, such as information centers and FM radio, require significant upfront investments and require considerable maintenance and training costs as well. And these may not be connected such that local information and knowledge can benefit others. When done right the results are clearly amazing, but the initial investment and time required to effectively establish such sites often prevents widespread deployment throughout a country; to say nothing across multiple countries.
All of this is to say its easy to find a communications solution that is sustainable and meets the needs of a small community or area. Demonstrating success at this scale is easy. Identifying something that suits local needs yet can be replicated elsewhere (often with an expectation of decreasing cost) is not so simple.
Enter the mobile
Mobile phone services offer a potentially interesting solution. With rapid growth of networks in even the most remote of locations, there exists a standard and geographically expansive platform; even if operated by many different service providers. Because of the point-to-point nature of the network, it manages to cater to local information needs and interests. In fact I would argue that in areas where the Internet has not penetrated, mobile phones change the expectation of how and what information is transmitted. Even in comparison with a community FM station, a mobile device is inherently more local and simply intimate. I believe this creates a new expectation for ever more tailored or individualized information. And of course the basic economics of mobile, as well as the form factor, makes it ease to deploy. Messages can be sent for mere cents, and as it is in the interest of commercial providers to make durable and easy to use devices, many deployment headaches are assuaged.
Clearly, mobile is not new. There are hundreds of ICT4D projects out there utilizing mobile to collect and disseminate information. But, there still remains a scale challenge I believe. To process messages for collection of field data, reporting, or to distribute information beyond a small social circle or region of a country, you need some automation. Creating these scripts and programs on a computer/server to interface with a mobile network is not always straight forward. It requires expertise and funding to do so. This unfortunately represents a barrier to scaling and replication. If you examine many mobile messaging projects underway, many are either still pilots or very geographically limited. At times it really is the content that limits scaling, but I also believe that as the technical basis for the local system is so highly tailored, it can’t be easily transferred without starting with a whole new reinvestment in setting up servers, programmer time, etc.
As a program working in multiple countries across Africa, Asia, Pacific, and recently Central America, RANET has been struggling with this issue for some time. Do we help our country and community partners develop highly customized mobile messaging applications, but then be unable to transfer this effort to other countries? Or, do we develop some generic data management and messaging interface that while feature reach is unwieldy or lacks the specific function needed in a local circumstance? Frankly, we have experimented with both, and we have experience of success and failure with each approach.
FrontlineSMS and the local
In the last year I came across FrontlineSMS, which I believe represents an interesting genre of tool. The desktop application prepackages most of the basic messaging features a small social group might want in order to exchange messages. But the ease of use extends into more advanced applications. The more RANET experimented with automation tasks and keywords in FrontlineSMS, the more amazed we frankly became. Want to automatically collect field data and filter for keywords, users, etc.? Not a problem. Want incoming messages to auto-respond? Simple. Have a database half way around the world you want to store incoming messages or use to feed an auto-response sent as SMS? Easy. Did I mention it is free?
Many reading this have probably experimented with or used FrontlineSMS, so I don’t pretend this is news. But, I have also used other commercial applications that cost thousands of dollars and have half the features. Some applications are feature rich and enterprise in scope, but these then require considerable technical expertise to use and maintain. The FrontlineSMS team has done the hard job of creating an easy to use application that can be used to meet local community needs, but it also performs well for scaled applications that at the end of the day connect and replicate successful local implementations.
RANET has only begun to introduce FrontlineSMS into its country programs, but I already see the possibilities. To help showcase some of the capabilities, as well as provide our community with baseline training, a few tutorials/discussions were added to our relatively new ‘Weaver‘ series. The articles on FrontlineSMS are available in English, French, and soon Portuguese. In the near future we plan to add some video tutorials and discussions, and after that hope to start sharing some of our experiences on how FrontlineSMS has been used for collection of data, ‘broadcasting’ weather information, and even allowing on-demand and automated information requests. We are looking forward to utilizing this application, as well as learning how others might be using it in earth science and services applications”.
Kelly Sponberg
Project Manager, International Extension and Public Alert Systems (IEPAS) / RANET
Joint Office of Science Support (JOSS)
University Corporation for Atmospheric Research (UCAR)
www.ranetproject.net
For those of you familiar with FrontlineSMS, our new team member isn’t so new after all. It’s Josh Nesbit, the brains behind FrontlineSMS:Medic and Hope Phones. Josh was the original inspiration behind the creation of targeted FrontlineSMS communities of practice when he started applying the software in health, making him the ideal candidate for what we’re calling the FrontlineSMS Ambassador Programme.
One of the down-sides to a discipline which doesn’t insist on “compulsory” fieldwork is the rise of a culture of politics. Losing sight of the bigger picture and becoming embroiled in competitive, overly critical behaviour can be a huge distraction and hugely destructive. Development suddenly becomes a battle of “a versus b” or “x versus y” and not about the alleviation of poverty and suffering that it should be. I steer well clear at every available opportunity, and draw on much of what I’ve seen and experienced over the past sixteen years to do so.