There’s a phenomenon in the science world known as ‘multiple independent discovery‘. It’s where “similar discoveries are made by scientists working independently of each other” and the Theory of Evolution, the jet engine and the television can be counted among its ranks. Not that any of my work comes close to any of these, it was no surprise when I recently announced my Donors Charter to learn that friends on the other side of the Atlantic were working on something very similar. Or at least that appeared very similar.
My Donors Charter was borne out of a specific frustration that donors often appeared to be funding ICT4D projects they shouldn’t. The result? A sector full of replication, failed pilots, poorly thought-out projects, secrecy and near-zero levels of collaboration – none of it useful.
The Charter was an effort to encourage both donors, and project owners, to ensure they were clear about what they were planning, why they were planning it, and how. The questions didn’t seek to steer them in any specific direction, or encourage them to choose one technology solution or principle over another, but simply to be clearer about the what, why and how of their idea. The questions fell into three categories:
Preliminary questions
- Do you understand the problem? Have you seen, experienced or witnessed the problem? Why are you the one fixing it?
- Does anything else exist that might solve the problem? Have you searched for existing solutions?
- Could anything that you found be adapted to solve the problem?
- Have you spoken to anyone working on the same problem? Is collaboration possible? If not, why not?
- Is your solution economically, technically and culturally appropriate?
Implementation questions
- Have you carried out base research to understand the scale of the problem before you start?
- Will you be working with locally-based people and organisations to carry out your implementation? If not, why not?
- Are you making full use of the skills and experience of these local partners? How?
Evaluation and post-implementation questions
- How do you plan to measure your impact? How will you know if your project was a success or not?
- Do you plan to scale up or scale out that impact? If not, why not? If yes, how?
- What is your business/sustainability model?
Transparency questions
- Are you willing to have your summary project proposal, and any future summary progress reports, posted on the Donors Charter website for the benefit of transparency and more open sharing?
None of these questions are difficult, none are particularly technical, and it’s perfectly reasonable to expect anyone starting a new project to be able to answer them. These are, in my view, the kinds of questions everyone should be working through because, well, they’re common sense. Anyone who hasn’t thought any of this through really needs to go away and think, plan or research a little more. And if it comes to it, yes – drop their idea.
There’s a dual benefit to all of this. Firstly, it would force implementers to consider key issues before reaching out for support, resulting in a reinforcement of best practice. Secondly, it will help the donors themselves by focusing their resources and dollars on projects which are better thought-out and less likely to fail.
Shortly after announcing the Charter last August I was pointed to another site – billed as ‘the same thing’ – which had just been launched a few weeks earlier. This site was billed as the “Principles for Digital Development” and it too had a list of things people needed to consider while designing their project. Unlike my Charter, which was scribbled in the back of a notepad during a train journey home, the Principles were the result of an extensive amount of work by a range of ICT4D players and partners including The Bill and Melinda Gates Foundation, USAID, UNICEF, The World Bank, SIDA, The State Department, WHO, HRP, UNHCR, WFP, UNFPA, UNDP, Global Pulse, UNWomen and OCHA.
After reviewing the Principles (you can download a PDF of them here) I quickly decided that they weren’t ‘the same thing’, although they were undoubtedly useful. Despite that, they came up again in a comment posted by Wayan Vota, who pointed people back to the Principles in what became the mother-of-all-discussions on the Charter in my Stanford Social Innovation Review (SSIR) article. I decided it might be useful to seek some clarity because I still didn’t agree that they were the same, and asked him:
1. Who are the principal audience? Is this to remind solutions developers what they should be doing? Or for donors to sense check proposals?
2. Are they going to be enforced in any way? If not, what’s different about this than all the other sets of ‘best practice’ we’ve seen over the past decade?
3. Who’s ‘signed up’ to the Principles, and what does ‘signing up’ actually mean?
4. I’m curious who else was consulted beyond the giants of the development community listed on the site? There seems to be a lack of any grassroots voice, or any of the smaller organisations who probably have a lot to share from their experiences.
Surprisingly I didn’t get a reply, although other friends at USAID did inform me they planned on writing a response to the SSIR piece. So, while I wait to hear their thoughts, here are four of mine on why the Charter and Principles are not ‘the same’.
Firstly, in many places the Principles are quite technical, and anyone other than a software developer, design thinker or ICT4D professional may struggle to understand them. For example, “Design solutions that learn from and enhance existing workflows and plan for organizational adaptation” isn’t useful if you’re a grassroots innovator trying to fix a local problem. The Charter is deliberately non-technical, aimed at everyone, everywhere.
Secondly, the Charter simply asks questions to help ensure projects consider the wide range of issues they may need to address. The Principles makes direct suggestions on how projects should be designed and run.
Thirdly, and perhaps more dangerously, the Principles apply a broad-brush approach to ICT4D project development. “Employ this”, “Apply that”, “Demonstrate this” and “Demonstrate that”.
Fourthly, the Principles steer projects in a specific direction with their recommendations, which is again dangerous. For example, “Design for scale” should only apply if the project wants scale. What if it doesn’t need to scale? “Develop software to be open source by default” implies that closed source is less effective. If we look at the evidence, is that really the case?
If the Principles are aimed at the very organisations that took part in their development – many of them the heavyweights of the ICT4D world – then that’s fine. They’ll have the knowledge, money and resources to make sense of them and deploy them in their work, and it sounds like many of them now do. That’s great news if it works for them.
But for the people and projects I’ve spent the best part of my 20+ year career working with – largely grassroots non-profits, and local social actors and innovators – they’re not much use at all. Even if they could unpick some of the development speak, they’d struggle to act on many of them. One of the biggest problems, as I’ve seen it over the past few years, is the increasing institutionalisation of international development. In 2015 it’s going to get worse, not better.
I believe now, more than ever, that we need to be more inclusive in our work, and although the Donors Charter – unlike the Principles – has very little chance of being adopted by donors anywhere, it is at least aimed at the ‘everyday innovators’ who will – quite rightly in my view – end up being the future of the technology-for-development sector.
