I’ve been at ACM DEV – listening to people talk about some spectacular successes. My favorite is of course Captricity, which processed my survey data from Uganda last year. (We won’t mention how the turkers mangled the Ruyankole village names). In fact, the only ‘failures’ mentioned today centered around OLPC and technology for education. I liked Kentaro’s point that educational content on computers (whether in desktop, laptop, or tablet form) competes with games for attention. We like to hope that these games are ultimately educational (as a kid I wrote a timed math drill game), but I’m not sure that TapFish, Angry Birds, and Triple Town are genuinely educational. Angry Birds teaches physics about as much as throwing a ball at some stacked bottles.
And yet – the X03 tablet, presented by Ed McNierney of OLPC, is intriguing. Interactive content, software keyboards, and ebook support all seem like potentially interesting contributions for um, everyone (however, I might suggest that a matte screen would be better for the natural light conditions than a reflective one, even if the mirror surface does look nice). Maybe the Linux platform will Angry Birds from draining the battery – but I remember being entertained for hours on end with snake and with robots. However – I really homed in on Ed’s stories of OLPC failures. Solar panels working too well caused the OLPC to shut off in the high altitudes of Peru. Displays failed in Uruguay because students carried them in bags that bounced against the horses they were riding to school. Laptops took longer to charge than expected because they daisy chained power strips, charging all the laptops off of one outlet. The hand crank broke off in Kofi Annan’s hand. They’ve worked hard to make the XO laptops as rugged and forgiving as possible – but surprises still crop up.
What makes a fail? Is it failure to anticipate? By now we all expect to be surprised by creative ways people use, break and appropriate technologies. It’s not possible to anticipate everything when our own contexts are so different from the places where we conduct our studies. I think a good fail happens when we’ve prepared, read the related literature, and bring experience to the table. A better fail is when we take time to think about why something might have failed – and share our insights with others. Bad fails happen too – when we just aren’t prepared, or when we fail to learn from our experiences. We’ll hear some great stories at the FAILFaire – and if you make it to CHI, I’m presenting a paper on the failure of Claim Mobile.
A while back, Clint put together a video of the Top 7 Reasons Why Most ICT4D Projects Fail. It’s worth a review if you haven’t looked at it recently.
- Results not directly tied to improving economic condition of end user
- Not relevant to local contexts, strengths, or needs
- Not understanding infrastructure capacity
- Underestimating maintenance costs and issues
- Projects supported only by short-term grants
- Solutions are not looking at the whole problem
- Projects built on condescending assumptions
Honestly, it’s hard to truly understand local contexts, strengths, capacity and needs – especially when these often change over time. It’s also easy to underestimate ongoing costs – often Operations just isn’t our area of expertise. Short term grants are another issue entirely – one DEV author on Sunday pointed out that one of his partners ran out of funding, and was no longer a viable partner. So the question remains, how can we get better at what we’re trying to do – avoiding widely recognized traps, and ably responding to unexpected outcomes. In many cases, experience in the field helps a lot – but no amount of experience helps if we fail to learn from one another’s failures. And so with that note – I encourage you to drop by the FAILFaire at ICTD this afternoon. See you soon!
