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:

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 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, and 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!

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)

We will feature lightening talks that focus on the learnings of the projects – and what can be done differently in the future.  We have some presenters already from the Bank and from various NGOs who will be presenting their failures but we encourage you to submit a failure here if you like to be considered for a talk during the event.

The format is informal, and we will provide refreshments and drinks.  We are looking forward to learning from failure in DC!

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:

• Make the event a safe space. Make it clear that this is about learning, not about blame. If necessary the moderator needs to reinforce this during them meeting, closing down any unhelpful discussions (which was done firmly but tactfully by Katrin during the event).
• Choose your speakers to be people who have also had notable successes. It’s easier to admit your failures when you are self-confident, and you will also have credibility because of your successes.
• Confidentiality: get people to agree on what can be shared outside the meeting and what stays in the room. I imagine that if we did something similar for UNICEF this might need to be internal only, with limited external sharing for people to feel comfortable enough with sharing.
• Don’t talk about money. The first presenter did talk about his financial outlay compared to the value of what he delivered, and it make sense in this context, but subsequent presenters were then quizzed on how much they had spent. I had the feeling that a focus on money can quickly lead to a focus how much was wasted and who is to blame which can then make people, especially in a publicly funded organization, very nervous about sharing. There are other means to look at these issues and I’d suggest that we stay away from them in our failure discussions if we want to promote honesty and learning.
• Focus not only on describing the failure but also sharing the lessons learned.
• Last but not least – ambience. Organizing the meeting with a sense of good humour, in a great location, with food and drink and socializing on the side is a great way to make people feel at ease and be willing to share and discuss frankly.

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!

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

Too often in our field, we talk up our successes, overhype and overestimate the value of our projects, and sweep the failures under the rug. But, if we don’t talk about what didn’t work (and, perhaps more importantly, why it didn’t work), others will keep repeating the same mistakes.

That is why we invented FailFaire, a gathering that is happening tonight in New York City and that we hope will take place in other cities around the world. FailFaire is a place where it’s ok to talk about what didn’t work to learn from for the next project using mobiles for social change and development.

Of course, there are different kinds of failure – some projects meet their basic objectives but are too expensive or unsustainable in the long run, some projects don’t fulfill their original mission but succeed in other (and sometimes surprising ways) ways, while some projects are just a flaming ball of fail. In the spirit of Hidin’s Top 10 Failure Points in Information System Implementation, we present here a sure way to fail in M4D: MobileActive.org’s Guide to Failure.

If you follow each of the headlines, you are sure to fail. If you read on below each invective, however, we point out ways to avoid utter failure. It’s not a recipe for success but may decrease the probability of failure and increasing the likelihood of helping people to have more free, healthy, prosperous, and dignified lives.

1. Don’t Clearly State the Project Objectives

It’s great to dream big, but vague objectives are nobody’s friend. How can you quantify something like “Change how people use technology?” When you first start to outline how you want your project to be developed and implemented, think about what you actually want to accomplish – and no,“Changing minds and hearts” doesn’t count. Be firm and clear. For example, if the projects wants to increase women’s literacy with SMS lessons, there need to be measurable goals forhow many women are participating, their literacy levels before the project, and after – in short, what measurable and quantifiable results you want to see by the end. Once you know what the goals are, it will be easier to create a plan that helps you achieve it. Which brings us to point number two:

2. Don’t Plan Ahead

Good projects can take months of advance planning before they’re ready to be launched. Glomming on to an idea and trying to rush the planning stage can lead to poorly designed technology, lack of stakeholder input that you’re trying to reach, and unachievable goals. It’s better to take time to make sure everything is designed to incerase the probability of actually accomplishing the goals of the project. Even if things go wrong along the way, having a plan can help you minimize the fallout and salvage the project.

3. Go It Alone

Strong relationships with the beneficiaries, users, and partners can be the difference between a project that succeeds and one that doesn’t. While you may think that your idea is so great that it doesn’t need support, the reality is that working with those who you are trying to reach is a must. Most mobile projects will also need the buy-in from the mobile carriers so find partners in the telecommunications industry, look to local schools and universities for developers that are local, partner with community leaders to make sure your project is taken seriously and meets the needs of the area, and look for other developers or NGOs who have either released similar projects or worked in the area to find out what you can learn from past programs. Ignoring others is a guaranteed way to make your project unpopular, and without supporters your project is likely to die a quick death.

4. Don’t Adjust / Don’t Compromise

You have a vision for your project. So it’s understandable that when you realize it’s not going according to plan, your first instinct may be to cling to the project’s original plan despite bumps in the road. But ignoring small problems can lead to bigger problems and all-out failure. Adjusting along the way also proves that your approach and product is flexible – which is important for long-term sustainability. Needs and technologies change, and trying to force your project into relevance once it’s clear that something is wrong isn’t going to make it magically work. Use these minor setbacks to improve upon your original idea.

