Below I am reporting an ironic contribution by Wayan Vota of ICT Works on the sustainability of “pilotitis”. I agree with all the points mentioned. I might have ordered them differently in terms of priority. One additional reason why ICT4D efforts persistently fail, without delivering learning, is because of insufficient research and understanding of the underlying problems. My pet hate is how opportunities are wasted on addressing problems which are merely symptoms.
One overarching theme from the recent Mobiles! Conference was the need to get past pilotitis – the too many small projects that never scale, dying the day the original funding dries up. Now how we can do that is a matter of some debate, and there are even folks who say we need more pilots.
Regardless if you think we have enough pilots or not, I know exactly how we can scale pilotitis in ICT4D. After extensive cross-sectoral research in everything from FM radio, to laptops, to mobile phones, here are the 7 simple ways I’ve learned to ensure pilotitis spreads well beyond ICT4D into every aspect of development:
1. Have more hackathons and contests
What says transitory impact more than a one-day hackathon that brings together those not immersed in the real needs of a program to build beta versions of one-off applications without buy-in from end users? Having a low/no prize money contest via Facebook “Likes” so more people can make flashy demo software never meant to scale! That’s the best way to make compreneurs instead of entrepreneurs.
2. Only give out small grants
When you really want a lot of pilots that die the day the funding ends, make sure to start with small amounts of one-off funding with no pathway to future financial support. Grants of $50,000 or less are perfect seed capital that will not give a project enough room to grow into something lasting, especially if you demand that the funding lasts 2 years, require that any revenue generated reduces the initial funding, yet don’t ask for business plans, regardless of grant amount.
3. Focus on small organizations, or no organization at all
Why bother with large companies or organization with international reach and a history of stability – that’s just a nice way of saying “overhead”. Better is to focus on individuals, small companies, “local” organizations, or better yet, start-ups that don’t even have a track record of existence, much less success. That way, you know the idea will die when they get bored or the funding ends.
4. Only fund innovation
Being the second person to fund or work on an idea is no fun. Worse is replicating an idea that already works. There is no fame in implementation. So don’t do it. Real pilotitis can only scale when everyone focuses just on the newest new innovation, the bleeding edge of change – unique ideas launched without any history of prior efforts or existing constituencies to quicken adoption. “Transience” is the new “resilience”!
5. Build new software
Why share code? We can spread pilotitis faster when we make sure that every project builds its own bespoke, proprietary software solution – because we need more software options. Oh, and don’t hire reputable software development firms to code innovative solutions, that’s not building capacity. Recruit inexperienced volunteers or hire lone coders who always brag how they won a recent contest but never seem to show up on GitHub.
6. Evaluate via photography
Why stick around for maintenance, support, or the f-word in development to appear? None of that is sexy. Nor is reading long, boring evaluation reports listing all the lessons (re)learned. The best way of all to scale pilotitis is to evaluate success through pretty pictures of children holding gadgets. That way we can reinvent the flat tire, again, and look good doing it.
In honor of Michael Trucano’s Worst Practices in ICT4E, I’ll leave #7 blank for you to fill in. I know you have your own ideas on how to scale pilotitis and I’d love to hear them in the comments below or on Twitter.
Together, we can scale ICT4D pilotitis!
Posted by: Wayan Vota on October 9, 2013