Mariel Verdi's blog

5 Lessons Learned Deploying ICT in East Africa


Computer lab deployment at Luteete Secondary School in Wobulenzi, Uganda

Being the first to do anything is tough. It is filled with challenges and unknowns. Thankfully, you don't have to be the first to deploy ICT in East Africa. In fact, you'll follow in a long line of others who have tried - some with failure others with success.

I'd like to help you be the latter group. So here are a few hard lessons-learned from deploying new technology for youth in East Africa. It is written in hopes that you will find it useful when planning your first deployment of development-focused technologies.

1. Never expect people to do what they say they will.

  • Test the technology yourself in the conditions it will be deployed. Do not operate under the assumption that the company that produced it has done so already. If you are going to put your name, or the name of your organization, behind a new technology, do some checks and tests yourself over an extended period before committing.
  • Make a detailed written agreement with all stakeholders about who is expected to do what and provide what. Include clauses for negative eventualities, such as recourse when one or both parties fail to meet commitments, or the procedures for dissolution of the partnership. It is best that this is in a written, legally binding form.
  • Make sure the company selling the hardware and software have fulfilled or made arrangements to fulfill its commitments before the project is deployed. Here are some guiding questions:
    1. Has the company selling the hardware fulfilling the promises they made in marketing?
    2. Am I getting a new, untested technology?
    3. Have all of the proper licenses needed to run whatever software is on the system been bought?
    4. Am I getting new parts in this technology, or is some of it recycled when it should not have been, and therefore may cause erosion issues sooner than expected?
    5. Does the final package have all of the parts advertised?

2. Keep everyone on the same page.

  • Make sure your implementers fully understand what they are getting into. If it is a pilot, tell them it is a pilot. If it is expected to be fully operational (i.e., not a pilot), tell them what you expect. If you're not sure, it is up to your discretion to tell or not to tell your people on the ground, but, as your grandmother may have told you, honesty is the best policy.
  • Communicate what is going on in the head office to your people on the ground. It creates a feeling of control even if there is no real transfer of power.

3. Make sure your hands are never tied.

  • Part and parcel to never expecting people will do what they say they will do, expect that you are going to have to negotiate and make compromises with various stakeholders. Make sure that you have ground on the negotiations when/if they do occur.
  • Retain your bargaining power by building mechanisms that allow you to have equal footing into your written agreements. Pay special attention to the following stakeholders:
    1. The technology providers
    2. Your implementers on the ground
    3. Technical support

4. Build in accountability tools

  • If you are working with private contractors, make sure that they know their requirements up front, and that you have that you have recourse when they do not fulfill their requirements.
  • If you want regular reporting from anyone involved, make sure there is some sort of punishment for failing to report.

5. Get regular reporting

  • Especially during a pilot, reporting is key. Knowledge of what is going wrong and right on the ground can be used to improve future deployments.
  • Regular reporting may include a lot of expenditure on your part, but if you really want to know what's going on, you may have to spend the money to call your people on the ground.


.

Get ICTworks 3x a week - enter your email address:

Mariel Verdi's picture

Mariel Verdi

My goal is to increase the earnings of people in low-income regions of developing countries

Human Capacity Puzzle Pieces in ICT4D Projects

Many computer labs go unused because no one in the community sees the need to use computers and therefore they have not even learned how to use them. Yet the community cannot return the computers nor afford their upkeep.

However, this is not the case regarding a computer lab near me in Kenya. The organization that sold the computers to the community provided intensive training to the lab managers. The youth center that owns the lab has plans to hold classes, as well as use the lab as an information center to educate on and prevent drug abuse and HIV/AIDS infection for the community. This demonstrates that they both had an idea of how to use the computers and had thought of activities for which they could be used.


Sustabale computer lab installation does not stop here

Instead, they faced three simple, yet seemingly insurmountable problems:

  1. Finding someone who could teach the community to use the computers and guide users in finding the information on HIV/AIDS or drug abuse
  2. Finding the money to pay that person on a regular basis
  3. Paying for the Internet access and bandwidth costs

These issues reflect two themes prevalent in many development projects: lack of funding and lack of initiative. First, the director of the program thought there was nothing to do until the money came to pay a teacher. Then he also did not think to volunteer as an instructor, or ask his center manager (also trained on computers) to volunteer, or search for a volunteer in the community.

About two months ago the missing piece of this lab's puzzle came into the picture: funding. The leadership of a community-based organization (CBO) met the managers of the youth center. After the CBO demonstrated that they were working with ICT and were knowledgeable about open source operating systems and packages (which this lab was running), the seeds of partnership were planted.

The CBO and the director of the youth center are now near signing an agreement whereby the CBO teaches computer classes to the youth center's target population at for small fee, and, in return, they have access to the computer lab to do their administrative work. Future plans to supply Internet access to the lab through the CBO's project are in progress.

The moral of the story is this, lack of knowledge on how to use or the usefulness of computers is not always the cause for computer's disuse in less developed countries. In some situations, the owners/managers are simply waiting for other pieces to fall in place.

Human capacity barriers are some of the most difficult to deal with in community-focused projects. Overcoming them is simply a matter of finding the right outlet for the resource that is needed. As we all know, change often takes time.

Soon, this lab will be drawing the community in for lessons provided by their fellow community members. As in all other endeavors, ICT for development projects should not end with hooking up the technology, it is finding the connections or resources needed to make it usable and useful for the target population.


.

Get ICTworks 3x a week - enter your email address:

Mariel Verdi's picture

Mariel Verdi

My goal is to increase the earnings of people in low-income regions of developing countries

Syndicate content