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.
This week I presented a failure at Failfaire. In presenting, I have learned something about the process of talking about failure. I presented (or I thought I was presenting) my failure to connect an amazing innovation (the Water Canary – a low-cost device for instant water testing that developed from our Design for UNICEF class at NYU) to the right part of UNICEF.
What people heard was something different.
This is a post about why, and some ideas on how to present failures better in the future.
Here’s what I was presenting: My failure to incubate an innovation inside UNICEF.
Here’s what I was not presenting: A project failure.
I tried to describe the complexities of the UNICEF ecosystem. I wanted to present how the Water Canary team took a project and continued to develop it into something that is robust and inventive – and possibly revolutionary.
The point of my presentation was that I failed to identify where inside of UNICEF Water Canary could fit. Water Canary devices provide real-time water quality information. That focus better matches the agenda of our logistics experts rather than our water experts, however – something that I did not consider when introducing the devices to UNICEF.
That organizational distinction (water and sanitation vs. logistics) makes a lot of sense to me. It made so much sense to me that I didn’t explain it very well to others. But that is because I sit inside an organization where those words (water and sanitation, logistics) have immediate and distinct connotations. I tried to translate those words at FailFaire, but clearly I did a bad job.
From the tweets at the event, and from what people took away, it must have sounded like “Water Canary did not work” and “Water Canary wasn’t tested with end users” – but when I presented this internally, at UNICEF last week, I got very different feedback: “Oh, of course you connected to the wrong part of the org chart,” and “Well, here is how you could have done this better.” The internal audience is familiar with the ecosystem, and shared the same language with me.
Just to be clear: Water Canary is not a fail.
I think I would break up with Failure if we were dating. Here is why:
Failure is needy: If you present a failure that is linked to a product *even if that product isn’t the failure* it seems like that product doesn’t work, or was badly designed, or was, itself, the fail.
Failure is jealous: You need to really own every part of the failure you are presenting. Don’t present around, or near, other peoples’ projects unless you’re trying to be mean.
Failure lacks subtlety: If you are describing a failure *within* a system and that system is big and bulky (like our organizational structure) – you may sound like you are actually presenting a failure of that system, or something else entirely.
The Water Canary is a cool project. It did not fail vis-a-vis UNICEF. The Water Canary folks talked to experts in the field, and in “the field” and developed the device with them. It has scope in a variety of different applications. We are excited to be one of those applications, and will be testing a version of Water Canary in Uganda. And I should have presented on a different failure. But at least I’ve got a topic for my next Failfaire.
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.
The fourth FAILfaire, this time in New York City on December 14th, will be an evening dedicated to those tech and mobile projects that were designed to have a social impact but instead crashed, burned, and FAILED. FailFaire NYC is presented by MobileActive.org and hosted by the U.S. Fund for UNICEF, with participation from UNICEF’s Innovation Unit.
If you do not know about Failfaire, here is some background: Launched in early 2010, there have now been three FAILfaires, events designed to provide a platform for those working in online and mobile technology for social change to openly, honestly (and humorously) discuss our own failures.
As noted in the New York Times’ piece on FAILfaire, “Technology’s potential to bring about social good is widely extolled, but its failures, until now, have rarely been discussed by nonprofits who deploy it.” Well, FAILfaire is changing that, and is doing so in style. The format is informal, the discussions are rich, and the refreshments are adult and, well, refreshing.
Slate.com wrote that FailFaire “…[isn’t] about celebrating failure just for the sake of failure, but about taking lessons from each mistake and using them to create more efficient, economical, and accessible projects that could have a greater effect on a community.” We couldn’t agree more!
To join us, please RSVP here, as the event will fill up quickly.
If you like to be considered as a presenter for the next FAILfaire, click here and submit a note about your failed project and what we can learn from it.
More information can be found at failfaire.org or on Twitter at @failfaire / #failfaire
From its inception, FAILfaire was designed to be something that could be organized by any organization interested in facing and learning from past mistakes. We even wrote a blog post a while back with directions for “How To Roll Your Own FAILfaire” Well, it looks like the idea is catching on…
On October 13th, FailFaire DC 2011 will be hosted by The World Bank, Development Gateway, Inveneo, and Jhpiego. The event will be held at The World Bank, and featured speakers include:
* Dr. Tessie San Martin, CEO, Plan International USA
* The World Bank on their 70% ICT4D failure rate
* Ian Schuler, Internet Freedom Programs, U.S. Department of State
* Erin Mote, Chief of Party, USAID Global Broadband and Innovations Alliance
* Andrea Bosch, ICT Advisor and Chief of Party, TILO Egypt, Creative Associates
* Grameen Foundation
* Development Gateway
As the hosts describe on their website:
“Fail Faire DC 2011 is a celebration of failure as a mark of innovation and risk-taking. We will have great speakers with fun, fast, Ignite-style presentations of their professional failures. Audience participation is not only encouraged, it is mandatory! We are all peers and none of us is perfect. Expect much laughter as we navel-gaze at where we have all gone wrong in ICT and international development.”
We wish them much success in sharing failures and look forward to the event.
More information can be found at failfairedc.com
A few months ago, we noted that we had been hearing buzz and feedback in the news about the FailFaire concept, and had caught wind of the format taking hold among new industries (in addition to our own focus, which is technology and international development).
While our original FailFaire events were inter-organizational and we invited a range of practitioners and organizations in the field, the concept is also well suited as an intra-organizational exercise. Hosting a private internal FailFaire can be helpful for honestly reviewing past performance, better sharing lessons learned, building capacity, and brainstorming solutions to prevent the same mistakes from being made again within your individual organization’s internal framework.
In this vein, we’ve heard that the World Bank, UNICEF and Ashoka, an organization focused on supporting and promoting social-entrepreneurship worldwide, have all hosted their own variations of internal FailFaires.
At Ashoka’s event in November, nearly 50 people attended in person, and many international staff from around the world called in. Our friends who helped put on the event reported that it was a huge hit, and people are already requesting another one next year. Ashoka’s Human Resources team is encouraging staffers and country offices to host their own variations of the internal event within their own teams.
While the specific takeaways and failed projects which were presented are, naturally, only available internally – you can read a roundup blogpost about their event here.
And, if you are inspired to host your own, check out our how-to guide to creating a killer FailFaire as a primer.
We’re not the only ones talking about M4D and ICT4D fails! We were thrilled to learn that the Dutch Institute for Brilliant Failures (yes, it’s a real organization – devoted to highlighting the importance of experimentation and failure in progress in innovation) recently instated a new prize specifically for the development aid sector in 2010.
As it turns out, our good friends at Text To Change recently won the distinct honor of an Audience Award for their first HIV/AIDS text message quiz program in Uganda! We asked Josette de Vroeg from Text To Change’s office in the Netherlands, to explain:
Q: What is the Institute of Brilliant Failures, and what is the new Transparency Award in the Development Aid Sector?
The goal of the Institute of Brilliant Failures is to bring about a shift in the way we view failure – to promote a positive view of failure through the use of stories, film, interactive workshops, and road shows. The institute is a tribute to inventors and those who had the courage to try something different, and a way of laying down a challenge for the rest of us.
After lots of criticism on development aid the Dutch Institute of Brilliant Failures has initiated a new award for the development aid sector. The idea of this annual award is: without failure, no progress.
Time and time again history has shown us that our most valuable experiences are more likely to come from mistakes than from successes. We learn from our failures and our failures are a source of inspiration for others. In this respect failure is not only an option but failure is also necessary. The new Transparency Award in the Development Aid Sector is created to stimulate openness and transparency in this sector.
Q: Why do you think recognizing failure is important, particularly in our field of ICT and aid/development?
Recognizing failure is very important because people and organizations can learn from each other. People are afraid to be associated with failure and this blocks the learning capacity. The key is to dare to learn and innovate by interacting. We think an open dialogue regarding the complexity of development aid, well thought attempts and common failures is a requirement.
Due to the fact that TTC received this audience award a big step is made towards more openness and transparency in the development aid sector. We are very proud to win this award and will definitely participate in the competition next year. We hope more organizations will have more brilliant failures and participate than this year. We hope organizations will realize that this is not a public humiliation but an opportunity to create more success stories.
Q: Tell us, what was Text to Change’s Brilliant Failure?
TTC is a non-profit organization that allows mobile phone users in Africa to participate in text message quizzes and win prizes through interactive education and development programs. This year, 6 out of 10 people in Africa own a mobile phone. Text to Change challenges participants by sending multiple choice questions not only on health subjects but also on economic development.
Our Brilliant Failure was our first project that spread out an HIV/AIDS text message quiz in Uganda.
Nobody ever tried this before. We thought everything was taken care of, nothing could go wrong. We were focused on content, technique and our financial means, except for…the SMS code that the Ugandan government would provide us. The morning of the project’s launch we were told the SMS code was 666 and this caused a lot of commotion. 666 is the devil’s number and the involved partners were all Christians, and wanted to stop the project. Fortunately, we were able to change the SMS code into 777.
Q: What is the big lesson learned/what should we all keep in mind when designing similar projects?
No matter how well prepared you are, keep in mind that unexpected things can happen. We were so focused on all external factors that we forgot to check our own SMS code in advance. Never assume that you are in total control.
This week, an interdisciplinary group of investors, social entrepreneurs, funders, innovators – including innovators in the ICT4D and mobiles for social impact space, have gathered at the sold-out conference, SOCAP 10 (Social Capital Markets).
Inspired by the first NYC and Washington, DC FailFaires, Catapult Design checked out our tips on “Rolling Your Own Failfaire” and decided that the SOCAP audience too would be ripe to openly and honestly discuss the challenges and failures within social enterprise. We hope participants will engage in a robust conversation and heed eachothers’ lessons and avoid reinventing the wheel and making the same mistakes as they embark on future projects and programs!
If you are at the event today, Tuesday Oct. 5th, check out the FailFaire session at 11am.
Here’s the original informational blogpost published over at Catapult Design’s blog:
Join Catapult Design on Day Two at SOCAP ’10 in San Francisco for the first west coast FAILFaire, a forum for open and honest discussion around failed initiatives within social enterprise. Moderated by Catapult, all SOCAP attendees are invited to participate by presenting their failures that led to greater understanding or later successes. Whether it be a failed initiative, a failed business relationship, or a failure in implementation, we will provide a safe venue for discussion, insight, and lessons learned. The objective of the 90-minute session: to learn from the mistakes of others, and perhaps contribute to someone else’s success in the process.
The first FAILFaire was organized by MobileActive, a non-profit connecting people, organizations, and resources using mobile technology for social change, in New York and followed by a DC FAILFaire hosted by the World Bank. Originally focused on fail stories from ICT and mobile development, the SOCAP FAILFaire opens up the topic to social enterprise and technology. As an organization focused on the development of transformational technologies for people living in disadvantaged communities, we’ve witnessed firsthand the profusion of abandoned and ignored technologies collecting dust in rural hospitals, schools, and homes. We’ve also witnessed organizations falling prey to the same mistakes made by previous organizations. Yet these stories are for the most part hidden, when they could directly benefit the community at large.
So if you’ve been part of a project that didn’t quite work out, join us on October 5th and tell your story! We want to hear and learn from you.
For those who can’t attend, check back on our blog for the major takeaways from the event!
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!
(CC) BY-NC-SA 2013 FAILFaire Logo by Robert McDavid.
Powered by Wordpress. Designed by 
Recent Comments