“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.” Samuel Beckett
“Fail fast and fail forward. You learn and iterate. You document what you learn, share it with the world and look for insights wherever you find them.” Aleem Walji, World Bank Institute Director of Innovation Labs
These two quotes symbolize the increasingly popular modus operandi within the T4D and Innovation community. As T4D and Innovation mature, they are increasingly breaking away from the traditional operating paradigm that success is the be all and end all. Instead of hiding from our failures, we are attempting to learn from them and also accept that failure is an important step in the innovation process. The truth is that failures happen, but the crucial questions to ask are what do we learn from the experience, and moreover, how are the lessons learned applied to future initiatives.
Richard Heeks, Professor of Development Informatics at the University of Manchester and T4D thinker, outlined five broad reasons for why ICT4D projects fail:
- Failure to involve beneficiaries and users: those who can ensure that project designs are well matched to local realities.
- Rigidity in project delivery: following a pre-planned approach such as that mandated by methods.
- Failure to learn: not incorporating lessons from experience that arises either before or during the ICT4D project.
- Ignoring local institutional capacities: not making use of good local institutions where they already exist or not strengthening those which could form a viable support base.
- Ineffective project leadership: inability to direct and control the ICT4D projects.
Plenty of other reasons exist for why projects fail, but for all intensive purposes this list can be applied to most if not all. During the T4D Capacity Building Workshop in Nairobi during the last week of October, we learned about two UNICEF projects that failed. We applauded these the designers of these two projects for coming forward about the missteps taken, and more importantly we learned a lesson or two about what to avoid when planning future projects.
Case 1 – eNutrition and mHealth
This project aimed to design decision support applications to aid frontline health workers in child nutrition (eNutrition) and maternal health (eMNH) initiatives. An Adroid application was developed coupled with OpenMRS (an open source medical record system platform, more info here) was developed in partnership with a local NGO for two purposes: correctly identify, register, examine and treat malnourished children and increase adherence to national standards of care for antenatal care.
The project was piloted in six facilities with four facilities trialling the eNutrition platform and two the eMNH. Project implementers were initially hopeful about the pilot for three reasons. First, the project had relevancy since it was designed around the national Ministry of Health guidelines. Second, it was considered effective as the facilities where it was introduced reported improved and comprehensiveness of treatment. And third, the projects had impact as clients noted positive interactions with health workers using the eMNH and eNutrition platforms compared to comparator tools. However, despite these initial positive signs, the pilot revealed some serious flaws with the project design.
Lack of Sustainability:
- A comprehensive eHealth and eNutrition strategy was lacking as well as government leadership and coordination mechanisms.
- There was a missing link with HMIS (Health Management Information System), causing parallel databases with the national health information system, meaning that the two databases couldn’t communicate with one another.
- Health officials, the Ministry of Health, UNICEF and other partners in the nutrition and maternal health fields did not use the information that was gathered through the eMNH and eNutrition initiatives.
- The pilot was expensive
- It became incomprehensible to think of scaling the project to 25,000 CHWs or 6,000 + Health Facilities.
- No ICT staff was involved from the UNICEF side to advise.
- Involve ICT from the beginning.
- Complete an evaluation of the project during the pilot phase to know when or when not to scale.
- Need to have government on-board with projects in order to fulfill the UNICEF mandate to support governments.
- Think about ultimate ownership of the project from the beginning.
- Not focus on just pilot – beginning thinking about scale-up early.
- Think long and hard about the technology choice to ensure it fits the project needs and context.
Case 2- Connecting Classrooms, Communities, and Youth for Biodiversity Conservation
This project sought to design an open source communication platform allowing students from around the world to learn about and discuss global issues. Connecting Classrooms was developed in the developed world with the intention to be implemented in the developing world. The project aimed to put technology in students’ hands with the hope of empowering and connecting them to other students learning about similar issues. The diversity and remoteness of the host country environment is extremely challenging. Ultimately, the project creators were unable to negotiate the environmental challenges in the project design, which led to significant setbacks.
- Due to the challenging operating environment equipment needed to be rugged enough to survive, and this proved to be very difficult find.
- The project team, therefore, decided to outsource equipment selection and testing to an NGO. However, UNICEF experienced a supply nightmare after the NGO didn’t have the funds to buy the equipment upfront to then have UNCIEF buy them from the NGO.
- When the NGO designed and tested computers were no longer an option, the project team felt rushed and bought whatever equipment was available. However, the purchased equipment was ultimately inadequate for the environment.
- Failure to field-test negatively impact projects. Knowing the environment and conditions of end-users is critical when designing projects.
- Need to be prepared for the supply process and the rigid structures and bureaucracy of large organizations.
Even though the two projects highlighted above did not scale and qualify as “successful,” we should not discount the lessons learned. It is important not to be discouraged by failing, and at no times should the fear or cost of failure stop us from trying to innovate. Moreover, we should strive to be resilient to failure and not only learn from past mistakes. Failures happen, and as the two quotes at the beginning of this post stress, we should fail fast, recognize the mistakes, and then move forward.
For further reading on failures in ICT4D please see:
http://www.ictworks.org/2011/08/17/great-success-world-bank-has-70-failure-rate-ict4d-projects-increase-universal-acces/ (Encouragement to break with the status quo and not only publicize failures but embrace them.)
http://wayan.com/ict4d/10-levels-of-failure.html (Something to chuckle at.)
“Can a Process Approach Improve ICT4D Project Success?” Richard Heeks. http://ict4dblog.wordpress.com/?s=failure