The solution design process is critical to the success of an ICT4D project, yet surprisingly little is known about collaboration between stakeholders and developers during this important stage.
In fact, there are often great misunderstandings between technology developers, project implementers, and intervention constituents, ultimately leading to ICT4D project failures. For example:
- Technologists and social scientists often have different, even conflicting perspectives on innovation and development (e.g. economic benefit vs human empowerment).
- Stakeholders funding the development of digital solutions are not the ones creating it, while those developing the solutions are not the ones using it.
- Stakeholders lacking in technical expertise have reported difficulties in collaborating with technology developers.
At the same time, digital development is only possible in the context of transdisciplinary collaboration, where stakeholders with diverse backgrounds need to align their goals to increase the chance that projects become fruitful.
Share Your ICT4D Design Conflicts
While conflict in collaboration is a known and prevalent issue, there is a need for a deeper grasp of where and why misunderstandings arise, particularly in the design stage of ICT4D projects.
Hence, my study, which is investigating how practitioners from varying fields and roles, such as technology designers, software developers, academic researchers, project implementers, donors, and intervention stakeholders view the design process.
For my master’s thesis project I am looking for your input in my Delphi study to find out where there is agreement and disagreement concerning 10 key design principles in ICT4D projects.
Bonus! This Delphi study will give you insight into the opinions of other ICT4D experts.
The data will be used to assess the problematic key principles that are applied in the design phase of ICT4D projects. I’ll develop recommendations and a more specific research agenda on transdisciplinary collaboration in ICT4D.
Your input is extremely valuable for this study.
By Stephen Smith, MSc Development and Rural Innovation student at Wageningen University
Interesting, I will pick out the last line “Stakeholders lacking in technical expertise have reported difficulties in collaborating with technology developers”.
The agile methodology takes care of this. However I see where you are coming from, though I have no clue where you are headed.
This problem can only happen when you have an inexperienced technology team. So this is a procurement problem. procurement of IT projects is complex, many contracts are awarded to companies that write eye catching proposals (“pitch decks”) even though they are low on substance.
Playing devil’s advocate you have to factor in some of the clients (who you refer to as stakeholder’s) want so many features. They forget about the keep it simple stupid principle. Rome wasn’t built in a day, they want a software product that can sing karaoke, dance and recite a prayer every other Friday.
Agile, Human centered design, lean methodologies and prototyping have been around for a number of years and I don’t understand the problem you are trying to solve, as they were designed to address some of the challenges you mention.
Factor in the red tape, and bureaucratic process involved in large contracts where they ask for Mother’s name, Date of birth of your last 5 relatives, and you find that many innovative companies will not get attracted to participate in such tenders, leaving them to the behemoths who are still stuck in the 1970s.
I agree with your last paragraph regarding the bureaucratic process, which needs a strong diplomacy background.
The problem of the conflict is simply a reflection of ignoring the rule of multi-disciplinary team. The core team should at least have 2 backgrounds, one for the Computer-Human interaction specialty (IT), and the other is the Human-Computer interaction specialty (Extension or development agents/researchers). This integrates the product’s what is needed and what can be offered.
This is how we build VERCON network 18 years ago, and it is still functioning.
In general 1) co-creation is key, 2) procurement teams need to have an understanding of what may be red flags in the contexts they are procuring technologists for, and 3) technologists need to be experienced working in the contexts that they are developing for. When these three criteria are not met, there will be design conflicts.
What a great idea to put your survey out on ICT Works – please do share the results of your study/thesis as well!
Procurement of ICT projects is treated the same way as roads, and what you end up with a vicious cycle of botched projects, and then we have ‘experts’ reminding us how the failure rate of ICT projects hovers around 80%. You don’t buy software the same way you buy sweet potatoes at the local farmer’s market. Procurement officers are not to blame, they do what they taught in school, and procurement of IT projects is one of them dishes not on the menu.