KM on a dollar a day

Musing on knowledge management, aid and development with limited resources

KM triple fail. No Faire!

with 5 comments

[This post is a contribution to “The 2nd Aid Blog Forum: Admitting Aid Failure?” being curated by J of Tales from the Hood – although as it happens I was already planning to write this anyway. It’s more personal than my previous post on failure which is here.]

Last week the World Bank hosted the second Washington DC Failfaire: “A celebration of failure as a mark of innovation and risk-taking”.

I attended the fist ever Failfaire in New York organized and hosted by which featured failures in ICT4Development projects. I was intrigued by this idea so much so that at the time wrote this blog and committed myself to try to organize a failfaire in UNICEF.

Of course that never happened…. so inspired by reading about last Thursday’s event on Linda Ratree’s blog and on Slate I’ve decided to share three of my own failures from my knowledge management work with UNICEF.

1. Making community sites overcomplicated in Drupal

Some years ago we first decided to set up a social networking platform to support our budding work on communities of practice. We got a very small sum of money to support this, and we approached our IT department to get their help. At this stage they were not ready to  help us develop  a web 2.0 platform. So we instead decided to get recommendations from some “young people” who were doing cool technology things on what we should do. We ended up developing a site with what at the time was a relatively new tool – Drupal – and which in the end never saw the light of day. A few of our mistakes:

  • We did not understand the tool and how it works or what it could do which put us at the mercy of our consultants to advise us.
  • We didn’t have a clear idea of what we wanted on our community site (so couldn’t easily communicate this to the consultants or our pilot users).
  • We worked with a consultant who wanted to  do cool stuff and showing what they could do to push the boundaries of Drupal. What we really needed was a simple site that would be easy to learn and use for people unfamiliar with web  technology with low bandwidth many of whom were not the web 2.0 generation. This meant we didn’t get the type of simple no frills platform we really needed.
  • We didn’t focus enough on maintenance, reliability and technical support for the site. This is critical when trying to get people to use something unfamiliar.
  • The tool didn’t integrate with other things people were used to using such as e-mail or the intranet and didn’t look like it was a “UNICEF” product. We thought this would make it easier for people – in fact it made it harder.
So in the end we abandoned this platform – but we did learn some important lessons which we applied when we developed our in-house platform through our IT department as an integrated part of the Intranet.


2. The end of end of assignment reporting

When key staff leave the organization, or even move on to another assignment there is always a risk to lose key institutional memory. Although people often do do some sort of handover note there was no formal guideline or practice for this across the organization. Some rather labour intensive and relatively costly approaches have been used on a selective basis such as debriefing retreats where key staff would go off somewhere for a week to write up their lessons before retiring, or interviews where a key staff member would be interviewed and this would be transcribed and written up.

We wanted a less labour intensive methodology that could be applied more widely without extra resources. The UN Department of Peacekeeping Operations (DPKO) does have such a system that is well established – so we decided to adopt and adapt the DPKO system. Unfortunately, although the tools were developed and piloted the system never took root.

One reason is that DPKO culture is very different from UNICEF culture – people are used to producing procedural notes such as handover reports, after action reports etc. possibly because such approaches are widely used by military organizations. People understand the need for detailed procedures and reporting and management support it and demand it from the highest level.

In UNICEF end of assignment reporting was done as a pilot project, with management approval in those offices where it took place, but without “enforcement” or top level pressure on staff who were leaving to comply. This meant a massive amount of time was spent following up with people who promised to produce reports but never delivered them with no real management sanction or peer pressure to make people complete the reports. Given other challenges people have when they move or leave this was understandably low down on their priorities. Another challenge was that there was no real commitment to  widely circulate or follow up on recommendations in the reports – which means that the incentive to complete them was limited.

The main lesson I took from this is that something like End of Assignment Reporting needs to be top down, rather than bottom up i.e. management need to decide that it is something they want to inform their decision making and insist on it taking place. Otherwise while completing such reports can be seen by everyone as valuable there is little incentive if there is neither a sense of it being mandatory or that it will be made use of.

3. Where is the UNICEF Failfaire?

Despite my initial excitement about the idea of the Failfaire, and the possibility of replicating it in UNICEF, I was never able to make it happen. Here’s some thoughts as to why.

  • ICT4Development as a sector is more experimental and less conservative than other longer established areas of development work. People are more willing to do new things (perhaps because comparatively less is known about what works), they are tolerant of failure,  more open to admitting their mistakes, and willing to learn and move on more quickly (not to say its easy – just that the people who work in this area are more apt to do this). Of course I tried to propose it for other areas of development!
  • Finding funding is always tricky – we saw an opportunity, but ended up pitching the idea to a donor that is probably among the most conservative and who were hard to convince of the idea (although they did not dismiss it entirely).
  • We tried to formalize it into a full or multi-day event with official high level sanction within the organization (because that’s how wee usually do things), yet even in my first blog I’d surmised that the event’s informal nature was one of the critical factors in its success. Our management was (probably rightly) cautious to trying out something totally new  and potentially risky without seeing how it worked on a smaller scale first, especially when this type of thing isn’t (yet) part of our organizational culture.

But all is not lost. Erica Kochi and Chris Fabian from the UNICEF innovation team presented at the first Failfaire and have been brave and good natured enough to keep the torch burning on this one. Hopefully they will make it happen in UNICEF some time soon.

And before I left, the first documented case study of a failure was published widely on the intranet, kindly offered up by one of our country representatives. This created a bit of buzz and people have started talking about how we should do more to learn from our failures. A big lesson here is that cultural change can take a long time, longer than you think – but that doesn’t mean it’s not happening – you sometimes need to be patient.


Written by Ian Thorpe

October 17, 2011 at 1:15 pm

5 Responses

Subscribe to comments with RSS.

  1. Ian,

    A few notes on Fail Faire DC. While it was at the Bank, a few us outside the Bank made it happen largely without the Bank’s involvement. Next, we purposely kept it informal, small, and cheap. Our goal was 100 people over 3 hours on 1 evening. Our entire refreshment budget was donated by 1 company and 2 individuals and was under $650. We did find there was more demand to be a speaker and attend the event than we ever anticipated, yet will still kept the event small. This was hard, but needed to keep it informal and enjoyable (for the organizers as much as the participants).

    As to Drupal… I’m still regretting using it for ICTworks every day and I’ll /never/ use it again.

    Wayan Vota (@wayan_vota)

    October 17, 2011 at 2:54 pm

    • DrupalFail? Drupal is not really the best tool for a a blog – sure, you can do it, but it’s definitely engineered to be a multi-user, multi-role, multi-content-type system, and excels at that. It’s also really easy to overbuild, as above – but then, any “community” site can quickly wobble out of control without a tight leash on the specific goal for the project.

      jon camfield (@joncamfield)

      October 24, 2011 at 8:23 am

  2. […] Abundant signs that this framework is surging are also the Failure Fair in DC, which was received enthousiastically by many bloggers here and @ithorpe here. […]

  3. […] a late supplementary entry in J’s Second Aid Blog Forum on “Admitting Aid Failure” (my first entry was about  some of my own […]

  4. […] But this time around I attended as a presenter rather than only as an audience member so I wanted to share a few quick impressions of what that’s like. I presented a case study on our fist attempt at developing a technology platform for communities of practice using Drupal which I described briefly in this previous blog post. […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: