Reflections on Learning from Failure from a #FailFaire Attendee

Posted by ithorpe on Apr 16, 2010

On Wednesday evening I was lucky enough to attend the first ever "Failfaire", organized by 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 in 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 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.

Chis 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.

For a more detailed write up of the presentations and the event take a look at this excellent blog post.

A few shared lessons emerged which might also seem familiar to us in UNICEF. A few of these were:

  • 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 needed. Before embarking on a project its important to ask yourself, if there really 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:

  1. 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).
  2. 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.
  3. 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.
  4. 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.
  5. Focus not only on describing the failure but also sharing the lessons learned. 
  6. 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!

Photo courtesy Matt Berg

This is really an excellent

This is really an excellent analysis, kudos for putting this together!

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd><p><br> <b><i><blockquote>
  • Lines and paragraphs break automatically.

More information about formatting options