Tag Archives: Reasons for Project Failure

Lessons in ICT4D

Before taking this class, I didn’t think much about the role of technology in development. Of course I recognized the significance of the spread of the Internet and knew how certain technologies could enhance a development project’s overall goal, but I hadn’t considered that information and communication technologies could be the central focus of a project. ICTs are useful tools that can bring us closer to development goals if used creatively. Learning about the uses of ICTs in development was helpful based on the lessons that both the successes and failures of ICT4D projects can teach.

One of the lessons that kept recurring throughout the class was the idea that project plans should be driven by the people they aim to help. In the case of many projects donors take control and manipulate the goals to either fit their idea of what will be helpful or fit their idea of what will look good from the outside. We looked at case studies where organizations with good intentions failed because they did not communicate with their target population. Without understanding a community’s needs an outside organization cannot successfully provide development aid. We saw this in the case of One Laptop Per Child. The recipients and teachers were not consulted with to assess their needs or the possible constraints that could get in the way of the project’s success. As a result, the project has had little effect on education indicators in its target populations.

One Laptop Per Child also teaches us about the danger of focusing on a project’s image. Their video showing children in under-developed areas carrying laptops appealed to the audience’s emotions and tried to portray the idealism of the project. This is an example of Oscar Night Syndrome, or the tendency to choose projects or methods based on their outward appearance and “shininess”. We studied many projects that failed based on a disconnect with reality stemming from a desire to provide immediate impressive results rather than sustainable long term improvements. This is even more of a concern with ICT4D projects than development projects in general based on their tendency to rely on technology to produce results. Technological determinism is dangerous in ICT4D because it fails to take important factors into account.

I learned the most about ICT4D from real world case studies. Many of these lessons came from their failures, showing us what not to do. But during our video conference with Wayan Vota, he compared the percentage of business failures in Silicone Valley to the percentage of failures in development projects. While it is estimated that approximately 70% of development projects fail, the 30% success rate is substantially higher than the 10% success rate of business start-ups in Silicone Valley. Putting things in this perspective helps to affirm that all is not lost in the world of international development. While rates of failure are high, we can learn from our mistakes to improve the effectiveness and efficiency of future projects.

Reasons Why ICT4D Projects Fail

In the following video, professionals from Africa explain why they think many ICT4D projects fail. It shows their perspectives on ICT4D and highlights 7 of the main reasons for failure.

The 7 reasons stated in the video are:

1. Ideas/results not directly tied to improving economic condition of end user

2. Not relevant to local context/strengths/needs

3. Not understanding infrastructure capability

4. Underestimating maintenance costs and issues

5. Projects only supported by short term grants

6. Not looking at the whole system

7. Project built on condescending assumptions

These seven reasons for ICT4D failure encompass much of what we have discussed in class. Some of the specific things that the people in the video talk about go into greater detail in terms of this succinct list. For example, one community organizer discusses how many projects are designed outside of the community without enough initial research or understanding of how the society works. Not only do they not do enough before, sometimes they come in with an attitude of superiority and the notion that they will be teaching the people there how to use technology, instead of working with them to see how it can be of the greatest benefit to them. Just as Richard Heeks argues, many ICT4D projects have a one-size-fits-all approach and do not take into consideration that each context is unique and some things don’t work everywhere.

The video also discusses the need for developed infrastructure to support projects. One man speaks of power outages and how they are an accepted reality in many communities. People are used to the power going out without warning and do not expect notice in advance. Another ICT professional discusses how his community received 40 computers and now none of them work. They were given as gifts, but their maintenance could not be paid for so they are out of use now. This is an example of an underestimation of costs. The biggest overarching problem that seems to be recurring in the video -and in actual ICT4D projects- is that the project designers and implementers do not fully understand the culture and the problems that need to be addressed. This will continue to be the biggest issue until ICT4D projects work more closely with communities and are led by members from the bottom-up.

Fueling the Failure

This week in class we discussed and read about why ICT4D projects fail. An article titled “Failed ICT projects, learning from the mistakes of others” offers an insightful response to the question: Why are we making the same mistakes over and over again, if we know why projects fail?

I must ask; do we really know why ICT4D projects fail? Sure, there are commonly-sighted reasons for failure like ‘not understanding the infrastructure capacity of the region’, but they are so general. We have a serious lack of case-specific evidence for why projects failed. The article’s main argument (which I agree with) is that there is a lack of direct evidence pinpointing which part or parts of the development project ‘caused’ it to fail. Too often, development agencies do not take the time to investigate and analyze their failures thoroughly, because it is easier to just sweep them under the rug and put a tally in the ‘loss’ column. And if/when the proper project evaluation is conducted, the article notes that the results are in-frequently publicized.

In response to their criticism of the handeling of ICT4D project failures, the article provides an example of what should be done when projects fail. The article presents a study conducted George Brouwer (the Ombudsman for Victoria, Australia) about 10 specific state-run ICT projects that have failed over the past decade. His detailed analysis of these 10 projects yielded interesting information about why ICT4D projects fail. In my opinion, the most relevant conclusions that Brouwer drew from his study were:

1)   Development agencies did not spend enough time on planning and project development

2)   Development agencies did not “give proper consideration and gain adequate understanding of the current state of the systems and business processes, which would be affected by the project”

3)  Roles and responsibilities within the agencies were not clearly defined, which made it difficult to hold people accountable for mistakes and/or failures

4)   Development agencies tried to take on “overly ambitious and complex projects”

In conclusion, the article argues that Brouwer’s report is invaluable because it provides detailed, case specific reasons for project failure (which I did not go in to fully above).  It is so useful for research like this to be published, because if it is not, development agencies continue to repeat the same mistakes.