5. Ignore the Community

Presumably you’re launching your ICT4D or M4D project with the ultimate goal of improving others’ quality of life. So why ignore them? Many well-meaning projects are initiated by donors and NGOs, often not from within a community (though there are certainly exceptions!) Understanding the needs and dynamics of the people in the community before you start throwing money and technology into the mix is a must. In fact, a lot of the work we do is about people, community organizing, and understanding what drives them. We’ve read about plenty of projects that didn’t take communities’ dynamics into account, threw technology at them (A la: Build it and they will come). Needsless to say, a lot of the projects do not exist anymore.

For example, in one project, a group of high school girls were given cell phones with embedded learning games in order to increase their math aptitude. Although the girls used the games, the project had a surprising secondary effect – at the end of the program, many of the girls said they felt less connected to their friends. Researchers realized (after the fact) that giving a select group of teenage girls in a high school a fancy phone had the unintended effect of creating an atmosphere of jealousy.

We’ve heard of other projects that tried to send personal HIV/AIDS test results to people over their mobile phones; they were surprised by the low pick-up rate until they realized that many people in the community share their mobiles with family and friends. A text message isn’t personal when multiple people share one phone.

Speak with the people who will be using your product, and be sure to engage with questions. Dig deep; ask about the community and family dynamics in the region you’re launching the project, ask participants how they anticipate using the product, ask what they want to get out of being involved, ask if they anticipate any problems and why. Working in and with the people and community in which you wish to launch your project is the best way to anticipate potential barriers.

6. Don’t Scale Your Rollout

Your dream may be to create an application that changes the way teachers use technology in the classroom across an entire country, but if the infrastructure can’t support the technology and the schools can’t afford the necessary equipment and upkeep, your grand plan will fail. While we have our issues with the many pilots in this field (that often go nowhere after their pilot phase) it is wise to start small and slowly scale the plan as it proves its usefulness and so long as it is, in some way, sustainable. Carefully researching a pilot project with the right level of support (strong infrastructure, funding, community interest) is one way to go. Understanding how rolling out on a larger scale, however, should not be forgotten. Small may be beautiful in some instances, but societal impact in this field may hinge on larger-scale projects. But, at least if you start small, if your project doesn’t work, you found out early on.

7. Ignore Critics

If people on the ground start telling you that the project isn’t working, or doesn’t meet the needs of the community – listen to them! Creating an open dialogue is a key to success. It may sting your pride, but no one is an expert in everything; other people may know more about which technology is best-suited for the region, or about local customs that need to be accounted for, or may just see a glaring error that you overlooked. Learning how to take advice and listen to others can make you and your organization better. Blindly continuing on with your projects while discounting the voices of others is at best a recipe for making you and your organization unliked, and at worst a recipe for failure.

8. Burn Your Budget

If you haven’t set clear objectives or planned ahead, then it’s likely that your budget is a joke. One of the surest signs of a failed project is one that wasted its resources; to create a truly useful, sustainable project it needs to be affordable and have a plan on how to financially live in the future. If your project only worked because you threw buckets of cash at it that won’t last, and it can’t be repeated anywhere else. Or, if you burn through your budget and find yourself financially depleted four months into an eight-month pilot, you’re out of luck unless you can quickly raise some serious money. To avoid budget setbacks, think about what you need to make the project work. Account for even small things; little things like airtime incentives so popular in many projects can add up.

9. Burn Bridges

Jumping through bureaucratic hoops necessary for implementing a project may make you want to tear out your hair. Maybe you have to go through an assistant’s assistant before you’re even allowed to contact the official you actually need to talk to. Or maybe you accidently offended someone (shouldn’t have ignored the local community!) and now find yourself blacklisted. Even if you’ve been unfairly treated by the people in power, whining won’t help. Complaining to everyone you meet about how you were screwed over won’t endear you to others – although sometimes they’ll commiserate with a similar tale of woe, creating a feud does nothing to encourage conversation or change. Similarly, if you find things going wrong in your project, don’t just pull out and leave the people involved high and dry; they’ll remember your shoddy treatment and it will make it harder for you if you want to come back in the future, or for other groups who may want to work in the area to be taken seriously.

10. Don’t Plan For The Fund

Pilots stop. Funding runs out. Projects end. Not planning for the end, however, can leave a bad taste in everyone’s mouth. If you only have enough funding for a six-month pilot, then plan accordingly to get the most out of that time. Make sure that all the parties involved are prepared for what might happen when it draws to its natural conclusion. If you’ve spent time and money training community health workers how to use mobiles to manage a database of patients, ensure there is lcoal supprot and continuity as part of the project. Plan ahead (wich we already mentioned). You can’t anticipate everything, but having a general idea of how to conclude the project in everyone’s best interests is the best way to make sure that your project has impact even after you’re gone.

