One of the cornerstones of our work supporting waterpoint monitoring in Malawi has been the creation of custom software for local government use. The software allows government staff, with limited computer skills, to produce powerful and user-friendly summary tables and maps based on very simple data. So far it’s been very popular with staff at district water offices across the country.
An example of mapping output from our software. (Note: in this case using fabricated data).
As our approach with districts has been getting increasing attention, we’ve been getting requests from different stakeholders to add more and more functionality to the software. Requests have ranged from maps showing political constituencies, to more data on specific waterpoints, to information on community mobilization.
A couple weeks ago, while attending a major conference on water/sanitation mapping (my first such opportunity), a new realization finally crystallized for me. There are a lot of software packages already out there for database management and mapping. Creating your own can be very useful in a specific context. However, at some point of desired software functionality, it’s probably better to stop trying to reinvent the wheel, and just use what’s already on the shelf. Being a visual person by nature, this realization led me to the following graph:
Technological Inflection Points in Waterpoint Monitoring – Shown Graphically
What this is trying to show is that custom software can be great, up to a point, but if you want to do something really complex, then eventually you just have to bite the bullet and use the real stuff.
For instance, our software application works by allowing district staff to manage their own database of rural water access (in Microsoft Excel, with which they’re usually familiar), produce summary tables breaking down raw data into useful statistics (happens automatically using a Pivot Table linked to their database), and produce maps at the click of a button using a custom VBA macro. We keep it obsessively simple, and generally it works well.
An example of statistical summary information produced automatically using our system.
The advantage of this approach is that we can train someone in the basics of database management, information analysis, and map production in only a few hours, often less. This lets the user quickly move on from struggling to manage the database to using it to make improved decisions. Training someone from scratch in the equivalent skills using a more traditional ArcView/MS Access approach would take days, if not weeks.
However, if we wanted to help someone manage a database with ten times as many indicators, calculate 15 different custom statistics, generate 10 different types of map, update in real-time while automatically analyzing trends, etc., then it would probably better to bite the bullet and do it using conventional software approaches. It wouldn’t be easy, and it may not be possible, but it’s easier than trying to create a bloated custom application which tries to make extremely complex tasks simple and user friendly, and ends up collapsing under it’s own weight.
The point I’m making is similar to my last post. Custom waterpoint monitoring software applications can fill a niche. I think our application is doing a very good job of that at the district level in Malawi. But it’s unrealistic to expect them to do everything. Understanding where the inflection points are is key to understanding which approach makes sense.
Barefoot Economics 