You are viewing a read-only archive of the Blogs.Harvard network. Learn more.

The project carcasses that litter the ICT-Dev landscape

Several years ago my colleague Carlos Osorio remarked upon a feature of the international development technology landscape that is even more apparent today than it was then, but still does not seem to be acknowledged by the development community at-large.

Carlos pointed out that just as most Web businesses had turned out to be failures, in all likelihood, most “e-projects” in the public sphere (e-government or e-development projects) would also turn out to be misconceived as well.

Carlos was right. Most ICT projects have not been successes — any ICT for Development practitioner knows that, and that is the real buzz in the hallways and dinners that surround conferences and workshops. Whether an e-development project is putting computers in secondary schools, establishing telecenters, or creating transparency in government operations, it is an open secret that failure is the general result. But why does the funding for bad projects still flow? Not to mention bad project design? And why doesn’t the development community seem to learn from its mistakes?

Here are a few reasons:

1) Most e-development projects don’t have clear objectives. The “if we build it, they will come” mentality still dominates technology projects. The “wow” factor still hasn’t gone away, and the technology remains the ends rather than the means of many projects. Nowhere is this more apparent than in ICT/education projects, where the overwhelming focus is almost always on buying computers, and not on teacher training, curriculum design or actually improving learning.

2) Without clear objectives, it isn’t clear how to measure results. There are very few ex ante attempts to figure out what the point of ICT projects should be, let alone to quantify the results. In the end, this means a lot of anecdote and not much analysis. Or even material to analyze.

3) Bad feedback loops. Development organizations are not effective nor timely in learning from mistakes and incorporating those lessons into new project design or implementation. As my colleague Ethan Zuckerman has pointed out on numerous occasions, there is a real need in the development profession to be able to identify failure and walk away from bad projects (a trait more often found in the programming community). But because of the way that project pipelines and lending portfolios operate, projects that are receiving funding now most likely were designed 2 or so years ago — in the meantime, needs have most likely changed, we’ve seen the flaws in the project design, and the project is doomed to failure.

4) Technology isn’t the problematic part of most ICT for Development projects — bad management, training, analysis, politics and bureaucracy are the real culprits. But since we still don’t deal too well with these age-old challenges, even more emphasis is placed on the technology and vague hopes that it be a tool for positive change all by itself.

And here is why all this matters:

1) International development projects by-and-large use limited, public funds to keep them going. The nature of the funding means that development money that goes toward technology is not going toward health, education, housing or other projects. The imperative of these public funds to be spent responsible is essential.

2) Technology for many parts of the world is a one-shot deal. If major investments are being made in computers in a developing country, even if the use of those computers turns out to be a disaster, it is not so likely that another round of funding will come through — both the scarce nature of the funds available and the issues surrounding technology lock-in (particularly a concern in e-government projects) limit more technology investment for a long time.

3) We are in danger of squandering a major opportunity to leverage the excitement over ICTs to create real positive change. The window is rapidly closing, but there is still time to use the major technology projects to pry open and make progress on even more difficult issues such as educational reform, transparency/corruption, foreign direct investment or the spread of democracy. Conversations about technology inevitably lead to discussions about the intractable problems of development. I always thought that as a result, technology should open the door for major change and reform elsewhere. But unfortunately, I don’t see that happening.

4) Technology is expensive. But sometimes technologies that are simpler than computers may be more effective at solving the problem (if the real problem is identified). The problem with holding a hammer is that everything looks like a nail. The problem with holding a computer is that every problem can be solved with word processing software and the Internet. But that just isn’t true. Sometimes a radio, a cellphone, or a pad of paper might do a much better job.

Six years ago, there was a lot of excitement about how ICTs were going to change the field of international development. A lot of that was hype, but it also was a breath of fresh air in a tired, bureaucratic profession.

I want to find a way to bring that enthusiasm back. And to focus more on results than on the hype.

If we could be more open and honest about the failures of ICT for Development, and try to understand them, it isn’t too late to try to change the course.

2 Comments

  1. Richard Curtain

    May 18, 2003 @ 2:34 am

    1

    Excellent points made in project carcasses that litter the ICT-Dev landscape.

    Here are some elements of a checklist I am developing for mainstreaming ICT into development.

    Define Project objective: In terms of poverty reduction, what aspect of poverty does the project address? In more specific terms, how does this project relate to the millennium development goals (MDGs)? What specific indicator related to a particular MDG does it address?
    Who are the poor to be targeted by this program? To what extent is it possible to identify the poor in terms of rural/urban location, region, gender, age, education attainment & health status?
    What are the likely causes, as distinct from the effects, of the aspect of poverty the program is focusing on? Is it possible to rate the likely causes in order of importance? Is poor communication a cause of this aspect of poverty?
    What types of interventions are most likely to be effective in breaking the causal linkages? Need to distinguish between direct, indirect and supporting interventions.
    What are the information and communication needs of the targeted poor in relation to the project’s objectives and how important are they to the success of the project?
    What role can ICT and other media play in delivering the information and providing channels of two-way communication?
    Is there an appropriate form of ICT which can be deployed in terms of cost, support, maintenance and compatibility with existing information flows?
    Does an enabling environment exist for the ICT to provide the proposed support?

    Richard Curtain
    Public policy consultant

  2. Frank Patrick

    September 4, 2003 @ 5:27 pm

    2

    A lot of what is discussed in the blog and in Richard’s comment sounds familiar, even in the commercial world. Very often, the definitions of completion for a project fall so short of real benefit, that the kinds of things that Richard mentions — in the commercial world, the marketing, mfg/supply chain pipeline filling, sales training, etc — is left to the functional silos to deal with. I try to move my clients to expand the notion of their project beyond the “mere” technology development that is the traditionally managed scope and to include the management of all the things necessary to “ring the cash register” in the for-profit world, or to accrue maximum benefit in the for-cause environment.

    (By the way, I’m making a few assumptions, but would appreciate a bit of clarity on the ICT acronym.)

Log in