Help me out with this one.

There’s a giant question that I’ve been asking myself for a few weeks now, and I would like to throw that question out to anyone who cares to answer. First though, I should give the question some background, its origins, if you will.

I don’t think that I’ve explained my actual placement (work-wise) very much at all in my blog since I’ve been in Malawi. I had said that I was going to work with CCAP in Northern Malawi, but that changed before I even left.

Quick summary of my current job: I work in the Machinga District Water Office alongside the District Water Officer. The word “alongside” may be a little misleading though. Mr. DWO spends the majority of his time at out of town meetings and on field visits to new borehole sites, gravity fed scheme repairs, and other things of the like. When does come to the office, he will usually opt to spend the day playing a computer game in which you shoot little coloured gems out of a cannon, trying to hit other gems of the same color. The game’s soundtrack is bound to be nominated for some award someday. He is a wicked guy, that’s a fact, and we can talk about all sorts of things, but I’m not sure that he knows why I’m here and what I’m trying to accomplish.

Good question, why am I here and what do I hope to do?

There was a EWB long term overseas volunteer at this office before I was (he’s leaving Malawi in the coming few weeks) named Enam Rabbani. Enam worked hard to develop a system that could monitor the functionality of every water point in the Machinga district. Does the water point work properly? Or has it broken down? Simple. In the past, a system using GPS coordinates was used to mark each water source’s location and its functionality was indicated on a huge map that is now collecting dust behind Mr. DWO’s desk. It was a neat concept, no doubt, but its continuation in future years required ridonculous amounts of training, work, time, and money from all the players involved.

Enam took the idea of monitoring and developed a relatively simple, sustainable, and affordable system that is in its first full-out cycle as I write this. In short, paper forms are distributed through an existing system of health workers, from the district hospital, right down to each and every village in Machinga. After being filled out by village health workers, the forms then work their way back up the chain and end up sitting on my desk. (hopefully the DWO’s desk when I leave). Sure, there’s no fancy visual aid with the data like the map of the old system, but we do know each water point’s home village and we know the population in that area; that’s all we need to determine whether potable water supply is adequate.

So that’s good, we know which water points are working, and which aren’t. This is where I come in. My job is to design a system (or “tool”) that can analyze that data, and produce a work plan for the mechanics that are to be repairing non-functional water points. The basic idea is... Broken water points need to first be visited by the mechanics and taken apart for a diagnosis. If the necessary repair is fast and cheap, and the community can pay for a part on the spot, then the repair is done during diagnosis. Otherwise, the community is given a written quote detailing the price of a full repair, and a list of parts that the community must purchase from a local store before mechanics will return. Mechanics travel from village to village performing the diagnosis.

When a record of all quotes has been compiled, we then wait for villages to notify us that they have procured all the necessary parts for their water point’s repair and are ready for mechanics to return to the village. When a number of villages have communicated this, a route can be planned for the mechanics to follow, as they complete repairs along the way. These repair trips, as well as the diagnosis trips, must be planned in the most efficient way possible. This means that the time and fuel required to move from one area to another must be known ahead of time. The time it takes for each type of repair must also be known. Combining all of this information to use mechanics’ time as effectively as possible is part of my job.

So this is the system that I am, in a sense, responsible for. Now for the question that I mentioned earlier:

Imagine that you have been put into a very foreign situation to design something – anything. Your job is to satisfy a number of different players with the thing that you are designing, but you know almost nothing about the existing norms, institutions, organizations, and people that your project will need to coexist with. You have no co-worker that can walk you through each step, telling you if what you are doing is acceptable or even plausible. In this environment, what are the most important things to keep in mind as you move through an entire design to implementation process? What can you do check the assumptions you are constantly making? How can you determine, or at least predict, where your design will breakdown and where it will succeed? I know the question is an abstract one, but hit me with some abstract answers!

I forgot to include this earlier... MY PHONE NUMBER ("on a public blog?" you ask...) meh, it's free for me to recieve calls. Just please remember that I'm eight hours ahead of Edmonton time, and that I go to bed at about 8 (no power - it gets boring any later), and wake up at about 6. Feel free to email me ahead of time if you plan on calling. Using skype is by far the cheapest. Here she is: 265 993 160 266

Take er easy.

Ian