I think that the importance of developing thorough impact and process indicators, and spending ample time and resources on project evaluation is completely underrated. This article validates the importance of analyzing projects after they are implemented, especially ones that fail. If we do not take the extra time and resources to investigate ICT4D project failures we are only making it more difficult on ourselves, and making it harder for us to succeed in the future. We can break the vicious cycle of failure by simply stopping and taking a close look at what went wrong, and sharing this research with others.

Lessons Learned: Don’t Believe the Hype

ICT4D looks to the future to try to address problems as ancient as rebuilding after a disaster and needs as base as a child’s need for food during a famine. The staying power of these problems makes the world seem incredibly bleak and can foster a strong sense of alienation that only grows as the divide between the haves and the have-nots expands. The successes and failures of our field offer a multitude of lessons about what we are capable of and what we still fall victim to when setting out to change whatever small part of the world we can.

  • 1.) Very smart people can do very stupid things, so proceed with caution and humility, even if you’re sure whatever you are dealing with is wonderful. I think for many of us, the bleakness of the development world fosters an intense desire to find the silver bullet and turn the whole world on its head. It’s easy to get excited about a new project, or innovator, or idea of your own and get tunnel vision. Good projects have failed because the leaders thought they had such a universal or perfect idea that they didn’t need pilots, and only saw the flaws in their work once it had been deployed en masse (or, alternatively, fail to get funding because they didn’t pilot). Bad projects have gotten huge through sheer force of personality and media manipulation, only to crash and burn, succeeding not only in not helping anyone at all, but often causing harm. Research, feedback and repeat monitoring and evaluation may take up time and money, but they are not short-cuts that should be taken, especially if the justification is “Of course my _________ will work, it’s perfect. I know best.”
  • 2.)Leading off of the first point, projects and initiatives need to get target community participation whenever and wherever they can.  Every project seems to benefit from increased target community participation, input, and eventual management, and many suffer for lack of it. If a project can get stakeholder participation, I feel it should embrace it, and if it can’t, the leaders need to take a step back and make sure that lack of participation isn’t the community signaling that the intervention is unnecessary or unwanted.

As far as tools, I feel my first foray into mapping, facilitated by this class and the Red Cross, will help immensely in my future career, which mostly concerns determining the most efficient and equitable means of distributing public goods in states with limited funds, and how to prioritize development. Being able to access and interpret more empirical data through mapping is vital, especially in areas with a lack of official and up-to-date mapping. More philosophically, the nuances of development that we’ve been shown in the class have, I believe, made me a more thoughtful person. Before Rob Munro, I never would have considered the issues surrounding public mapping, even though looking back it seems so intuitive that there are very real concerns with publishing such sensitive information. There are so many causes and effects and realities of life on the ground that I think we miss out on when just looking at raw data and looking for quick interventions, and the cautionary tales presented in our class has really helped me proceed more cautiously and less dogmatically than I would have before.

I think in general, the best frameworks for tackling a problem involve enabling existing community initiatives and focusing on bottom-up projects. While there are of course many things (especially in physical infrastructure) that must be financed and implemented on a governmental or higher level, I feel all projects would benefit from community involvement and that community voice should be the main driver of project creation and implementation. The mantra of “if we drop it in, they will come” has largely failed, and the most successfully utilized initiatives have been those that already had clear demand. Grassroots projects have the benefit of already containing a number of dedicated individuals who have proven an intense desire for the intervention, and a commitment of time or money to see it through. By focusing on what target communities are telling us they need, rather than us telling them what they need and what we’re going to give them, I think we can decrease the paternalistic flavor of many ICT4D programs and increase both the sustainability and benefit of interventions.

Failures in ICT4D

This article relates to our class on Tuesday in detailing the high rate of failure of ICT4D projects. The high rate of failure has been well documented. The article points to a Harvard study from 2011 that details one in six projects overran their cost by an average of 200% and a schedule overrun of 70% on average. This article is different from most that simply detail the many failures of ICT projects without pinpointing definitive reasons for failure. It points to investigation by George Brouwer of ten ICT projects in Australia that went past their timetable or went over-budget or both. The report points to some concrete reasons for project failure. Some of his reasons overlap with those we talked about in class but he also points to several other possible downfalls. These include poor planning and development of goals, poor understanding of businesses and other actors that would be affected by the project, failure to define roles and responsibilities, and a lack of involvement from leaders and senior officials in the project.

Each of these factors would be detrimental to the success of a project, causing a lack of oversight and accountability among those responsible for the project and racks up costs and delays. I thought this article would be an interesting read for those who were interested in finding out more about the different factors that contribute to project failure and provides a framework for looking at both failed and potential development projects moving forward.

Why do most ICT4D initiatives fail?

One of the summarized points of Chapter 2 in the Unwin textbook is “ICT’s have the potential either to increase inequalities or to reduce them depending on the social, political, and economic contexts within which they are introduced.”  In some cases,  ICT4D projects clearly have helped nations make huge strides in development.  According to UNESCO, however, the majority of ICT4D projects fail.  I’ve posted a link to a video produced by Dr. Clint Rogers which explains the top seven reasons why ICT4D may not be successful, summarized below.  The video shows interviews with people working on various developmental projects and poses significant questions about the sustainability of ICT projects.

Top 7 Reasons Why ICT4D Projects Fail:

1. Ideas/ Results are not directly tied to improving end user economic conditions.
2. Not relevant to the local/ context/ strength/ needs.
3. Not understanding infrastructure capability.
4. Underestimate maintenance costs and related issues.
5. Projects supported by only by short-term grants.
6. NOT looking at the whole system.
7. Project built on condescending assumptions.

What do you think about the significance of these issues? Are they relevant?  Are there any other problems you have read about or experience that you think should be included in this list?