ICTworks by Inveneo

While we often focus on highlighting successes in our field, it’s no secret that many projects just don’t work – some don’t scale, some aren’t sustainable, some can’t get around bureaucratic hoops, and many fail due to completely unanticipated barriers.

At FAILfaire we want to recognize the failures: the pilots that never got anywhere, the applications that are not delivering, the projects that are not having any measurable impact on the lives of people, and the cultural or technical problems that arise.

FailFare Info
New York City
April 14th, 2010
5:00-7:30 pm
RSVP

This event may have been inspired by our Failday Twitter Chat, which wasn't a failure

While many practitioners and pundits in the ICT4D community agree that the field has had more than its share of failure - with some even claiming an unbroken string of failures - little work has gone into understanding why these failures happened, and even less work sharing failure with others.

ICTworks attempted to change the nature of the community's discussion of failures last Friday with "Fail Day", the second edition of the now-monthly #ICT4D Twitter Chat.

By all measures, the event was a success, with nearly thirty participants -- including researchers, practitioners, and interested people from industry and government -- not to mention an even larger audience of observers. The event's guiding questions were simple: What are the major types of failure in the ICT4D field, why are we faced with these patterns, and what can be done to change the course?

Unsurprisingly, at the end of 90 minutes, there were arguably more new questions than answers. (A full transcript of the event is available.) However, a few important themes arose:

1. Improper or missing understanding of users.

Technologists, like all people, have a tendency to dream big. As a result, systems are often over-engineered in the minds of the designer, without taking the time to base the design on real data points from potential users (or even from other projects). Designed in a vacuum, these projects are nearly guaranteed to fail -- users in the developing world often end up finding very little in common with an application developer in the United States (for example).

The human-computer interaction field is partly to blame for this pattern, as we haven't done a good job providing low-cost, meaningful ways to better understand users in the global south. We certainly haven't promoted use of simple techniques such as use of personas, interviews, and surveys in the early phases of ICT4D projects. Some of us, including me, are working to change this, but it will not be an overnight process.

2. Failure to focus on real problems and needs.

A failure to understand real needs is somewhat related to misunderstanding of users. After all, the better technologists are at understanding users, the better they can understand their needs. At OpenMRS, we have a mantra that "care will lead the way". This means that every bit of functionality can be traced to actual, real-life needs of the clinics and health care professionals we serve.

Unfortunately, this type of understanding can only be achieved by spending time first-hand in the environment where an ICT4D solution will be used, or, if that's not possible, by involving people from that environment directly in the design process. Eliminating time spent on "imagined" problems not only makes the technology development process faster, it also increases the likelihood the product will be well-received.

3. Expectation gap between implementers and donors.

Building on the previous two points, the chat's participants made it clear that implementers don't always do a good job of educating donors and other stakeholders about the realities "on the ground". (Perhaps this is because these "doers" don't fully understand them, themselves!) This misunderstanding inevitably leads to faulty expectations not only of the project, but also the processes of designing and implementing. Technologists must become better at "speaking donor", and also must help the donors learn a little about how to "speak tech".

This communication gap has plagued the informatics world in the global north since its beginnings, so it's not surprising to see it at play in the global south in international development projects. However, I believe the remedy may be the same in both situations - increased cross-training of people with solid technical backgrounds in concepts like interpersonal communication, project management, monitoring and evaluation.

Summary

While failures -- particularly in ICT4D -- will never be eliminated, focusing on these factors earlier in projects can help reduce of the impact of these failures, and help us "fail early and often", iteratively improving project implementations instead of failing late in the game, wasting more donor funds and invaluable time.

What do you think? Do you agree with these ideas? Were some overlooked? Voice your opinion in the comments.

Other FailDay Chat Synopsis

• ICT4D: Past mistakes, future wisdom
• Agile Development and Retrospectives: Learning from failure?

Keep current - subscribe to ICTworks updates via RSS, Email, or Twitter

.