Archive for December 2011
Duncan Green recently wrote Honduras is building a charter city? This is never going to work which as you can tell by the title is rather skeptical about the attempt in Honduras to build a charter city along the lines proposed by Paul Romer. In the opening paragraph we offers readers to make a wager that it doesn’t work, such is his confidence.
Roving Bandit offers (kind of) to take him up on his challenge by correctly pointing out that just like in betting on poker sometimes it’s worth while betting on a long shot, if the potential reward is big enough and you have enough resources to bet on a long shot without losing everything.
“So what odds do you say Duncan? I’ll give you £10 if it fails and you give me a £1000 if it works?”
This is a very important observation because if you never bet on something untested and risky, then you would rarely be willing to invest in something new, untested and potentially risky but which could potentially yield large benefits – exactly the kind of challenge we face in development aid.
That said betting on a long shot in poker is different from doing it in the real world in two important respects:
- In poker you know whether you have won the hand – the rules of success are clear.
- In poker you might not know what cards the other player has, but you can calculate the odds and use them to guide your bids (at least according to those poker tournament shows they have on the teevee).
So going back to the Guatemala Charter City idea, although different people will have different opinions about the likely success of this enterprise, we don’t have a very clear picture neither of the real odds or the potential payoff. In addition if I were to take Duncan or Lee’s bet, how would I know if I had won or lost – what is the definition of success?
All this is a very roundabout way for me to come to the under-exploited potential of “prediction markets” for development. What if you could run a book on the potential outcome of a project investment? If you could get enough people to take bets on whether this (or any other project or initiative) is successful then you might get a much more accurate sense of the likely risk and potential benefit of this project. In order to so this you would also have to come up with a specific definition of success in terms of what happens by when.
As well as being fun for people to place a little wager, this type of approach could also tell us a lot about where to place our investments in development. Interestingly enough, while we often take our pilots projects to be make or break, in reality a failure or success of a pilot, including the current one on charter cities, doesn’t tell us whether an approach is right or wrong, it just helps us reevaluate the odds.
(for the record I agree with Duncan – but what do I know?)
I remember attending the first ever failfaire back in April 2010, and writing a brief blog about some of the things I thought made the event successful.
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.
This is just my own feelings about the event which may differ from other presenters and attendees, but I don’t apologize for that.
So what’s it like?
1. It’s nerve-wracking – I always get a little nervous before a presentation, but this time particularly so. In addition to the usual reasons to be nervous I also found myself wondering “Is this a good enough example of failure?, are there really some useful lessons in there to share? will admitting I made these (often quite obvious) mistakes make me look stupid?, who’s in the audience and how will they react to this admission of failure?”
2. It’s exhilarating – once you get started actually being up there and letting it all out feels like a great relief, at least when you get a positive or sympathetic response from the audience. You don’t often get a chance to talk about what went wrong, and there is a great sense of solidarity that you can actually get up there and do this.
3. Humour saves you – I found it easier to soften the blow of talking about the mistakes I made (and those I also implied that others made) if I could make fun of them and myself – it helped ease the tension for me and probably for the audience too (at least if they laugh).
4. Autoadvance is your friend. I think the “Ignite style” auto-advance worked well for this type of presentation to keep things moving, and keeping it short overall. I’m sure if I’d have had control over the timer I’d have waffled much more and the presentation would have been less effective. I also think that less detail, with just the minimum context needed and a focus on the main lessons is probably the most effective way to convey fails and to keep your audience.
5. Failure is nuanced – but it doesn’t always come across that way. What’s clear to me is that just as we normally upsell our “successes” in regular reports and presentations, in Faifaire we accentuate the failures. In reality few projects are either epic successes or failures and have elements of both – but to tell a good story we make things more black and white – that’s OK as long as we recognize what we are doing. Chris Fabian wrote a great post about this from his own presentation at Failfaire which highlights also that failure can be more subtle than a failed project – but it’s a challenge to present a nuanced argument and not have the audience hear it more in black and white, especially when complex organizational dynamics are the topic of discussion.
6. Failure should lead to success. What I didn’t do in my presentation which some others did do is to show how the lessons learned from the initial failure were used to make future projects more successful. I know we did learn a lot from our first failure but unfortunately I failed to cover this. This might have been a mistake since the real value of the failure is not the fail itself, and not even the analysis of what went wrong, but the successful application of the lessons in the future – this is be something that deserves greater focus in our “celebrations” of failure.
7. Pick your audience. I’d been trying, unsuccessfully, to advocate for an internal failfaire in UNICEF for some time. This time around I had the possibility to repeat my presentation at a smaller internal “brown bag” lunch within UNICEF which included a smaller sub-group of the Wednesday night presenters in order to try to explain/promote the concept in house. I declined – partly perhaps because I’m no longer with UNICEF but partly also perhaps out of fear that my (former) peers would be judging me and that they would not be as sympathetic/forgiving as the failfaire audience. This made me realize that in some ways it can be harder to do an internal failfaire inside an organization which still struggles with admitting failure than to do an event with peers from different organizations who voluntarily step up to share.
In conclusion – it was great – I’d certainly do it again, and recommend it to others. You will be nervous – but it’s worth it. And if more of us could admit we’ve made mistakes and show how we can and have learned from them then there’s much greater chance that we won’t keep making the same mistakes over and again.
Congratulations to Katrin and team, and to all my fellow presenters for another great event.
(P.S. A good summary of the event is available on the failfaire site here: http://failfaire.org/2011/12/19/what-we-learned-from-the-last-failfaire-nyc-2011/ as is a nice guide to organizing your own event: http://failfaire.org/2010/07/29/how-to-roll-your-own-failfaire/)
A couple of weeks ago I was lucky enough to attend a presentation by Walton Smith (@walton3) of Booz-Allen Hamilton (BAH) about their experience in fostering social networking and knowledge sharing within their organization and in their consulting work with others. I’m ashamed to say I’ve only gotten around to writing it up now.
BAH developed a social platform for staff which has had a tremendous staff take up and usage by their staff and within a short time frame. So what was the secret of their success?
I’ve included below the slide deck from the presentation (thanks to Walton for allowing me to share it). There was a lot in there, but a few points that stuck out for me were:
1. Focus both the development of the tool and how you market it to your staff around solving key business problems they face, especially current pain points. Focus on how it helps them to do their work better – not on the software platform itself and how great or high tech it is or what bells and whistles it has.
2. Develop the platform in an “agile” manner – i.e. allow for frequent changes and continual improvement to meet the needs of users – in particular to quickly fix things that are not working, or add new highly requested features. Interestingly the BAH platform is built on Sharepoint 2007, not generally known for its social networking capabilities, b ut they were able to make it work through adding on various open source tools. This flexibility to combine different tools into a system is an interesting idea to ensure you can adapt to evolving user needs rather than just focusing on choosing a single platform – but I also imagine it must be a developers nightmare.
3. Work with your users, especially the power users and system champions to get continuous feedback on how to improve the system. Make these people happy as they are the people who can help improve your platform and will be critical in getting people to use it.
4. First impressions count. Make sure it works well and is easy to use the first time people try it (or they might not come back). Keeps things as simple and intuitive as possible, and ensure that performance is good (if it is too slow people will lose patience).
5. Clear senior management endorsement, encouragement and support is essential both to push through and support the project, but also to drive adoption and set the right incentives for people to try using the system. Working socially is a change management process and needs the same type of leadership support that is required to get people on board and sustain commitment in other change management activities.
6. Allow people flexibility to create their own spaces, including for non-business purposes such as hobbies – don’t stifle their ability to express themselves or try to censor or pre-moderate content, or try to prescribe how people use the system – people will find their own uses that you might not have expected, and this will help bring more people on board.
7. Employ gardeners. While you want to leave people as much flexibility as possible in how they use the system it’s still important to have community managers who clean up content, add tags or taxonomy to help retrieve content later, help advise users and stimulate effective use.
8. Build out profiles. Helping people find each other inside an organization and having information about your staff so you can more easily build teams or tap into expertise is one of the advantages of having s social platform and can be a quick win in terms of providing something that was not previously available.
9. Integrate the platform with existing business processes to help support them to be more efficient rather than having the social system as a parallel or add-on to “regular work”. That way users will more quickly see the benefits of how it can help them to work better.
10. Measuring ROI is hard. Even in the business sector its hard to calculate the return on investment on developing social platforms, and the exact benefits are both hard to quantify and are unpredictable and unevenly distributed. The better way to show success is through case studies which demonstrate how the system has created value in practice (this seems very akin to the idea in Wenger’s and De Laat’s value creation framework) as these benefits can be both large, and through use of a storytelling approach quite convincing.
There were also many other good tips in the presentation. There was an interesting discussion on how to apply the same type of tools in an extranet environment to involve customers or partners, and we got an inside peek at a couple of public sector type applications. Here the issue of content ownership and permissions as well as authentication of users becomes a little more thorny, and sustaining participation is also more difficult and this is an area where I would have like to heard more as it’s very relevant to a lot of what we would like to do in the United Nations in working with government counterparts, donors, NGOs etc. but unfortunately we only had time to scratch the surface of this.
After the presentation it struck me that BAH did have a few natural advantages over UN agencies and other development organizations in developing this type of system:
1. Money: As Walton said in BAH it’s always a struggle to get enough resources to invest in developing (and continually developng) a social platform – but my guess is that it’s easier to make the case, and resources are more plentiful in large private sector organizations like BAH.
2. Bandwidth: BAH is in many locations worldwide – but most of them are in places with good internet connections. With us working almost everywhere in the world we are not so lucky, and having adequate bandwidth for a system to work satisfactorily in all our locations, or when people are on the road can be a big challange.
3. Knowledge focus: This is perhaps the biggest challenge for development organizations. While we might consider ourselves to be knowledge workers and think that knowledge is one of our biggest assets – the actual demand for knowledge (and the incentives to create and use knowledge) is not as great as we might wish. In consulting companies knowledge really is the core of their business and their ability to mobilize it directly affects their bottom line. Until that becomes more explicitly true in development work, and until it is demanded of us y our donors and partners, and er demand it of ourselves it will be more of a struggle to get people to use these types of tools.
That said, I think the lessons from BAH are very pertinent and I’m hoping we will be able to apply them in our own work going forward (or even more than we already have).
Here’s the full presentation:
(Image: “Sumerian School Days [Text and Object],” in Children and Youth in History, Item #408, http://chnm.gmu.edu/cyh/primary-sources/408 (accessed December 5, 2011).
There’s a very interesting discussion going on right now on KM4Dev on ways of documenting and sharing lessons learned. One issue that often comes up in this type of discussion is whether there is any benefit of writing down and sharing lessons learned at all.
On the one hand many of our organizational masters seem to believe that if you could compile a master database of “Best Practices” then everyone would know most of what they need to do a good job. I’m not convinced (see this past post on why I’m not a fan of “best practices”).
On the other hand I’m increasingly seeing KM practitioners state that there is little to no merit in documenting lessons and practices, instead advocating for a flow of knowledge shared person to person as and when needed through participatory face to face events or online through social media type tools. Good reasons cited for this are that application of knowledge is contextual and that a lot of the real knowledge about what happened in a situation is tacit and cannot be captured easily, if at all in a written document. In addition, it’s usually much more convincing to get information from another person, one you trust, and one to whom you can ask follow up questions than to get it in a sanitized lessons learned publication.
Others might not dismiss writing but sometimes say that it’s best not to impose a structure so as not to constrain the thinking or try to fit ever y experience into the same box.
Perhaps you will not be surprised that I’m not yet ready to dismiss writing down the lessons you learn according to some pre-defined format as a valuable way to share knowledge. Here are a few reasons why:
- Writing down your experience in a structured way is a very useful way to trigger self reflection about your experience, what happened and what was “important” about it. Keeping it short, and using a few key questions or headers is a good way to help you think more clearly about your experience and how to explain it to others. It might also help surface some aspects that you might otherwise overlook if you just told it or wrote it as a freeform story.
- A written lesson or practice helps others locate relevant experiences for further consideration – in other words, the documented piece might be a conversation starter for more in depth follow up and contact between individuals rather than the end of the contact. Here the documented summary helps a seeker of knowledge /ideas to sift through different experiences to find those which might have most relevance to their own situation.
- A written piece, if it includes attribution, gives recognition to those who had the experience and those who documented it. Recognition is an important and often overlooked motivator for knowledge sharing so having a physical product externally shared with someone’s name on it can be a good motivator for people to share their experience and build their networks.
- It’s a record which can be drawn upon later. The problem with real time knowledge sharing in events and online communities is that only those present can share their experience. Having something documented from other experiences can help bring in ideas that are not “in the room” or help identify people and organizations who can be encouraged to join the current conversation.
- Having a simple template makes it easier to store and organize practices, but it also makes it easier for people to sift through them to find those which are most relevant. It also ensures that certain key questions (such as what was the problem being addressed, what was the context, what steps were taken and what actually happened including whatever evidence is available to support the conclusions). Without a template it can be easy to miss key questions that help others to validate or contextualize what is being shared.
- Lessons learned documents can be relatively easily repurposed for communication and fundraising purposes. They tell a nice simple story that shows how ideas turn into results, yet if written well acknowledge both strengths and weaknesses and what can be done to improve in the future which can be a more compelling (and honest) message than a simple unqualified success story.
In summary, there are still reasons for writing something down in a structured way which are not replaced by more interactive and tacit methods. The key is to use them both together for what they are good for with the writing down of a lesson not being the end of the knowledge sharing – but rather just the starting point for the conversations around an experience and how it might help inform practice in the future.
(Aside: the image above is an interesting record of an apprentice Sumerian scribe who is frequently beaten by his teacher for not doing his (wrote) work accurately enough. That is, until the boy’s parent’s invite the teacher to their home and ply him with food, drink and gifts after which the teacher’s impression of the student’s potential markedly improves – a lesson for the ages!)
Update: For those of you interested in the KM4Dev discussion on documenting and sharing lessons learned which sparked this blog post Davide Piga, the originator of the query, has posted a nice summary here.