Participatory ProLogs
November 29th, 2006
As part of Robert Chamber’s Workshop on Participatory Methods at the DevNet Conference, people were invited to speak on their participatory experiences. I was already thinking about the “participatory†approach I had taken with developing the ProLogs software, and somewhat hastily decided to share my experience.
For those of you who don’t know, ProLogs is a database which I developed for an International Humanitarian NGO to manager logistics information. It is used by the staff of the NGO, many of who do not have a huge amount of computer experience.
The initial specifications for ProLogs came from the director of logistics, in New York, but the entire database has been developed in the field, working closely with the staff who are using it in the field.
This is where the participatory approach comes in: Because I am working closely with the staff who are using this database, they can help me to improve the design of the database. Every step along the way, I have been able to check features with the staff who will be using them. When I sat with the staff to train them, I made notes on what they found hard to use, looking for further improvement. I also actively encouraged the staff to make suggestion for features which would help them. This added to a number of features to improve the software, which I would not have been able to come up with on my own.
Some of these ideas are borrowed off the principle of Agile Software Development, but I think that they can be develop further.
I’m not how participatory my experience was in the development context. However I think it made an interesting contribution. I should have put more time into preparing what I said, as I’m not sure if I made myself entirely clear, especially the fact that I was working with staff members and not the community. I did receive a number of criticisms from some of the people:
The database was only in English
Yes, it would have been possible to write a multilingual database, but very hard, and considering the NGO works in over 20 different countries, very time consuming. All of the logistics staff speak some English. I think there needs to be a balance between diversity and efficiency – how else are we going to build the Tower of Babel?
Using a database ignores the traditional methods of recording information, eg. writing things on a tree stump
While I believe that it is important to observe traditional methods, I believe that they have their limits. The NGO I worked for was providing relief for the 2004 Asian Tsunami, and 2005 Pakistan Earthquake, and services for camps containing thousand of people in Africa. I am not aware of any traditional methods, which could handle information for projects this size – you would certainly need a fairly large tree stump. The optimal solution would be to incorporate traditional methods into modern technology, and by listening to the feed back from the staff, I hope I aided this.
The database was imperialistically reinforcing western ways of doing things.
I should have emphasized the fact that this was used by the logistics staff. The NGO I worked for is moving to more community based work, where the focus is on the community, and the logistics staff do not have such a large involvement. However in emergencies, the western systems are very effective at supplying large amounts of food, water, health care and other essentials.
Giving the NGO workers databases, and computer skills, increases the gaps between them and the beneficiaries.
The Ol’ Digital Divide. I may have misinterpreted what this person said, but I believe what they are arguing for is to avoid training people in developing countries, because that will create a gap between them, and the other people in that country who they are trying to help. This is true, but by not training, the gap will still exist, just on a higher level – between people in developed countries and developing countries, so I think that this argument isn’t very valid. I also believe that knowledge will trickle down.
The only way to remove the digital divide, is through training people in developing countries, pushing the gap further down, until everyone is educated and there is no more divide. Or destroying all technology.
Why do you need expats to do this sort of work? Why can’t you get people to develop the database in developing countries. I was given the example of someone in Afghanistan, who had taught himself how to program, and designed a number of databases for the organization he worked for.
I agree. Programming really isn’t that hard. But just as there is a difference between a builder and an architect, there is a difference between someone who can write code, and someone who can understand what the specifications are, design easy to use software, and write good code. I have seen some pretty awful databases, and there is a skill to deigning them well.
I know that there are people in developing countries, who can program databases, many of whom, better than me. If they had done it instead of me, that would have been just fine, but they didn’t. I hope that in future more software for NGOs is written by people in developing countries, and I hope to train more people to do this – maybe then I can take a holiday!
I may seem a little defensive here, at the time I did feel rather attacked! But it is good to hear and consider all of these points. If anyone has anything further to add, please leave a comment or contact me.
December 19th, 2006 at 4:41 am
[...] An opportunity was given for people who had had experience in participatory projects to present their work to the group. I thought my experience developing ProLogs had been rather “participatoryâ€, and presented that to the group. I’ve posted the full details here. [...]
December 21st, 2006 at 12:29 am
“I may seem a little defensive here, at the time I did feel rather attacked!”
Welcome to the world of academic conferences. Some people actually enjoy attacking what others have done and will go to any lengths to do so, no matter how good the stuff presented is or how well it’s presented. You learn to live with it eventually.