Tag Archives: Scalability

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.

Weekly T4D/Innovation Insights & Updates #5

Over the last couple of weeks, the Weekly T4D/Innovation Friday posts have covered some of the ins and outs of scaling innovation, worst practices in ICT4D, and challenges and opportunities of T4D application in programme delivery. Some of the themes that have emerged are the need to think about scale from the beginning, fail fast, and involve the end-user in the design process.

This week we’re going to focus on the why and how to involve the end-user in T4D and Innovation initiatives with a look at the blog post, “Building Human-Centered Design into ICT4D Projects.”

https://bestict4d.wordpress.com/2013/07/18/human-centered-design/

KEY TAKEAWAYS:

What is human-centered design?

  • “A problem-solving process that puts humans at the very center.”
  • 3 components: 1) learn from a community/end-user to understand the problem; 2) ideate and prototype rapidly; 3) feedback from real users quickly and frequently.

Why is human-centered design important in the social sector?

  • “In international development you have projects being implemented thousands of miles away from where decisions are made. Frequently, there’s no feedback loop so it’s hard to say: Is it working, and are people choosing to use this?”

Why is human-centered design important to the field of ICT4D?

  • “In general the development community is very risk averse…One of the benefits of human-centered design is to mitigate risk by testing early and failing fast.”
  • “In the context of ICT4D, human-centered design can help with the design of a technology, and the context around it, long before the technology is ready for launch.”

Is failure at certain times not only acceptable but important?

When you learn from it, failure can be a very positive part of the process. You want to try to get some of the failing out early so that you can learn from it and let it influence the design of a better more successful project.”

In October ESARO facilitated a T4D Capacity Building Workshop, and one of the sessions focused on human centered design. After learning some of the basics, participants discussed how human-centered design can be incorporated into UNICEF T4D programming, two conclusions emerged:

  • Human-centered design can be used internally to identify priority areas for T4D application;
  • Understanding the process can help manage external vendors such as software developers during the iterative software design process.

For a closer look at the human-centered design session, please see page 12 of the conference report.

https://drive.google.com/file/d/0B101gFvV4LzKRXVHenlWeTlOZXc/edit?usp=sharing

 

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