Archive for the ‘ICT4D Design’ Category

Bricolage and the Sustainability of ICT4D Solutions

In  ICT4D, bricolage refers to context-sensitive ways of implementing and sustaining ICT4D solutions [1].  Different from approaches where strategic goals, ways to achieve them, as well as success and failure metrics are defined in advance, bricolage is mostly characterised by improvisation and continuous learning from failures in environments with many uncertainties [2].  People who play key roles in shaping and driving the bricolage process are hereafter referred to as bricoleurs.

Drawing from a particularly successful long-term ICT4D project in Tanzania, for which the author of this post has been part of a team for about 10 years, this article discusses a three-stage process that local bricoleurs have gone through in sustaining the project in the face of scarce resources and diverse interests of stakeholders.  Extended empirical and theoretical insights about the role of bricolage in shaping and sustaining the project were reported in the work of Fruijtier and Senyoni [3], and this post will essentially provide some sound bites from the paper.

Bricolage in ICT4D Projects: Stages

1.    Opportunity Based: During this stage, a project opportunity is identified, its activities are mainly driven by external players, and the local bricoleur gets involved in project activities based on availability and need, as determined by main players. In the case of the Health Information Systems Program (HISP) team at the University of Dar es Salaam in Tanzania (hereafter referred to HISP UDSM), this stage was characterised by the advent of a pilot project for implementing the District Health Information Software (DHIS) in Kibaha and Bagamoyo districts in the Pwani region.  This was around 2002-2010 and the main focus of the project during this period was to demonstrate the capabilities of the then-new DHIS system in handling routine aggregate health data, and to make a case for the endorsement and national rollout of the system by the Ministry of Health (MoH) in Tanzania. The University of Oslo (UiO) (main developers of the DHIS system) mainly influenced the direction of project activities during this period, and the HISP UDSM team supported the pilot districts in activities such as training, user support and data analysis, as was determined by the main team at UiO. 

PhD and MSc scholarships were also established as a result of collaboration between the UiO and HISP UDSM in order to, among other things, strengthen local capacity for supporting project activities in Tanzania. It was the ability to serendipitously survive funding uncertainties and diverse interests of stakeholders, and the partnership with MoH in persuading a variety of stakeholders to pursue the common cause (strengthening HMIS (Health Management Information System) data reporting) that prepared the UDSM team for the would be next phases of the project where it (HISP UDSM) turned out to play a key role that fostered project success.

2.    Locally Owned: During this stage, bricoleurs cultivate the growth of what is already achieved while advancing their knowledge and understanding of practices in the project domain. In the case of the HISP UDSM team, this was the period from 2010-2015 which was characterised by close involvement with MoH in providing technical support during revision of HMIS data collection tools and definition of indicators prior to the national rollout of DHIS, and playing the central training role during the national rollout which was done in December 2013. After the national rollout, HISP UDSM got closely involved in supporting hundreds of users across the country, as well as bringing data for other programs and partners on board. Apart from this close involvement, care was taken to involve MoH and its various departments on every step of the way, to foster ownership and long term sustainability of the project.

3.    Locally Driven: At this stage, bricoleurs assume main control of events in the project. They can proactively anticipate challenges, and provide them with apt solutions. In the case of the HISP UDSM team, this is a period from 2015 onwards. It is characterised by, among other things, new projects and requirements from various stakeholders. Following the successful DHIS national rollout in 2013, the HISP UDSM team was also requested by other ministries in Tanzania to implement similar solutions for them. In response to this, so far, HISP UDSM has customised DHIS to serve the data reporting and analysis requirements of the Ministry of Agriculture and the Ministry of Water in Tanzania. Arrangements are underway to do the same for other ministries and government departments. As well, as they continue using DHIS, various MoH partners keep on requesting new and rather generic functionalities which are not yet implemented by the main DHIS developer base, which is globally led by UiO.  To respond to this, in 2015, the HISP UDSM team devised an innovation strategy which has seen the implementation of generic solutions, in terms of new DHIS functionalities and mobile apps, that have turned out to be useful to other DHIS users across the globe [3]. 


