⇓ More from ICTworks

Want to Scale ICT4D Projects? Stop Developing Software!

By Wayan Vota on March 29, 2013

mhealth-projects-uganda.jpg

Recently Priya Jaisinghani, Teressa Trusty, and I brought together a few folks to have an informal Technology Salon around the pertinent question of how can the development community get technology to scale?

Be sure to sign up to get invited to future Salons.

We all know we have a problem – just look at the map above. We say our work in ICT4D, M4D, mHealth, ICT4E, etc will reach “scale” and even (financial) sustainability, yet the reality is a profusion of similar software and technology applications around the world that never leave the pilot phase. We focus on responding to RFP’s that ask for something new or innovative with limited, bespoke solutions that die the day after funding ends.

We keep reinventing the flat tire.

This problem isn’t confined to one group – funders, implementers, techies, dev experts, we are all complicit. We all have sinned in the name of scale and sustainability. It is time for us to come clean, make amends, and seek a better way forward. To that end, we came to three key conclusions:

1. Have Buy-in From the Beginning or Walk Away

Too often both “scale” and “sustainability” means a vague paragraph in a long-forgotten proposal. We need to get serious about both.

For scale, we need to recognize is it relative to the project size. Some projects reach scale when 100% of a small community changes their situation, others when a majority of citizens in a country change their behaviours. Yet, not every project is going to be regional, national, or continental – and that’s okay. “Scale” does not need to mean “global”. This is a lesson that many funders can afford to learn.

At the same token, “sustainable” does not need to mean free from donation funding – as most religious organizations can attest. It does mean that as international actors, we need to have local buy-in to the intervention, where whomever we are working with agrees from the beginning to not only support the project long-term, but also have a clearly defined plan for that support.

Now this can be government adoption (and funding) of the activity as a new service to the community. Or it can be fee for service, a social enterprise, or even a for-profit service. The business model can take many forms, but as implementers, we have the responsibility to make sure there is a clear handoff that is expected and planned for.

For both of these parameters – scale and sustainability – all of us have to be braver. We must be willing to point out when either parameter is failing and be willing to walk away from a project if it’s not corrected. Yes, that’s easier said than done. So is real scale and sustainability.

2. A/B Test Everything

In web design, there is a concept called A/B testing, where you develop two (or more) version of a page and test to see which one has the better response rate. In fact, every Salon invite is an A/B test – 10% receive one email, 10% receive another, and the version that is opened more is sent to the remaining 80%.

What if interventions were A/B tested? Say the top two ideas were awarded pilot funding and the service that had the best intervention result received full funding to scale – something like USAID’s Development Innovation Ventures. Or if proposals were written to be honest about the need for local consultations, and rather than prescribing a solution after a short bout of rushed research between RFP announcement and deadline, implementers won based on their post-award intervention research and solution design, in addition to actual implementation methodology.

A/B testing doesn’t stop at project start. You can A/B test every step of the intervention process, constantly tweaking the project to make sure its optimized for the outcomes desired. Yes, you can say we do that now – but are you tweaking your formula hundreds of times every year like Google?

3. Stop Developing Software

The most contentious point that came out of our Salon was the idea that international development organizations should not be software development organizations. Specifically, with the reality that specialized software development organizations exist, and that they will be better than development organizations at software development, if you focus on health, education, agriculture, etc, you should focus on the intervention itself, not the technology that you use to achieve your goals.

In fact, we should have a registry of industry leading solutions – ranked software tools where we can all plainly see which are the few (3 to 5) tools that we should concentrate our efforts on. Like say this list of mobile data collection systems that came out of a previous Salon.

Only then, when we are all bought into the same tool set, can we really get scalable solutions that are robust, with the longevity for our lengthy project life cycles.

Ideally, all these tools would be Open Source to allow everyone to build on the code base and use it freely. In fact, one participant was adamant that all software development funded by the international community should be Open Source. And really Open Source – licensed as such and on GitHub.

OpenMRS, the world’s leading open source enterprise electronic medical record system platform, was put forth as a great example of this process. I personally think Tangerine should be next, becoming the leading electronic data collection software for early grade reading and mathematics skills assessments.

Yet even now, how many other medical records or education data collection software exist? Do we really need more? Shouldn’t the development industries – software and international – come together and focus on the proven tools instead of inventing more?

Or are we destined to see more mHealth moratoriums?

Love this discussion? Sign up to get invited to future Salons.

Filed Under: Software
More About: , , , , , , , , , , , ,

Written by
Wayan Vota co-founded ICTworks and is the Digital Health Director at IntraHealth International. He also co-founded Technology Salon, MERL Tech, ICTforAg, ICT4Djobs, ICT4Drinks, JadedAid, Kurante, OLPC News and a few other things. Opinions expressed here are his own and do not reflect the position of IntraHealth International or other ICTWorks sponsors.
Stay Current with ICTworksGet Regular Updates via Email

5 Comments to “Want to Scale ICT4D Projects? Stop Developing Software!”

  1. Bravo Wayan, I was so happy to read this post…

    I have been working for the past 3 years to develop softwares to teach reading , which are adaptable to different languages and technology (web,mobile…) . Our mission is to work for developing companies. For instance we are currently making a Khmer version with World Education (USaid All Children Reading Grant).

    But beyond Smart4Kids software, I have tried to promote the idea of going away from “tailored made” to move toward “localizable” software in order to address the sustainability issue. Watch my unesco presentation on the subject: http://www.slideshare.net/isabelleduston/smart4kids-unesco-2013

    Thank for your post, they are always a great source of inspiration:)

    Isabelle

  2. Clark Ritchie says:

    I’ve always termed this “funder driven development”.

  3. Great post, and I completely agree that all software should be Open Source. Our human resource information system software, specifically targeted at health systems, has been Open Source from the beginning. Initially, we did have to develop the software in-house as proof of concept, but because it is Open Source code, we are now seeing development moving to the countries where the software is actually being used. Agreed that we do not need to reinvent the wheel each time, but we those of us who are developing software — or partnering with software developers — should be talking to one another and working from the same standards so that our software can interoperate easily.

  4. Torbjörn Fredriksson says:

    Interesting post. Let me draw your attention to UNCTAD’s Information Economy Report 2012 (www.unctad.org/ier2012) which discusses how to strengthen the capabilities of developing countries in the area of software development. The report, among other things, features the role of Open Source (chapter IV) and also argues that whenever international organizations need to develop new software for their development projects, they should try to engage talent in the South rather than only relying on programmers in the US or Europe. CodedinCountry (www.codedincountry.org) is an interesting initiative in this context.

  5. Agree and disagree. International development organizations spend a lot of time and money building software (or hiring outside tech firms to custom build software) that they only use themselves. They should spend that time and money focusing on their core strengths: building content and implementing programs – not managing technology infrastructure, which frequently is not one of their core strengths.

    The problem with the “leading” software tools are that they either a) require significant technical expertise and infrastructure to set up, implement, and manage, making them impossible for NGOs without big tech budgets to use; b) are very basic in functionality; or c) can’t scale.

    Most NGOs need tools that non-tech people can use to implement programs – tools that offer robust functionality and that easily scale.