Can a Process Approach Improve ICT4D Project Success?

Many ICT4D projects fail[1].  There are various mooted reasons for this, of which I will highlight five here:

  • Failure to involve beneficiaries and users: those who can ensure that project designs are well-matched to local realities.
  • Rigidity in project delivery: following a pre-planned approach such as that mandated by methods like Structured Systems Analysis and Design Methodology, or narrow use of LogFrames.
  • Failure to learn: not incorporating lessons from experience that arises either before or during the ICT4D project.
  • Ignoring local institutional capacities: not making use of good local institutions where they already exist or not strengthening those which could form a viable support base.
  • Ineffective project leadership: that is unable to direct and control the ICT4D project.

This does not represent an exhaustive list of causes but one can find one or more of them in many failed ICT4D projects.  And they are deliberately selected because – if we turn them around to their mirror-image project enablers – they become the five key components of the “process approach” to development projects: beneficiary participation; flexible and phased implementation; learning from experience; local institutional support; and sound project leadership.

The process approach arose during the 1980s and 1990s as a reaction to the top-down, “blueprint” approach[2].  The blueprint approach was particularly associated with use of foreign technologies in rural development projects.  Perhaps, then, it is no surprise that it has filtered through into ICT4D practice.

Equally, though, one can see elements of the process approach in action in successful ICT4D projects:

  • Beneficiary participation: the M-PESA mobile finance project in Kenya incorporated the views of users into project design through user trials and volunteer focus groups.
  • Flexible and phased implementation: India’s agricultural information kiosk project, e-Choupal, used a pilot approach for all new services; introducing them one-by-one and planning designs and scale-up on the basis of those pilots.
  • Learning from experience: Grameen incorporated the lessons from its microfinance projects into the design and delivery of its Grameen Phone programme of rural mobile telephony.
  • Local institutional support: Brazil’s community computing project, the Committee to Democratise Informatics, is founded on the development of local institutional capacity through each of the schools it creates.
  • Sound project leadership: returning to M-PESA again, Vodafone put skilled project managers in place in Kenya in order to make the project work.

Each one of these projects – and one can no doubt find many others within the ICT4D field – demonstrates more than one of these five elements.  This is not unexpected since the process approach can be understood not as five rather arbitrarily-categorised, separate components but as an integrated whole.  It can be conceived like a wheel (see figure below[3]): flexible, phased implementation being the tyre that absorbs the bumps as the project goes along, feeding contextual information to learning from experience: the central axle from which the spokes of participation, local institutions and leadership radiate, giving strength to the whole.

 Figure 1: The ICT4D Process Approach Wheel

The process approach also reconceives the notion of success in ICT4D projects.  Instead of seeing either success or failure as cross-sectional, final judgements on a project, instead – like a point on the rolling wheel – any judgement must be seen as contingent and passing.  Instead of success and failure, we would therefore talk of multiple “successes” and “failures” as the project proceeds.  Any overall judgement would rest on relevance of the ICT4D solution, opportunities for capacity building, and sustainability.  A process approach contributes to each of these.

And for ICT4D practitioners, a process approach can help pose questions:

  • What is the role of beneficiaries throughout the project’s stages?
  • What is the mechanism for changing direction on the project when something unforeseen occurs?
  • What is the basis for learning on the project?
  • What local institutions can be used for project support?
  • What is the nature of project leadership?

And so forth – these and other questions can lead to concrete plans, schedules and roles which incorporate the lessons of the process approach into future ICT4D activities.

This blog entry is a summary of the online working paper “Can a Process Approach Improve ICT4D Project Success?“, published in the University of Manchester’s Development Informatics series.

If you have experiences of ICT4D project failure or success to share, please do so via comments.

[1] Good data on success/failure of ICT4D projects is embarrassingly limited, and more historical than recent.  See: “Information Systems and Developing Countries: Failure, Success and Local Improvisation

[2] A foundational paper is David Korten’s article “Community Organization and Rural Development: A Learning Process Approach

[3] Source: Bond, R. & Hulme, D. (1999). Process Approaches to Development: Theory and Sri Lankan Practice. World Development, 27(8), 1339-1358

5 thoughts on “Can a Process Approach Improve ICT4D Project Success?

  1. It is quite interesting to hear about this process approach and I completely agree with it. This I say because we have an ICT component in our project which has done reasonably well so far. One of the reason we feel we were successful lies on our approach and on how we went about measuring it. Becuase we had a process flow measurement approach (we capture it in form of a tool called “Results chain”), we were able to learn and make changes to interventions when it was required, keeping market systems incentives and beneficiaries in mind. A key component was to understand what would be market incentives of market actors to continue on with our ICT initiatives.

  2. Reading this post the case of M-Pesa came to mind as an example of the relevance of adopting a process approach all the way. M-Pesa was initially designed in a sort of participatory design manner, then it also developed in quite unexpected ways: it was conceived to facilitate urban-rural remittances, so fees were set on the delivery of money. This meant that the unplanned use of the M-Pesa accounts for storing money came for free and spontaneously grew. People in unsafe areas found M-Pesa safer that their mattresses (and women could gain some independence in money handling from some husbands). When so many people had M-Pesa, it was obvious to start using it for micro-payments. As I like to repeat, it’s at least 15years we hear about e-platforms for micro-payments and this future didn’t happen in California first, but in Kenya. In Europe, we have to pay oranges with coins, still. More recently, M-Pesa growth is challenging the banking industry, which complains to regulators that M-Pesa and similar services do not have to comply with all banking restrictions.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.