A Small, Imperfect Role in Malawian Identity
Over the past two years we’ve had occasional involvement with a very interesting research project in Malawi. Malawi is in Africa, near Zambia, Tanzania, and Mozambique; I’ll save you the search. The project has to do with microloans. If you want to know more, or get involved, check out OptInNow, Kiva, BRAC, and perhaps the Grameen Foundation and the Acumen Fund.
I know I don’t have enough pretty pictures in my post but Shutterfly, where some of the project photos are posted, is really not helping today. Ok? Ok.
More specifically, the researchers wanted to find out if they could increase repayment rates (and thereby strengthen the effectiveness and permanence of microcredit) in Malawi by showing people that they could be uniquely identified. Malawi, like many areas in the world, has no pervasive Social Security Administration, Department of Motor Vehicles, or other widely accepted way of uniquely identifying its citizens. So, intentionally or by accident, people were able to receive multiple loans in different villages – thanks to misspellings, miscommunication, moves, or other natural bureaucratic phenomena. Perhaps some people really wanted to pay their loans back but were unable to find a reliable way to do that.
Don’t quote me on these figures, but I think Malawi had a repayment rate in the 70% range while other areas such as Bangladesh are able to report repayment rates closer to 98% or 99%. A good problem to fix!
The research team located a vendor of small, rugged fingerprint scanners, and contacted me to see if I could help build some software they could use in the field. I was very interested in the project, because it meant a short escape from the day-in, day-out web applications. Unfortunately, the project did not go perfectly. The remainder of this post attempts to describe, and learn from, the various things that went wrong.
The application we built had several main tasks: Collect fingerprints, identify people using their fingerprints, and merge fingerprint databases. Believe or not, small villages in the Malawian outback are not internet enabled, so collected data had to be manually merged into a central database after each collection run.
- The fingerprint scanner vendor supplied a suite of software developmest kits (SDK), but the only one I could reasonably hope to work with (Java) wasn’t my main area of expertise (PHP). These SDKs were also quite finicky and it was sometimes impossible to tell why it was working or not working.
- The fingerprint scanner vendor released a new version of their software which probably worked better on Windows XP-64 bit and Windows 7, but for reasons probably having to do with the very fine print of grant applications, it was never purchased or deployed as an upgrade.
- Timelines for delivering various components of the project were too short. Timelines are always too short, in all kinds of projects, all over the world. In this case, it affected our ability do develop slowly and carefully, and meant that not many “test runs” were possible in the field before they started collecting real, experimental data.
- Some unknown issue, perhaps tied to the above bullet points, or some mistake we made, led to the corruption of some of the collected data. This means the researchers couldn’t do the entirety of what they needed to do with the data.
So, how to do it better next time?
- Refer the project to someone else. Even though the timelines were too tight for anyone to do a search for a Java-specializing firm, I should have put my foot down and insisted the project was not right for us. It’s funny, once delivering something by next month is known to be impossible, the deadline can magically be extended or reshuffled. It may have led to a delay in the first phase of the project, but would probably have led to a better end result.
- Insist on good tools. Developing on the older version of the SDK took probably twice as much time as it would have with the newer, more compatible one.
- Test, then test more. Testing and QA are hard. Very hard. It is important for everyone, developers and clients, to perform thorough tests. It is important to test at the beginning, and then to test again while you think everything is going fine.
It’s harder, less fun, but much more useful to talk about things that didn’t work out than the things that did. Thanks for this post.
I think coming up with a list of success factors before doing a project that the client can review and check off that they’ve made adequate preparations is really important. Consultants can only do so much, and guaranteeing the success of a project cannot solely rest in their hands alone, as many org mistakenly believe.