I spent the top of this week at the World Bank, where I’d been asked to share something of our methods and approaches, particularly Failure Case Analysis. It was a really stimulating experience, the likes of which I can’t think of a parallel to in recent memory. There were largely economists, public health experts and statisticians in the group, so a very different profile from what one usually encounters. I have some thoughts and reflections to share, as below.
. My first attempt at explaining FCA was itself an abject failure. I believe less than a quarter of the room really got it. The fault is entirely mine, for I was having trouble grasping where different Bank staff were coming from, in terms of their disciplines, conceptual architecture, vocabulary and so forth.
. There seemed to be a great difficulty in naming what it is that people are doing in the period before a project hits the ground. We danced merrily around this for a while. I would suggest that the verb in question is ‘design.’
. At first it seemed that it was not clear to everyone in the group that this pre-rollout period is an important period of activity, crucial to the generation of hypotheses and insights that might yield effective solutions with real impact.
. In the second go round, when I ran an exercise things worked better. I began by showing the CKS Innovation Cycle, and then asked them to imagine that path drawn along a vector line. I then drew this diagram below and explained exactly when and why one would do an FCA. At the beginning of the project cycle is the right answer. But not everyone had gotten that. So it was useful to make that clear. And doing FCA allows us to be clearer about the Theory of Change with which we are operating, more fine grained and thinly sliced than otherwise possible, as indicated in the diagram below.
. Despite having followed the overall logic of the sheet, the teams’ analyses still operated at a pretty high level, and stood to be far more tightly calibrated to the specifics of end user experience. In at least one instance we encountered a pre-cooked solution that clearly hadn’t emerged organically out of the FCA, but rather had been preordained as the desired result, towards which all the analysis was then enacted. So some scope for further clarification here as well as to why bother — if you don’t want new things out of this process then really, don’t bother.
. Another concern is the extent to which the team focuses on process and capacity without addressing things, materials, technologies and any other kind of tool. This is something that bears calling attention to and correcting for by bringing more design talent into such exercises.
. In the wake of this session, I believe we at CKS must explain several other nuances of our way of working in greater detail, both to ourselves and to other people. For example, we must speak more clearly about why we use FCA, how we prioritize concepts, how we concatenate them, and why they end up being radical solutions, drawn from mundane sources.
All in all though, a terrific group of people and a great experience, from which I think we will continue to learn how to better communicate and how to collaborate with unlike minds so as to better build systems around the world that really work!
In closing, here’s an outbrief from one of the teams: