Do the majority of people working in “mobiles for development” work in mobile, or development? It may seem like an odd question, but how people approach “m4d” may have more of an impact on success or failure than we think.
The world of social mobile isn’t short of anecdotes. “Put the user first”, “Consider the technology only at the very end”, “Don’t re-invent the wheel” and “Build with scale in mind” are just a few. Ignore these and failure won’t be far around the corner, we’re told. But maybe we’re missing something here. Sure, there’s a growing number of ‘best’ practices, but one thing we rarely seem to question are the very credentials of the project origin itself.
Everyone from donors to project managers and technologists to journalists are keen to identify traits or patterns in ‘failed’ mobile projects. Many of their conclusions will point to poor planning, poor technology choice or lack of collaboration, but sometimes the biggest failure may have taken place long before anyone got near a mobile phone.
What I wonder is this. Do we know what ratio of “m4d” projects are initiated by development practitioners (or sectoral experts in health, agriculture, conservation and so on) as opposed to mobile technologists, and what impact does this have on the success or failure of the project? In other words, if the problem solver is primarily a mobile technologist – the “m” part of “m4d” – then you might assume they have much less understanding of the on-the-ground problem than a development practitioner or sectoral expert might – the “d” part.
Does this bear out in reality? If failure does turn out to be higher among technologists then this is a relatively easy problem to fix, whereas many of the other perceived reasons for failure are not. It’s all about getting back to basics.
(Click here for more observations on mobile development).
I’ve always maintained that the people closest to the problem have the best chance of coming up with a solution, and this probably bears out in many cases, particularly in the ICT4D field. Ushahidi, started by Kenyans to solve a Kenyan crisis – and DataDyne, a health-based data collection solution designed by a paediatrician – immediately spring to mind. In these instances, being up-close and dirty with the problem came well in advance of any technology-based solution to it. The same goes for our very own FrontlineSMS initiative, borne out of a series of visits to South Africa and Mozambique back in 2003/2004.
In any discipline, the greater the rate of innovation the greater the problem of focus, and mobile is no exception. As Bill Easterly put it in a recent post in response to questions from students about how they might help “end world poverty”:
Don’t be in such a hurry. Learn a little bit more about a specific country or culture, a specific sector, the complexities of global poverty and long run economic development. At the very least, make sure you are sound on just plain economics before deciding how you personally can contribute. Be willing to accept that your role will be specialized and small relative to the scope of the problem. Aside from all this, you probably already know better what you can do than I do
This is great advice, and not just for economists. If mobile and health is your thing, focus on health and get very good at it. If it’s mobile and agriculture, or mobile and election monitoring, do the same. Whatever your area of interest, get out and understand the issues where they matter – on the ground – and don’t get totally sidetracked by the latest trends, technologies or disciplines. Whatever the reason for your interest in ‘mobiles for development’, make sure you don’t forget the importance of understanding the ‘development’ bit.
Focus is highly underrated, and often debates around technology choice, open source, challenges of scale and “understanding your users” are distractions from a much-less discussed but equally vital question. And that’s this.
“Who’s best placed to run a successful “m4d” project – the m‘s or the d‘s?”.
Great points, Ken (as usual) — and thanks for the shout regarding EpiSurveyor. I’ve followed up on your thoughts back at our blog: http://datadyne.org/blog/frontlineandepisurveyor
Joel
@Joel – Thanks for the positive response, which I hope wasn’t entirely influenced by the shout for DataDyne. 😉 But on a more serious note, some of these things do need to be discussed, but rarely are. Let’s see who else in “m4d” has an opinion on this.
Ken, Ken, Ken: you think we’re THAT easily swayed by mere shout-outs? Tsk, tsk.
No: your post was spot on, and spurred me to write down some things I’d been thinking for some time (which is, all things considered, exactly what one hopes a blog post will do). Now, then: enough of this mutual admiration society and back to work!
j
R/T @kiwanja Who’s best placed to run a successful “m4d” project – the m‘s or the d‘s? Time to get back to basics. http://is.gd/efRit #m4d
Good points, but to clarify–what you’re talking about are success/failure of m4d projects rather than m4d tools.
Any vertical user of those tools (whether they be an NGO or an entrepreneur) will be much better prepared to use them in the most effective and productive way given their expertise in that vertical.
But I think that the ‘mobile technologist’ has a vertical of expertise as well–building mobile tools in this case. So they have a role, but it’s likely not in getting involved in trying to apply those tools in particular projects or areas outside their expertise.
For disclosure, I consider myself a ‘mobile technologist’ so that may explain my position to some degree. 🙂
@Matt – Thanks for the comments. Interestingly, you’re not the first person to say that mobile technologists are likely not best qualified to do deployments. I agree they have a role in developing tools, but it’s important that they understand the conditions under which their tool will be used. If they don’t have that, why would they build one in the first place?
Perhaps it’s time to break down “m4d” into roles, and define what each does and the value they bring. People working in the space can then say where they fit.
I think we need both. The approach used by development and that used by tech seem to be coming from totally different angles a lot of the time. If the two sides can do more listening and learning from each other, initiatives will be more successful… It’s critical to understand local context and engage end users throughout the process.
Maybe OT, but: saw this on your FB page, then searched for the original post on your blog here and saw “27 comments” – only to realize that about half of them are retweets.
I feel something similar about most m4d projects: a lot of hype (which isn’t bad) and sexy keywords, but are these really succesful? What are their (real & neutral) indicators for a success?
I sometimes wouldn’t want to be in your position where you have to deal with ppl who are used to quick wins, only knowing that some things can take month to develope, and other are done within two days (Ushahidi 0.1, for instance). I think it’s not the mobile technologists, but the audience/readers that need to be slowed down in their wish “to end world poverty”.
@Linda – Totally agree. I think the problem is that most projects *seem* to be instigated by “mobile experts” rather than development practitioners. By that, I mean people who get excited about the technology and an urge to do good. Most development people I’ve met and got to know (particularly those working in the field) are too busy to spend their time getting their heads around new technologies, and are often less likely and in less of a position to speculate with a new mobile-based project or initiative.
In short, I think we have “mobile experts” and “development experts” but there’s no such thing as a “mobile for social change” or “mobile for development” expert. If they need to meet in the middle then surely the biggest challenge is how, because they don’t seem to be too much right now.
@jke – Fair point on the comments/tweets. I need to find a new plug-in which separates them out. As to your wider point, see my comment above in response to Linda. I did write another post which you might find interesting/useful, too:
http://www.kiwanja.net/2009/06/the-folly-of-finding-what-works/
Ken, I totally agree and I see it time and time again. Just last week in fact. :-). I do think that this will change over time. I’m serving in that exact role right now (as are you!). I’m a ‘development person’ that is getting my head around the ‘tech’ side so that I can better advise and support our staff on the ground and bridge those two areas. I think over time we’ll start to see more people emerging in that sort of a role, but the tech folks need to get some ground experience, and the ground folks need to get some tech experience. For now, we can’t all be experts in everything, so we need to really work together as partners. But seems there is still a lot of mistrust across the divide. I sometimes think that the mistrust comes from those very different approaches to design. One is slower and more measured, with cautious steps, building on what’s gone before, looking at constraints and designing what can work within them, moving at the pace of the community. The other seems to be more about blue sky thinking and a need to invent, solve puzzles and challenges, and to not allow oneself to think about any constraints during the design process, to try and to fail early and often. I am struggling to find the best way to marry those two, as both have their strengths and weaknesses….
Linda, I totally agree. M4D is still a relatively new space, so the m’s by nature don’t really understand the d side too well, and vice versa. But it’s inevitable that technologists will get into the field more and more — and engage in discussions like this more and more — and start to understand the complexities of development work. And the development practitioners will start to find time to understand these technologies that they are coming across more and more in their daily work. Soon enough, some will be skilled enough in the other’s field to be able to really bridge that gap.
I come from a journalism background, and I see clear parallels with what happened in that field over the past decade as technology smashed headlong into one of the oldest and most intensely tradition-steeped fields out there. Over 10 years we’ve gone from newspapers simply cutting and pasting their content onto Web sites to entire magazines written and designed for mobile devices like the iPad. Every J-school teaches dozens of courses linking technology and journalism; some have entire masters programs devoted to it. Some of the most sought after journalists of the past decade have been the ones that could span the journalism and tech sectors — the early adopters, so to speak. In the next decade, they’ll be a dime a dozen, as the two fields have been essentially coupled.
I see the same happening in the development field. Technology is too powerful a force to be ignored for too long. It will edge its way into the development field bit by bit — and then faster and faster — until we wake up one day and realize it’s as natural to talk about m- and e- as it is to talk about M&E.
But that raises another question in my mind. Will it necessarily be “m” that gets integrated into most development work, or will it be some other form of tech? Who’s to say — the tech space is so fluid that something could always come along and supplant mobiles as the big difference maker (as @jke said, Ushahidi took only 2 days to burst onto the scene, and it has transformed the tech4dev landscape). But my hunch is that mobiles will become and remain central to many development strategies for many years to come because they’re widely accessible, even in relatively poor communities, and they seem to have inserted themselves rather seemlessly into centuries-old cultures, probably because their primary use — oral communication — is something that is extremely highly valued in most of those communities. Wonder what others think.
And since we’re at it, I’ll throw this one into the mix too: should we be thinking more about designing for tablet computers in developing countries? I want to head what both the “m”s and the “d”s in this conversation think!
I know I’m a little late to the party here, but I think that both sides bring very different strengths to the table and that they are important at different times in the project. I feel lucky to have a long history in IT (Though not mobile so much) and am now fully on the D side of things. I think that technologists can bring great tools to the table, but can sometimes be so wrapped up in the “What can we make this software do?!?” mindset and not as much in the what SHOULD we make the software do. Thinking about all the cool thing that are technically possible without context of the problem on the ground or the people who will be using it. Enthusiasm is great, but getting carried away is bad. On the mHealth projects I’ve worked on, I felt like when talking to the tech guys who were going to go and code things based on our research into the problem that I just kept telling them to keep it as simple as possible. I just kept saying, don’t make it do too much, don’t try to replace all the systems that are in place and that work, try and work with it. So, I think that the tools developed my M folks really need to be informed by people who have spent the most time near the problem (either M or D) and to try to not get carried away by the awesomeness of what they could code.
On the other side, if you have D people without any M input, you get requests for tools that don’t take into account the difficulties of doing tech based work in resource poor environments. Often times if there is no one to reality check the stability of a server running in rural Tanzania (power, interesting ISP reliability, etc) you can have a project that fails due to unrealistic expectations.
I guess overall I think that the M folk should keep coming up with cool tools and let the D folks think of the m4d community as a huge toolbox, you don’t need everything in the box for every program and you might even wonder why the hell you ever bought a micro-beveler, but there is the right tool for the job somewhere in there, even though it might need some customization.
ken:
i believe you have already answered the question in your post: “get out and understand the issues where they matter – on the ground”
the persons best placed to successfully impement any project is someone who keeps the focus on ‘people’ [their needs & aspirations]. or as you put it: the ‘issues’ at hand.
it doesn’t matter if they come from a Dev. or a Mobile background, as long as they grasp the ‘issues’ they should be able to find a solution to the challenges on-the-ground in collaboration with the ‘other’ side [mobile/development]. so it is the ‘P’ who is going to be the champion – in my view.