Archive for September 2012
In past posts I’ve talked about the problems of relying too much on rules, guidelines and so-called “best practices” in development work. And while big organizations like the UN still rely too much on these, I’m also starting to see some taking quite an opposite view.
With the trend towards innovation work, and discussions around complexity in development an increasingly popular approach is as follows: get together a group of people, preferably including some of your beneficiaries, quickly brainstorm some ideas preferably involving applying new technologies, then try them out and iterate what you do as you go along adapting your approach to what you find. Quite often these projects are attractively presented and communicated and shared at conferences and via social media generating a lot of buzz – but it much less frequent that they are also studied and evaluated over time with the potential learning from them incorporated into “mainstream” development thinking.
Innovative and iterative approaches are exciting, and they are built upon the recognition, often missing in more traditional aid programmes, that each situation is unique and that we rarely know exactly what will work. But it’s important that they be seen as complementary or additional approaches to development work, rather than a new, better approach that will replace the old.
Here are a few counter-arguments as to why we shouldn’t just throw away the rule book, programme procedures, toolkits and case studies in favour of “making it up as we go along”:
1. Not all development problems, or at least all aspects of them are fully “complex” in nature, and even some of those that are have been extensively programmed, researched and evaluated. This means that in many areas we already have a fairly good idea how best to tackle them, and have probably also gained some costly experience about how not to handle them. In these cases it might be less risky and more productive to do what we know works rather than trying to do something new.
2. Some areas of work actually rely in standardized predictable procedures to make them work, even if these aren’t always the most efficient or user-friendly. An obvious example is financial management systems where you wouldn’t want to experiment or reinvent them every time, but this might equally apply to other technical processes such as vaccine handling, or shelter construction etc. etc. where what is being done is highly technical and expert, but good practice is built into the standard procedures to ensure consistent quality.
3. Sometimes consistent (non-innovative) approaches are needed for reasons of transparency and fairness i.e. to ensure that everyone knows how the system works and that they will be treated according to consistent rules (even if these are recognizably imperfect). This may even be a legal requirement that needs to be taken into account e.g. to be demonstrably and accountably equitable in how resources are distributed to the poor from a programme.
4. While every individual situation is unique in some regard, and it is often not clear what approach is the best to take, few situations are completely unlike anything else that has gone before, there are usually ideas and experiments that can be adapted from other countries, or from other sectors. It’s therefore good to use “document and possibly well studies/evaluated approaches from elsewhere as a starting point for a new innovation rather than designing from scratch or only designing from local knowledge and context.
5. It’s hard to deliver innovative and adaptive programmes at scale since they are a moving target and since there may be an insufficient understanding of how and why they work and what aspects of them are replicable or scalable. Also not everyone is a natural innovator, even if given training and tools, and innovation often needs a lot more hands on support and so there might be limits to how far we can expect public servants and aid workers all to be productive working in this fashion.
Of course if we want to find breakthroughs in development it can be hard to do so if we only do so by starting out from established approaches. Sometimes counterintuitive and radical ideas are needed to break though our existing paradigms of thinking that might limit us to incrementally improving solutions that are only partially working at best. Duncan Green has an excellent blog post about this notion drawing on Robert Chamber’s work and giving “Community Led Total Sanitation” as one example of a highly successful new approach that broke the mold of existing thinking (shameless link to something I worked on in UNICEF about this).
So how do we balance the two approaches?
I’d argue that we need two parallel but interacting approaches to our development work:
One is the more mainstream work of programmes that are designed largely based around existing “scientific” knowledge and experience, often codified into rules, procedures, tools and case study examples. This is mainstream development programming which is also attempting to scale up known successful approaches. These need to be continually evaluated and studied and the knowledge from experience and formal study needs to be fed back into the system to incrementally improve it. And when the tools and procedures are applied they need to be done so thoughtfully to take into account local context, and specific challenges and opportunities as they arise, as well as based on feedback they receive – but within an overall agreed approach.
The Other is an experimental, iterative and interactive approach that deliberately tries out new ideas including ones that seem counterintuitive or unlikely. One that test out commonly held assumptions. One that is willing to discard unsuccessful approaches or adapt them fine tuning or even totally redirecting efforts in the course of the programme in order to find out what works based on real-time feedback. This approach should also seek to try out multiple parallel experiments on the same project at the same time – even if they seem mutually contradictory. These ‘experiments” could be in new areas where little knowledge exists, but they should also be used to try out radical new ideas in areas that are also well trodden.
But these experiments need to be carefully documented and studied (and also networked) in order for the insights from these experiences to be internally digested, shared and also reflected upon by others. The aim here is to identify approaches or elements from them that might be susceptible to being scaled up – or aspects of them that might be adapted or turned into tools and procedures or approaches that can be used by others. Adaptations of the same basic innovative approach might also need to be tried in different contexts to better understand what makes them successful (or not). The innovations can then turned into something that informs and improves mainstream thinking.
So in conclusion, I’d argue for a portfolio approach to development where perhaps a major part of the work is relatively mainstream – consistent and only evolving slowly over time as approaches are refined, but with a smaller, but significant (and certainly larger than at present) segment that is deliberately trying to break new ground through an innovative and adaptive approach – but with good systems to connect the two such that breakthroughs developed by the innovation stream can be tested and if suitable incorporated into mainstream thinking, even if they upend current thinking and approaches.