ICTworks

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.