ICTworks

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.