KM triple fail. No Faire!
[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 MobileActive.org 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.
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.