Tag Archives: ICT

Themes from our Capacity Building Workshop

In October, the ESAR Office hosted a T4D Capacity Building workshop which brought together programme and ICT staff from 19 of our 21 country offices to discuss the both challenges and possible solutions for managing and scaling T4D and innovation projects. The workshop served as a good platform for information sharing and learning between country offices.

We are pleased to share the post-workshop report which serves as a summary of the sessions and discussions during the workshop. It offers a brief analysis of the common challenges met by Country Offices during T4D implementation, some practical examples and opportunities for integrating T4D into programmes, and a summary of the tools proposed to assist with T4D project management. Finally, it summarizes the key outcomes and offers a roadmap for future support from the Regional Office: ESARO T4D Capacity Building Workshop Report

To learn more about the individual sessions, check out the presentation put together by our facilitation partner for this workshop, ThoughtWorks, which highlights the main points of each session: T4D Synthesis-FINAL

We would like to thank all of our participants, especially those who shared case studies from their offices. Whether or not you attended the workshop, we hope this report will serve as a learning opportunity and spark discussion for those working on T4D and innovation initiatives.

Advertisements

Weekly T4D/Innovation Insights & Updates #4

Wishing everyone a Happy Friday. For this week’s installment of ESARO’s T4D/Innovation Insights and Updates, we’ll take a look at some of the worst practices of using ICT in programme sections.

http://blogs.worldbank.org/edutech/worst-practice

While this blog post specifically focuses on using ICT in education, the lessons can be applied across all UNICEF programme sections.

  A quick look at the worst practices:

1.     Dump hardware in schools, hope for magic to happen

2.     Design for OECD learning environments, implement elsewhere

3.     Think about education content only after you have rolled out your hardware

4.     Assume you can import content from somewhere else

5.     Don’t monitor, don’t evaluate

6.     Make a big bet on an unproven technology (especially one based on a closed/proprietary standard) or single vendor

7.     Don’t think about (or acknowledge) total cost of ownership/operation issues or calculations

8.     Assume away equity issues

9.     Don’t train your teachers (nor school headmasters, for that matter)

10.   _________(No. 10 is purposefully left blank to reinforce that many other worst practices exist.)

However, knowing the “what not to dos” is only part of the learning process as we become more familiar with integrating T4D in programme delivery. Last month Global Innovations launched the Child Friendly Technology Framework to help programme sections think through some of the challenges that arise when designing a new project with a tech component. With the help of 52 worksheets to stimulate thinking and discussion, the framework helps guide a new project from the idea stage through producing a Concept Note and Executive Summary to guide project implementation..

http://unicefstories.org/2013/08/06/child-friendly-technology-framework/ 

 Hopefully, by utilizing some of the planning tools such as the Child Friendly Technology Framework, we can avoid committing some of the “worst practices” mentioned.

 

Coming to Terms with Failure in T4D and Innovation

“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:

  1. Failure to involve beneficiaries and users: those who can ensure that project designs are well matched to local realities.
  2. Rigidity in project delivery: following a pre-planned approach such as that mandated by methods.
  3. Failure to learn: not incorporating lessons from experience that arises either before or during the ICT4D project.
  4. 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.
  5. 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.

What happened?

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.

Scalability Issues:

  • 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.

Take Away?

  • 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.

What happened?

Equipment:

  • 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.

Take Away?

  • 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.)

Sources:

“Can a Process Approach Improve ICT4D Project Success?” Richard Heeks. http://ict4dblog.wordpress.com/?s=failure