MobileActive.org’s FailFaire was featured in a January 15th article in The Chronicle of Philanthropy. Covering FailFaire’s success at bringing together nonprofits to openly and honestly discuss failure, the article calls the event “remarkably frank.” If you’re curious about what goes on at a FailFaire, check out this article to read more about the benefits of learning from failure.
FailFaire – where it’s okay to admit the mistakes. MobileActive hosted another round of FailFaire, bringing together practitioners, developers, donors, and students involved in the use of technology for social change development to discuss what’s usually swept under the rug – project failure. The event is an open space to discuss those projects that went wrong in our field fostering a sense of learning from mistakes and knowledge sharing. The latest FailFaire in New York brought together eight practitioners to present their failed projects and what they learned along the way. Take a look at this FastCompany article about the NYC FailFaire for some background.
So, here we bring you…
1. The project wasn’t right for the organization (or the organization was not ready for the project): How does a tech-for-social-change project fit in with an organization’s structure and goals? The UNICEF Innovation Team started off our FailFaire night by discussing a project that the team originally tried to place in UNICEF’s Water, Health and Sanitation Department only to later learn that it worked better as a post-disaster recovery device since it had little to do with the day-to-day work of the Water, Health and Sanitation Department. Understanding where a project fits in with your organization, who the key stakeholders are, and the target deployment area can help decide if a mobile or ICT tool makes sense for the goals of the organization.
2. Tech in search of a problem: Is the introduction of technology in a project actually solving a problem? Ask end users how the project will work in their day-to-day lives and if it is necessary and needed. Although technology is often a “sexy” option, a low-tech solution may be a better choice.
3. Must-be-invented-here syndrome (aka not taking advantage of existing projects and tools:) Many organizations spend considerable time and resources developing tech in-house that already exists. Since many organization’s core competency is not technology per se, many of these projects shave time and money overruns or fail outright. A case in point: Bryan Nunez of Witness spoke about building The Hub, a human rights-focused social media and video site; the organization later realized that leveraging existing tools like YouTube and FaceBook might be better strategically and save the organization considerable time and money.
4. Know thy End-Users! Allison Stone of MoTeCh discussed the failures in a maternal health and data collection project that ran into problems with both the community health workers tasked to enter patient data, and the women patients who received alerts on their phones about pre- and ante-natal visits. The conceptions and available data about mobile usage of women in Ghana didn’t reflect the reality on the ground. Many women were not comfortable replying to text messages or had only limited access to a phone or electricity to charge a phone. Likewise, community health workers found the project added to their workload rather than saving time.
A key theme throughout FailFaire was the importance of working closely with end users throughout the design and development so that projects reflect their needs, address their points of pain, and the reality of their technology use.
5. Trying to please donors rather than beneficiaries (and chasing small pots of money): A common theme heard throughout FailFaire was difficulty of retaining adequate funding all the while trying to build scalable and sustainable projects. Mobile tech in particular is sexy for donors right now but not particularly strategic or knowledgeable about appropriate use of mobile tech to address specific issues and may push organizations into tech projects when less tech would be actually better. Presenters advised being careful and choosy while seeking funding, and against chasing after lots of small grants and prizes.
Several donors in the room also suggested a ‘Failfaire’ for foundations and donors – an idea that we wholeheartedly endorse.
6. Forgetting People (or – where is the human dimension?) A number of speakers noted that technology doesn’t change basic human behavior and motiviation. Stephen Hamill of the World Lung Foundation discussed his organization’s FaceBook campaign that allowed user-generated pictures of suffering from the effects of tobacco use; despite the buzz around the project, people ultimately didn’t want to post unattractive or disturbing photos of themselves or their friends and family on their social media profiles.
7. Feature creep (or: Too many bells and whistle): Less is more and agile, modular development is good. (Even though it was noted that mentioning the word “scrum” once does not make a project agile!) Speakers emphasized keeping features focused and simple and goal oriented rather than adding extraneous bells and whistles that take up time and money, and make development more difficult. Presenters also noted that tech projects run by committees are not a good idea and emphasized the importance of tight and competent project management for tech and tool development.
8. Lack of a backup plan: What will you do if your project hits a roadblock? Henri Makembe spoke about using SMS election monitoring in Benin (full disclosure: MobileActive.org was involved in the project). When the Internet went down during the election, many of the submitted SMS reports were lost due to FrontlineSMS’ limitations to storing data for API calls, and so SMS that were sent in did not properly transmit to the online database and mapping tool we used. Makembe spoke about how we had not built in a sufficient contingency plan for the eventuality of the Internet failing during a critical time period, and that having a backup plan could have saved the data. Simulations and building in storage redundancy would have been smart to do!
9. Not connecting with local needs: Ian Schuler (formerly of the National Democratic Institute) spoke about launching a crowd-sourced election reporting campaign during the 2007-2008 Kenyan elections that turned out to not be particularly popular. Dropping in technology without the involvement of a local community meant that no one responded.
10. Not knowing when to say goodbye: Several of the presenters spoke about how once it was clear that a project wasn’t working, they continued to try to save the project even though it was taking up time and money. Understanding when a project has failed and letting it go is a hard-win skill that we often lack in this field.
Thanks to our presenters who kept things light-hearted while discussing how projects can go off the rails: Chris Fabian of UNICEF, Ian Thorpe of the UNDG, Stephen Hamill of the World Lung Foundation, Bryan Nunez of Witness, Allison Stone of MoTeCh, Henri Makembe of the Beekeeper Group, Oscar Salazar of CitiVox, Ian Schuler of the US State Department (and formerly National Democratic Institute).
And – if this inspired you: FailFaire is entirely open source. Please feel free to host your own! Check out our guide on How to Roll Your Own FailFaire for ideas and tips for a successful event fostering honest and open discussion about failure.
FailFaire gets people talking – the casual, open event allows attendees to talk about failure in non-profit ICT4D and M4D in a new way, presenting mistakes in a learning environment. Our second FailFaire, held in Washington, D.C. with the World Bank, followed a similar layout to our New York City event with presenters, representing either themselves or their organizations, giving quick speeches on non-profit projects that burned out, never got off the ground, or had unintended (and unwanted) results.
Now, people are taking notice of the benefits of hosting a FailFaire.
The New York Times wrote an article about FailFaire and since then, we’ve seen the story picked up in many other places. Even more encouragingly, we’ve heard other sectors talking about how FailFaire could be adapted to more than the non-profit world. The Columbia Journalism Review wrote about how the journalism profession could use a FailFaire to navigate the changing face of the media industry. Voices for Innovation wrote about how the FailFaire approach could be useful in business, health, and public sector work.
The story was also picked up and re-reported on several blogs, including Next American City, the Chronicle of Philanthropy, WorldChanging, and the ICT4D Jester. The positive response has been great, and we’re glad that the FailFaire idea has caught on so well.
If you’re hosting a FailFaire in your industry, please let us know – we’d love to see how the idea adapts across sectors (and check out our how-to guide to creating a killer FailFaire for ideas).
Here’s what some of our Twitter followers are saying:
So, you heard about FailFaire. You liked the idea of learning from failure in a not-so-earnest setting and want to have your very own FailFaire, or you think that your organization could benefit from an internal event. Here are some tips for rolling your own.
Caveat: We have now organized two FailFaires for our community of practitioners who work with ICTs and mobiles for international development, because that community is our audience. And because part of our mission here at MobileActive.org is to help reduce redundancies, build capacity, and advance the field. We also happen to work in an area of the NGO sector where failure is not often discussed honestly.
But the FailFaire concept can work for any field or, maybe just as helpfully, within any organization. (Note, of course, that some of the suggestions listed below will differ for an internal event, rather than a public one like ours.)
The FailFaire name and logo are licensed under a liberal Creative Commons, so feel free to use them. You do not need our permission. For tweeting, blogging and posting event pictures, we have used the hashtag “#failfaire.” If you are running an event branded as FailFaire, feel free to drop us a line (or leave a comment) to let us know how it went.
Here are some thoughts and tips on how we approached FailFaires.
1. Start With a Lot of Personal, Old-Fashioned, Direct Outreach for Both Participants and Presenters.
Identify those in your network who are more agile, less bureaucratic, and less resistant to talk about and learn from failure. Have many conversations to introduce/warm them up to the this radical new idea long in advance – perhaps before you’ve even set a date. Explain the concept, the goals, and the format of the event. Gauge whether there are enough supporters who will a) participate, and especially b) present. This process is critical in order to get to #2: You need buy-in, advocates, people who are into it early on.
2. Have the Right People in the Room.
You want people who are there to learn, not to be voyeuristic; there to be constructive, not to be snarky or malevolent. People who genuinely care about their work and want to do better. People who are ok with some irreverence and humor, because failure is hard to talk about without it. This type of event is great for building (or strengthening) community, so try to keep the audience targeted and relevant to your focus or topic. Promote the event among people you think will get the most out of it – those who value different ways of learning.
3. Plan the Presentations/Case-Studies.
To confirm a stellar line-up of smart, honest and brave presenters for both FailFaire NYC and FailFaire DC, we made both an open solicitation for presentations (online or email submission) and sent personally tailored requests to some of our contacts (refer to #1 above – it’s all about relationships!).
It helps when the presenters are people who have also had notable successes. As an attendee at the first ever FailFaire in New York noted: “It’s easier to admit your failures when you are self-confident, and you will also have credibility because of your successes.”
We ask our presenters to focus on the storytelling aspect (and not worry too much about the slides) to help personalize and illustrate the major lessons and take-aways. Tell us:
• What was the project?
• What were you trying to do?
• What was the fail/where did it go wrong?
• What would you do differently next time (or never do again!)?
• What lessons can be learned?
We are partial to the “ignite” style format – quick presentations at 10 minutes or shorter. We called it a “FAIL-slam.” (Again, organizations hosting internal FailFaires may chose a different format in order to maximize learning and promote actionable lessons that can be embedded into future work). Everyone’s mental wheels will be actively turning by the end of the presentations, so make sure you leave time for questions and discussions around the room.
4. Set Ground Rules.
To make sure everyone is aware of how his or her presentation will be received, it’s important to set a few ground rules so that everyone is on the same page. Ours include:
• No live streaming of event.
• Blogging/tweeting allowed unless someone says that a presentation or parts of the the presentation (or a comment, question, or discussion) are off the record.
• For pictures, ask permission before taking so that anyone who does not want to be known to have presented or attended isn’t inadvertently outed by a photo.
• No third party bashing – presenters must have been personally involved in the project they are showcasing in some way.
• Slides will not be made public unless the presenter him/herself puts them out there. We actually have destroyed the digital copies of slides, especially of those presentations that are off the record.
• It’s perfectily ok for presenters to be there in their personal capacity rather with their organizational affiliation and say so.
You can set your own rules based on how public/private you want your FailFaire to be – just be sure that everyone knows the rules up front.
5. Create an atmosphere.
Even though this may be a bit controversial among the more dour types, we have emphasized creating a safe space in a neutral, nonthreatening venue (for example, don’t pick the board room). We think it might be best to host the FailFaire outside of an office setting all together. Provide drinks (trust us, it helps) and food to encourage chatting, networking, and the loosening of ties and guards. Enable real conversations – no formal nametags, tentcards or overstructured agenda elements. We are a fan of hosting FailFaires in the evening, after formal work hours, and start with at least half an hour of friendly mingling and a glass of wine before presentations even begin.
6. Have The Right Attitude and Tone.
There should be a real commitment to LEARNING from failure. Make it clear that failure is no reason to be ashamed, and reinforce the belief that there is value in learning from mistakes. Balance levity with responsibility – allow yourselves to laugh at mistakes, and cut yourselves a break without losing sight of the gravity of failing, In our field, there is trust, people’s livelihoods, donor money, and even beneficiary lives on the line if we fail. At the same time, talking about failure can be very hard and making it easier with a gentle way to make fun of ourselves can help. Again, this is something that is not for everyone and in some cases, not appropriate.
7. Choose a Moderator/Host.
It’s important to have a moderator to keep the schedule moving, set down the ground rules, emphasize the goals, and make people feel comfortable (humor really helps!). If necessary, the moderator can close down unhelpful comments in a firm but friendly way (this is about learning, not about blame or criticism).
The moderator should be someone neutral who either doesn’t have skin in the game (for example, if it’s an internal event, not someone who can hire/fire), or works with or in support of the community/organizations represented in the room but not in a position of being a funder/donor, etc. Avoid anything that can alter the dynamic of the participants or cause people to censor their remarks for fear of looking bad.
Conclusion
In the end, we work hard and we care about our work. It’s only going to help us improve if we share and learn from things gone wrong rather than sweep them under the rug. Hosting a FailFaire can be a great way for your respective field or organization to openly discuss failed work and learn from the past, especially in the nonprofit and NGO fields where we are so reluctant to discuss our shortcomings in any public (or constructive) way. Good luck, and let us know how you are faring!
Talking about success is easy, but talking about fail is more fun (and definitely more cathartic). On Monday, July 26th, MobileActive.org hosted a FailFaire in Washington, D.C. together with the World Bank Institute. The event brought together developers and practitioners in the ICT4D field in an open and relaxed environment to talk about those times when projects didn’t go according to plan.
Presenters gave quick, Ignite-style talks about projects that had unintended outcomes, failed to meet the needs of the local community, or never got off the ground in the first place. FailFaires are interactive, take a lighter approach (because failure is hard), and allow presenters to share what they’ve learned in a supportive, engaged environment.
The winner of ‘best presentation’ as voted by the attendees, was the World Bank’s very own Michael Trucano, who presented “Worst Practice in ICT Use in Education” a guide on how to fail in ICT4E. Highlights from the rapid-fire, 50 slide (yes, 50 slides!) presentation included: “ Dump hardware in schools, wait for magic to happen,” “Think about educational content only after you have rolled out your hardware,” and “Make a big bet on an unproven technology (especially one based on a closed/proprietary standard) or single vendor/ don’t plan for how to avoid ‘lock-in’.” Attendees tweeted along with the action:
Other presentations focused on issues such as not adequately anticipating gender inequality in local communities and failing to build sustainable models with local buy-in – issues well familiar to those who work in international development.
InfoDev’s Tim Kelly gave a presentation on the difficulty of global scaling called “Global Capacity Building Initiative for ICT Regulators” – the project never got off the ground. He started by pointing out that there is often the temptation to “go global” in our field, but that the project would have been better if it had started smaller. Wayan Vota presented on his personal experience developing an online forum that missed its target audience – he found, for example, that most of the people he was trying to engage (local decision makers) were not involved in the online community.
The D.C. FailFaire also featured “miniFails” – short, five-minute looks at one small fail within a larger (and often successful) project. Rachel LaBruyere from the Fair Immigration Reform Coalition presented a translation failure – a poor translation of the word “unsubscribe” into Spanish that caused over 2,000 people to unsubscribe from FIRM’s mobile list. The word (“alto”) the organization choose for “stop” (i.e., “unsubscribe”) actually had a passionate connotation. So some people texted ALTO as a sign of solidarity, not because they wanted to be off the list.
So, why does an event like FailFaire matter? It creates an open environment where practitioners can speak freely about why some projects fail. This kind of openness in the ICT4D community can help others avoid the pitfalls that lead to wasted time and resources. As a community of practice that we have worked hard to establish, we find it incredibly useful to not just tout our successes (which we should and do) but also to be honest and forthcoming about where we fall short and what we could do differently.
But don’t just take our word for it – we are the organizers, after all. If you want to see what other attendees are saying about the D.C. FailFaire, check out TechChange’s blog or Anand Varghese’s recap. Thanks to all who came, and for making FailFaire not a #fail but indeed – a success!
(Written with Anoush Rima Tatevossian and Katrin Verclas)
(This article originally ran on MobileActive.org on April 16, and was written by Ian Thorpe)
On Wednesday evening I was lucky enough to attend the first ever “Failfaire”, organized by MobileActive.org, where several brave souls agreed to present their failed “Information Technology for Development” projects, explaining why they failed and what they learned from them.
I work on knowledge management at UNICEF, and have a strong interest in improving how we learn from our experience. This event (which was certainly not a failure!) was interesting to our work from at least two points of view:
1. The lessons learned from the projects themselves.
2. The idea for the event itself and whether this might be something we could try ourselves.
There were four presentations during the meeting:
Bradford Frost presented on Mobileimpact.org, a project to recycle old cellphones and donate them to Africa.
Matt Berg presented SMS Billboard, a project to use SMS technology to replicate the famous Liberian billboard blog in Kenyan villages, and PennyLED, a project to help power low cost lighting to the rural poor.
Chris Fabian and Erica Kochi of UNICEF presented “Our Stories,” a project to collect 5 million children’s stories.
Ian Schuler presented a project to use SMS to collate election monitoring reports in the Montenegrin independence referendum.
A few shared lessons emerged which might also seem familiar to us in UNICEF:
• Good intentions, a great idea, and great branding don’t necessarily make a good project. You need to focus on planning and execution and see whether you know how to do the project and whether it makes sense.
• Market research is needed. Before embarking on a project its important to ask yourself if there really is a need or demand for what you are doing, and whether there are already other solutions out there that might meet the need cheaper or better.
• People – not just technology – and process. Finding the right partners, listening to them and engaging them are critical success factors. A project that works well in one context might be ineffective in others if you don’t have the right partners and you don’t engage and make use of the skills and knowledge of the people you are working with.
• Make sure to pilot and test. Before scaling up a project, or before using it in a critical setting, make sure to have enough time to thoroughly test it and work out the kinks.
• Beware of “zombie” projects. If we are too attached to a “good idea” and have invested a lot of effort we are often unwilling to admit it is a failure and let go of it, and it keeps coming back from the dead, or it limps along unsuccessfully, not fully supported but still consuming valuable resources.
• Failures can lead to future successes. While a particular project might fail it can lead to new innovation and subsequent success. Look out for the learning and for the unexpected successful spin-off opportunities.
Some of these lessons might seem obvious with the benefit of hindsight – but it doesn’t stop them from recurring in development work.
As to the idea behind the event, I’m a strong believer in the value of learning from our mistakes if people would be willing to admit them and share them with others. This is challenging within a large publicly funded organization that places a lot of emphasis on delivering results and holding people accountable for them, but if we don’t do it we are at risk of continually repeating the same mistakes and in keeping alive our zombie projects because no-one wants to admit they are failing.
In terms of fostering this, I did get a few useful tips which came from the event itself:
I’m now trying to plot how we can organize something similar within UNICEF. I’m sure we must have some juicy failures we can learn from and laugh about!
MobileActive hosted the inaugural FAILfaire last night, bringing together mobile technologists and NGOs to talk about failed projects in M4D and ICT4D. Presenters talked about their failed projects, answering the questions: “What was the project? What was the failure? Why did it fail? And what would you do differently next time?”
The event was filled to capacity with more than 70 people. The five presenters made us think (and laugh), and the audience asked some great questions. For those of you who couldn’t be there, here’s a quick look at the failed projects presented at the first (of what we hope will be many) FAILfaire.
Bradford Frost: MobileImpact.org? Not exactly…
Starting off the evening was Bradford Frost, who told the story of his failed non-profit venture, MobileImpact.org. The goal of his project was to bridge the gap between people trying to recycle used phones and developing countries. He felt he had a strong idea and a strong brand with the tagline “One phone. Change the World,” and that there was enough of an untapped phone recycling market (the current cell phone recycling market only captures about 25% of reusable devices) for the project to succeed.
However, the project didn’t work out as Frost had hoped. He used Facebook ads in order to target a younger, social media-savvy audience. He spent 1,000 dollars to launch an ad campaign and $5000 in a partnership with a phone recycling company. In the end, the non-profit gathered 131 phones valued at a sum total of …$252. And many of those phones were donated through word-of-mouth connections (friends and family) rather than people who saw the Facebook ads.
The low response and low quality of some of the donated phones made this a financially unsustainable project. He says that some of the failure came from not recognizing early warning signs – it was difficult for him to find partners to back the project, and it eventually folded. We also wonder that given the low prices, ubiquity, and phones-as-status symbols in many countries make recycled phones desirable at all. Brad ended his presentation joking, “I shudder when I hear people say ‘I want to start my own non-profit.’”
Matt Berg: SMS Billboard/Penny LED… #fails
Matt Berg (who we recently covered for his success with ChildCount and ChildCount+) presented two projects, SMS Billboard and Penny LED. The SMS Billboard launched in Ghana; Berg wanted to take a village billboard system (inspired by Alfred Sirless’ system of using billboards to share village news and photos) marry it with RapidSMS. This would allow villagers to have access to information more quickly than if reporters were sharing the news by mouth, expanding the scope of the billboards. However, the RapidSMS billboards didn’t catch on. Berg attributes this to being unable to recreate the level of passion and commitment to the news that Sirless and his sources had for the area, saying, “You can’t recreate passion.”
His second presentation focused on the Penny LED system. The project was designed to meet the needs for cheap, reliable lighting in developing countries. His group wanted to build converters so that people could safely use car batteries to charge their LED lights (the car batteries put out electricity in a higher voltage than the lights could support), using old copper pennies as the means of conducting electircty. They gathered copper pennies and set up a group of people to build the converters; however, the converters were expensive to produce and the likelihood for error high. But what really killed the project was the availability of other, better resources. Berg says that the project was essentially a failure in market research – cheap converters already existed, and LED flashlights produced in China were cheap and ubiquitous, making the project unnecessary.
Chris Fabian/Erica Kochi: 5 Million Stories by 2010? Nope. 400.
UNICEF Innovations’ Chris Fabian and Erica Kochi co-presented what they jokingly referred to as a “zombie project”, because despite the fact that the project couldn’t get off the ground, it kept being half-heartedly restarted over the years. “Our Stories” was designed to give children around the world the chance to tell their stories to be published online as part of a look at the global experience of childhood, with the ultimate goal of having 5 million stories posted by 2010.
Launched in 2007, Kochi and Fabian estimate the project had a .008 success rate, since it only gathered 400 stories. They say that this project was a failure of real world application, in that although the idea was good, there was no real desire for it among the community it targeted. As Kochi explained, “No one asked for this.” Other problems included using proprietary, non-open source code so that they couldn’t adjust when there were problems, a lack of ownership and commitment to the project by key stakeholders, and a long timeline that mean that resources never aligned with needs – in 2007 there was money for PR, in 2008 pro-bonoe design resources, in 2009 the software development. In 2010, they finally shelved the project.
Ian Schuler: Election Observation in Montenegro. Manual Refresh.
The final presentation of the night came from Ian Schuler, who presented his experiences with election monitoring via SMS during the elections for Montenegrin independence in 2006 (read our interview with Schuler here). The initial system was designed to let election monitors send in SMS messages from polling stations across the country to report problems and results. The first test of the system resulted in none of the volunteers receiving confirmation texts that their SMSes had been received. Because the protocol for not receiving a confirmation text was to call into the main database, all of the volunteers began calling at once, overwhelming the system. The phones were linked to a computer database that was compiling the SMSes, and the amount of data overwhelmed the system. The group solved the project by having a volunteer click through and refresh the list every 45 seconds.
This was a failure in timing – the project was started exactly two weeks before the election, not enough time to test and refine the system. Although it eventually got the results in, the group had promised they would have definitive results within 30 minutes of the closing of the polls – even by midnight, the group hadn’t released the results, although other news organizations were already reporting that the vote for independence passed. Although the group found a work-around, the project didn’t work as initially planned.
Since then and learning from the early failures in SMS election observaton, Ian’s former organization has greatly improved election monitoring with mobile technology such as in Ghana, for example. As someone in the audience noted durong Ian’s presentation: “It’s called ‘learning.’”
Final Thoughts
Thanks to everyone who came out to the event. FAILfaire is a completely open-source concept and all collateral on our FAILfaire site is licensed under Creative Commons license, including the logo, name, and content. Feel free to start your own FAILfaire in your city and your field! We think that openly sharing mistakes is a great way to prevent future failures, and we would love to see more FAILfaires.
Photo by Prabhas Pokharel
(CC) BY-NC-SA 2013 FAILFaire Logo by Robert McDavid.
Powered by Wordpress. Designed by 
Recent Comments