I would like to follow up on Margaret Grieco's plea, which we hear from
multiple sources, for some way of "taking stock" of what we know and
what we have learned in the area of ICTs for Development. The uses of
SMS for development is - of course - just a subset of that larger body
of knowledge.
It is worth spending a few words reflecting on why we are a couple of
decades into using ICTs for development and still unable to draw lines
around what works where, what doesn't work, and what we have learned.
Part of that answer is - again of course - that project funding and
unfunded grassroots initiatives seldom have a budget to do a proper
assessment of lessons learned. We are left with "good news" and "bad
news" versions of what happened, and in some cases public relations
stories about things that actually didn't happen or didn't happen that
way. Is there any way forward here?
One way forward would be to actually have an inventory of those actually
involved in the ICT and development projects, and - based on that
involvement - have some expertise in the area. Several projects
attempting to do this have stalled at the moment so I won't mention the
respectable agencies involved.
A collaborative multi-layer "network-of-networks" of regional and
area-specific inventories of expertise could support knowledge
networking and collaboration across projects. Much of that collaboration
would be virtual, using the tools themselves. The parts are there, but a
strategy for efficient and effective knitting together is lacking.
A second way forward would be for us to train ourselves to be more
careful when we talk about successess and failures. We need to describe
them in ways that lend the lessons learned to knowledge transfer. We all
know the unique properties of successful, and failed, projects: the role
of champions, and of stakeholder buy-in, the importance of attention to
context etc. We need to describe them as key parts of lessons learned.
All to often we point to the WHAT we achieved (or the technology used),
but not to the HOW we achieved it. We may waste a lot of words on the
WHY we did it when that was the obvious part. Of course, we still should
subject the WHY to ethical and strategic review and not just accept it
at face value. The three most dangerous words in the "WHY" of a project
proposal are "don't you agree..."
At a minimum we should be able to put the WHY of our successes and
failures into four categories:
1. Unique solutions to unique problems (context is everything)
2. Common solutions to unique problems (high diffusion potential)
3. Unique solutions to common problems (high diffusion potential)
4. Common solutions to common problems (why doesn't it diffuse?)
and go on with:
1. Unique failures to unique problems (low diffusion potential)
2. Common failures to unique problems (high diffusion potential)
3. Unique failures to common problems (high diffusion potential)
4. Common failures to common problems (what are we missing here?)
Just doing this on SMS would provide a start to a systematic approach
for gathering what we know, and who knows it, with regared to ICT.
Sam Lanfranco
*******************************************************
School of Analytic Studies and Information Technology
http://www.atkinson.yorku.ca/frschasit.htm
------------
***GKD is solely supported by EDC, a Non-Profit Organization***
To post a message, send it to: <[EMAIL PROTECTED]>
To subscribe or unsubscribe, send a message to:
<[EMAIL PROTECTED]>. In the 1st line of the message type:
subscribe gkd OR type: unsubscribe gkd
Archives of previous GKD messages can be found at:
<http://www.edc.org/GLG/gkd/>