Two key take-aways for other ICT4D projects:

  1. The sustainability likelihood of an ICT4D project increases with an increase in the ability of the bricoleur to create the environment that fosters the prosperity of bricolage. Importantly, to be innovative in unpredictable project envoronments, bricoleurs need to build both social and technological alliances.
  2. Because of the special emphasis on learning, universities can be conducive environments for bricolage to thrive.


1.    Ali, Maryam, and Savita Bailur. “The challenge of “sustainability” in ICT4D—Is bricolage the answer.” Proceedings of the 9th international conference on social implications of computers in developing countries. 2007.

2.    Ciborra, Claudio U. “From thinking to tinkering: The grassroots of strategic information systems.” Bricolage, Care and Information. Palgrave Macmillan, London, 2009. 206-220.

3.    Fruijtier, Elisabeth, and Wilfred Senyoni. “The Role of Local Bricoleurs in Sustaining Changing ICT4D Solutions.” International Development Informatics Association Conference. Springer, Cham, 2018.

Participatory Design Problems in ICT4D: The Low Self-Efficacy Issue

23 January 2009 4 comments

First inscribed into Magna Carta in 1215, it is a legal requirement for all ICT4D project evaluations to conclude that more user participation would be a good thing.  But would it?


I’ve written earlier in general on the problems of participation in “The Tyranny of Participation in Information Systems: Learning from Development Projects“.


Here, though, I want to reflect on the more specific idea that norms of user feedback do not always apply well in ICT4D contexts.


This was prompted when I reviewed research (which will be presented at the ICTD2009 Qatar conference) on an ICT4D project to help women from poor communities get better access to health information.  As per participative norms, a prototype system was built and women were brought in to use the system and provide feedback on design improvements.  However, it was difficult to get any useful feedback from the women.


Further investigation found a key underlying issue.  When the ICT4D system did not work well, the women tended to blame themselves rather than either the system or the designers.  Therefore they had little or no design improvement feedback to offer.


That sounds like a classic problem of low self-efficacy (“the belief that one is capable of performing in a certain manner to attain certain goals”) and/or low self-esteem (“a person’s sense of self-worth”).


Put simply and in stark form, some users in ICT4D projects see themselves as either useless with ICT systems and/or generally worthless, and so offer little input in conventional participative design/prototyping situations.  This may be particularly true of the more marginalised groups that ICT4D often targets.  (And, yes, also true of some groups/individuals in the global North, so this is not necessarily a North-South difference issue.)


Some spin-off points:


– Problems with ICT4D participatory design are sometimes put down to cultural differences (e.g. Winschiers’ work; see also Straub on global market usability testing).  Prescriptions of reducing the perceived status-differentials between users and designers may work.  But they may work for efficacy and esteem reasons, as much as the claimed cultural reasons.  (See also Kam et al’s work in India showing the importance of relationship building between users and designers.)


– The “Bollywood method” of engaging users through film plot-style exercises may, again, be less about the presented issue of user motivation and more about overcoming efficacy barriers (users feel capable of talking about films, not about ICT systems).


– Drawing on Bandura’s theorisation of self-efficacy, we would want more attention being paid with ICT4D user-participants to issues of a) past ICT experience; b) modelling and other peer/social influences; c) physiological factors.


Generally, this suggests ICT4D needs to dip more of a toe in the waters of psychology than it has so far done.  Negative psychological constructs like low self-efficacy and low self-esteem may be hampering ICT4D participation, and will continue to do so unless we understand them more.


I’d be grateful for comments pointing to other evidence (or counter-evidence) on this issue.


(Thanks to Andy Dearden for helping develop these ideas and pointing to sources.)


Categories: ICT4D Design Tags:
%d bloggers like this: