This is a second guest post by Paul Goodman who is supporting Plan Benin to solidify their SMS Reporting and Tracking of Violence against Children (VAC) project. More on the overall project and process via the links at the end of this post.
Future proofing? Wishful thinking! There is of course no way to “future proof” an ICTD project. There are ways, however, to ensure that an ICT project has a fighting chance at sustainability. Here in Benin we’re revisiting the entire VAC Benin workflow in an effort to document the non-technical aspects of the project so that each person that touches this system fully understands the way that information moves through it. In addition to supporting training, this small but critical step will help drive consensus around how the project should and can work well into the future.
A succinct overview of this project:
The beginning of any development initiative is often marked by energetic optimism. At the onset, when a project enjoys the attention and enthusiasm of its creators and supporters, it is easy to forget that over time this attention will wane, priorities will shift, and critical personnel will undoubtedly take on new responsibilities or even different jobs. Purposeful problem definition and documentation can minimize the impact of these eventualities and only with a thorough understanding of the problem is it possible to discuss appropriate technology-enabled responses. And yes, in the real world, the problem often shifts over time as the situation changes or new information comes to light. But with a well-defined problem you have clarity around your intent and can face new challenges head-on.
Once defined, the problem and corresponding solution must be documented so that others may benefit from the insight gained during this process and apply that insight systematically. This seems elementary, of course, but in years of ICTD work I’ve found that the documentation of both technical systems and non-technical processes is often neglected in the rush to deploy or as a result of over-reliance on a few knowledgable individuals. Furthermore, in international development, documentation sometimes plays second fiddle to the production of reports and case studies.
Now I’ll happily get off my soap box and get back to business in Benin.
After sketching out the various aspects of the information flow with my colleague Elsie, I documented the workflow in a way that can be used to inform, train, and guide others as they interact with this project. I’m working on reference materials of different shapes and sizes including a number of graphics. Several of the graphics appear below; these are drafts and will be revised with Elsie, translated, distributed to the team, and revised again. These graphics represent the way we would like the system to work and are intended to be living documents.
In this graphic I included all the critical actors and their key responsibilities:
In this flow chart, I illustrated the way that messages should be processed:
In this graphic, I illustrated the way that reports should be created:
Finally, this flow chart will support report approval and verification:
Update from Benin: charting a course forward (also by Paul)