9 minute read

I have a critical flaw - not being able to say no to helping out worthwhile projects get their technological house in order.

I’ve left a trail of wikis, content management system-run sites, and creative cabling across three continents. One such effort was in the pre-iPhone world of the early 2000s with a creative social enterprise that empowered artisans to realize the full market value of their goods (often undercut by middlemen taking advantage of innumeracy, a need for liquidity, or both). These goods are then shipped to the US to sell. The NGO takes a small cut for its operations and the shipping cost, and everyone benefits. Beyond dealing with the unpredictability of the Nicaraguan electrical system, they were efficient in their offline practices, but saw the need for inventory tracking. That seemingly basic task is both a key to empowering online sales and other scaling activities, but is no short order. The system must be able to know what items were stored in what locations in the US and in Nicaragua, and meet the needs for a geographically disperse set of volunteers to sell those items at events. It also has to have a simple and largely foolproof way of adding inventory from the Nica office that can absorb a backlog of work if the power or Internet connection is off.

Web 1.0: Cue Cat No problem - totally doable. For the US side, we work with a Salesforce Foundation volunteer to create an online, cloud-based inventory system where the volunteers can log transactions live on the site using a re-purposed cue:cat barcode scanner – the cue:cat itself being a dotcom-era QR code wannabe, best summed up by Jeff Salkowski of the Chigao Tribune as “You have to wonder about a business plan based on the notion that people want to interact with a soda can.” and by Wired’s Leander Kahney as “a cheapo bar-code scanner that looks like a marital aid.”

On the Nica side, the staff can add the inventory on a spreadsheet and batch upload it into SalesForce whenever they have power. This gives them an offline backup, and lets work continue (on a laptop) even if power cuts out. The Excel sheet automatically creates a code that can be barcode-ified for matching by the volunteer sales staff without painstaking scribbling of notes.

We’re in this to save and improve lives, not make a profit. If a plan fails, it’s lives lives - not just bank accounts -- that are not enriched.

Perfect, right? With so much time spent on the “challenging” part of the equation in Nica, not enough thought went into the sales side - often outside, at craft markets, sometimes in the rain. Not happy environments for laptops, rarely enough electricity or battery power to last the day, and never any wifi to actually connect to the Internet to track sales in realtime.

Times have changed, and the plan, like the cue:cat itself, may have a new life in our 3G-saturated world with QR Codes and Square point-of-sale gadgets replacing the bulky laptop, but at the time, it was simply a failure.

What do you do when your project just falls flat? Moving on and hiding it is the wrong answer. The right answer is that you get up in front of a crowd of your peers, donors, and investors (past and potentially future) and spill the beans. In the startup world, some amount of failure is expected, and even welcomed. Learning from failure is, after all, the best education out there. But in the do-gooder space of non-profits and international development organizations, failure is not an option.

The challenge is that we’re in this industry if you will to save and improve lives, not make a profit. If a plan fails, it’s lives lives - not just bank accounts – that are not enriched.

There are obviously failures in development, as evidenced by the mere fact that we’re five to six decades in to concerted global efforts, and still working on it. More ICT4D projects fail than ever scale beyond the pilot stage. The World Bank bravely released its internal study revealing that while most of its projects succeed overall, in the ICT4D category of projects, only achieve their intended outcomes 30% of the time. Some of those may be wildly successful in unanticipated ways, others just complete flops.

Katrin Verclas has done the community a huge favor in creating and open-sourcing the concept of the FailFaire.

The Failfaire celebrates and de-stigmatizes failure by loosening lips with some alcohol and then throwing people on staqe for a tightly scheduled 5 minute moment of candor. Thanks to the open-source philosophy, these have spread to internal organizational events as well as a few public failfaires, most recently one hosted by Inveneo’s Wayan Vota in DC at the World Bank itself, and another coming up this December in NYC hosted by MobileActive.

The risks of failure in development work are clearly weightier than Q3 profits,which makes the relaxed, raucousness of a failfaire that much more important. For a community that has no normal mechanism for learning across the various implementers, the only way we can advance the whole cause is through these commiserations over good goals, good people, and solid technology completely failing - and learning from them.

This was best encapsulated after the event. One presenter discussed his media-darling pedal-powered phone booth for remote villages, which was a complete failure. Another Failfaire-er approached him afterwards to commiserate on similar problems - their own popular bike-powered computer system actually took almost seven people pedaling to reliably power the system. While bikes garner tons of often-misguided warm feelings and media popularity, they aren’t necessarily silver bullets – a lesson for the road.