Avoiding Failure

We are sure there are many more (we never mentioned proprietary tech platforms here, for example….) so the definitive MobileActive.org guide to failure may be indefinite for now with more to come. We do hear of a number of poor practices coming up over and over again, though. Insufficient planning, a lack of strong local and partner relationships, and not understanding people and community needs are sure ways to make your project fail. Sometimes even meticulously planned and researched projects don’t work out due to unforeseen circumstances, but in general, failure can be mitigated. And if not, we invite you to the next FailFaire to tell all about the flaming FAIL!

Despite widespread recognition that challenging times place unpredictable demands on people and businesses, I still run across many managers who would prefer to avoid the logical conclusion that stems from this: failure is a lot more common in highly uncertain environments than it is in better-understood situations….

For many years, scholars such as my esteemed colleague Sim Sitkin of Duke (see his article “Learning through failure: The strategy of small losses,” ) have been studying how organizations learn, and they have come to the conclusion that intelligent failures are crucial to the process of organizational learning and sense-making. Failures show you where your assumptions are wrong. Failures demonstrate where future investment would be wasted. And failures can help you identify those among your team with the mettle to persevere and creatively change direction as opposed to pig-headedly charging blindly ahead. Further, failures are about the only way in which an organization can re-set its expectations for the future in any meaningful way.

While she addresses failure in this context from in intra-organizational perspective (useful but not sufficient) we would argue that failure must also be understood in the context of an emerging field. Mobile tech for social change and development would rather qualify as an “emerging field” where we make it up as we go along. Hence, if we keep failure bound in the confines of the organization, we, as a field and community of practice, will not learn – not intelligently or otherwise.

So, what makes intelligent failure that is a learning opportunity as opposed to wasted?  McGrath notes these characteristics of intelligent failure:

• They are carefully planned, so that when things go wrong you know why
• They are genuinely uncertain, so the outcome cannot be known ahead of time
• They are modest in scale, so that a catastrophe does not result
• They are managed quickly, so that not too much time elapses between outcome and interpretation
• Something about what is learned is familiar enough to inform other parts of the business [or field]
• Underlying assumptions are explicitly declared
• These can be tested at specific checkpoints, identified in advance, since planned results may not be equivalent to outcomes.

She asks exactly the right questions – those that we are after in conceiving FAILfaire:  “Are we genuinely reaping the benefit of the investments we’ve made in learning under uncertain conditions? Do we have mechanisms in place to benefit from our intelligent failures? And, if not, who might be taking advantage of the knowledge we are depriving ourselves of?”

Add to that the other dimension of the field that we are in: International Development.  Helping people and societies increase their own capacity to address their problems and increase the quality of life for their fellow citizens.  Or, as the Wikipedia puts it:  “International development.. seeks to implement long-term solutions to problems by helping developing countries create the necessary capacity needed to provide such sustainable solutions to their problems.”  Which, as we are now all beginning to acknowledge, is also hard. Very hard.  And, also littered with failure – something we talk even less about than corporate IT flops.

Technology, and particularly mobile technology, has, of course, as of late been lauded as the second coming in international development.  And while we certainly agree that there is much potential for the use of mobile tech to support the development, governance, accountability, and democracy efforts that we all work on, we also believe that, as a field, we are now mature and wise enough to start to take a close look at what is not working.  And have the guts and insights to talk about these flops and failures in a constructive and forthright manner.

Bring in FAILfaire.  It is a way for us to come together and talk about exactly this – what did not work, why, and how to do better.  We hope that the inaugural event in New York (where we are based) is only the beginning of a long series of conversations to talk about where we fall short and why.  Because a lot is riding on that we do.  I am reminded of a post I read by an aid worker who is nothing but wise, reflective, and honest about his field.  He writes:

It is not that we should be endlessly self-critical. The work that we do does accomplish some good. But I am challenged to remain in a state of confident humility. We must not just sit and watch while the problems of our fellow humans go unattended. We must do something, and we must do it confidently. And we must do all of this humbly. If my own experience is at all representative – and I believe that it is reasonably so – then we must go about the business of making the world a better place mindful of the fact that we are all still learning. We will make mistakes along the way. Maybe our mistakes will outnumber and outweigh our successes. We must keep in realistic perspective the limitations of what we have to offer, not just technically or intellectually, but as human beings.

Katrin, New York, March 18, 2010

]]> http://FAILFaire.org/2010/03/20/failfaire-and-some-thoughts/feed/ 1