I’m embracing my status as a political scientist working in the Ministry of Information and Communication Technology (MCIT).  While a lot of my experience in the tech space tends to be tool-centric, I’m finding more and more that the challenges on the user end (in this case Samoa) are related to policy and economics.

The main set of policies I’ll be working on the next few months is cyber security and privacy; these haven’t yet been extensively developed in Samoa because until relatively recently there wasn’t a big demand for them.  There are a few basic statutes about information privacy and some criminal statutes, but there’s yet to be widespread public knowledge of them.  For folks looking to do crowdsourcing, and looking to do it ethically, making sure that participants know their rights and the risks of participating is paramount, since folks in many countries (including the U.S.!) likely don’t know the laws regarding data privacy and ownership.  I know this isn’t new, but it bears repeating; budget the time to incorporate an explanation of the ISP and privacy laws into your informed consent process, since the people contributing data may or may not know them.  Doing this is good for ethics, and it helps inform the public which earns you the appreciation of the ministry in charge of public information – wins all around!

I’m also enjoying getting a taste of the economics of internet connectivity in Samoa.  Hypothetically, internet connectivity is universal in Samoa.  Even in places where there isn’t wired internet, anyone with a smartphone could get online via 3G.  I think a mistake we make on the design side is designing tools with universal connectivity in the back of our minds.  It’s not because we’re trying to be exclusive – everyone I’ve worked with in the tech for development space is aware of the limits of connectivity in the developing world, but unless you’re doing at least some of your design work in a developing telecom/internet market (in a rural setting, not the capital), these limits are abstract and hard to design for.  We subconsciously default to the connectivity we know and are designing in.  Here’s a little method I use for thinking about the micro-economics of whether someone in a developing country will use an ICT solution.

Right now high-speed wireless internet is available in Samoa via a microwave transmission system for about $7.00 per hour for unlimited data consumption.  There’s a 3G option; it’s about the same price and is charged by data consumption instead of time.  $280.00 for a working week (8 hrs./day*5 days) of high speed internet is manageable for the UN or NGOs who roll it into project budgets.  But in Samoa, where GNI is $3,160.00 ($263.00 per month) anything that requires a high speed connection is usually going to be out of the economic question given the current costs of internet connectivity.  When I see a new ICT solution for disaster management, e-government or peacebuilding, here’s how I ballpark if the solution might be economically viable:

[(connectivity cost/hour)(#hours to achieve benefit)/monthly income)] < 5% Monthly income

Here’s how I break it out.  5% of monthly income seemed like a good number to come in under; maybe people would spend more during an emergency, but I doubt it (the next pay day is very uncertain after a disaster, so people will be risk averse when using limited resources like money).  Connectivity is a fixed hourly cost at $7.00 per hour.  If I have to use an ICT tool for three hours to achieve the intended benefit, then I have to spend $21.00 on it, or about 8% of my monthly income if I’m in Samoa.  It might be worth if it’s an emergency and I know what I’m supposed to do with the tool.  But if I’ve never used the tool, the opportunity cost of using 8% of my monthly income on an ICT tool before/during/after a disaster is pretty high.  USD$21.00 gets you a few gallons of clean water in Samoa – after Cyclone Evan last year, there was no running water for a month in some places.  If your solution costs someone as much as emergency water rations, and it doesn’t directly solve the water problem, it probably needs to be cheaper to use.

We’re doing some amazing things on the engineering side of ICT4D, and sometimes it can be easy to focus on the tools to the exclusion of policy, economics and culture.  This doesn’t mean that the focus on engineering is bad, but a healthy effort to understand the policies and local economics that affect end users can help us refine the specifications of the tools we build so that people can use them more effectively to respond to disasters and crises at the local level.