Ten concepts everyone in ICT4D should know
I was recently asked which concepts are helpful in learning more about Information and Communication Technologies for Development (ICT4D).
I didn’t have an immediate answer for her.
ICT4D can be a daunting field to start out in. It’s a domain occupied by academics as well as practitioners; field workers and policy wonks, technologists and activists. Being such a diverse and multi-disciplinary field is clearly one of the strengths of ICT for social good, but is also one of its challenges in on-boarding.
For those working in the ICT4D space, it is not easy to get oriented to a basic set of principles or concepts in use by those in the field — even after years of experience (it’s accepted that we don’t really have a defined set in the first place, so that’s ok.)
For me, I find that I keep coming back to some of the same concepts fairly often as I discuss particular projects, challenges, and trends.
These particular concepts have helped me not only to frame problems in a particular lens, but to also guide the process for how to move forward. Or just fun conversation.
Maybe they’ll help you too.
This grounds a lot of my thinking in international development in general.
The easy problems have been solved. The ones that remain are not so easily solved.
Wicked problems are often messy, inter-related and inter-dependent, have no obvious solution, and when fixing one area, you might disrupt the entire balanced system and create new challenges.
“Don’t take down a fence until you understand why it was put up in the first place”
— Robert Frost
Thinking of the challenges you’re addressing as ‘wicked’ helps to remove some of the burden of solving an issue overnight, but it also forces you to zoom out and look at the entire ecosystem and develop your systems thinking.
This is probably the concept that I see most in ICT4D presentations, and is probably about as foundational a concept as we have.
The idea behind the hype cycle is that essentially any new technology or innovation goes through a sort-of predictable path of growing interest, then wild enthusiasm, followed by disillusionment, to finally a period of renewed but constrained use and enthusiasm.
This concept is great for understanding how to interpret unabashed enthusiasm for a new tech trend without being a wet blanket (blockchain, 3D printing, drones), but also on how/when to start appreciating the sustained use and maturity too (SMS, paper).
Although the phrase design-thinking seems to be cresting on its own Hype cycle of buzz-wordiness, it’s an incredibly useful concept and lens through which to tackle a problem. Design thinking is at its most basic is simply adopting the approach and sensibility that a designer might when tackling a problem—which focus more on people’s needs than on technological capability.
Design thinking (a.k.a. creative capacity-building) is useful because it jams a ton of other useful concepts into a given process: user experience, ideation, prototyping, iteration, contextual inquiry, and usability, just to name a few.
Borrowed from the world of economics, I have found opportunity cost to be incredibly helpful as an explanatory concept in a variety of settings: from the attendance numbers of a nutrition training by new mothers to the slower growth of smartphone adoption around the world.
Opportunity cost is essentially the value of opportunities not taken when at a fork in the road. The New Oxford defines it as the “loss of potential gain from other alternatives when one alternative is chosen”—which is a little wonkier but more accurate.
I find opportunity cost helpful when thinking through the cost-benefit of decision-making and why we make decisions in the way that we do.
For example, though our nutrition training may have been free and even provided a phone credit stipend, it was not greater than the opportunity cost of finding someone to watch your other children or take time off of work.
This is the bias that we place greater value on things that we create. The Effect is well understood by any student who purchases Ikea furniture and is responsible for its assembly at home.
This particular concept creeps into projects all the time — whether for a piece of software that was ‘custom-built’ for a no-longer-relevant task, or for a manual made in-house that is woefully outdated yet referenced by the author all the same.
Couple this with Maslow’s Hammer axiom—when all you have is a hammer, everything starts to look like a nail—for extra relevancy.
I find that even walking through this concept helps teams to step back from their previous efforts to look a little more objectively at assembled work.
An externality is a cost or a benefit that affects someone who did not choose to incur that cost or benefit. We often think about it as when negative consequences are separated out from an initial action (there are also positive externalities).
Global climate change is the standard example of an externality — the costs of changing temperatures affect everyone, while not everyone in the world is responsible for climate change itself.
An example of a positive externality can be something like early childhood immunization programs. While they obviously benefit the child receiving the vaccination, they also have a positive externality in maintaining a healthier community, which means lower healthcare costs, more economic opportunities, and the potential for greater economic growth as a community.
An example of positive externalities in ICT4D could be mobile phones. While the initial benefits of the phone are clear, they provide a range of benefits beyond the scope of phone calls and text messaging for communities.
Pay attention to externalities — they are hidden everywhere, and they can often help to understand explicit and implicit costs/benefits.
7. Stakeholder Analysis
This one might seem obvious — but try asking “who are the stakeholders of this project” on a given team and you’re likely to get a variety of responses.
One challenge I find often in ICT4D projects are that project leads are good at articulating the end-users as key stakeholders, but they often discount the role that their organizations play, and how they themselves are stakeholders that influence a project, as are (more importantly) their bosses and donors in the end.
The ‘golden rule’ of project management — “He who has gold, makes rule.”
If you want to get a little bit more technical around stakeholder analysis, you should check out the concept of the principal-agent problem.
Also known as the 80/20 rule, essentially says that for any given environment, 80% of the outcomes are determined by 20% of the inputs. In other words, some small sub-set can have a huge impact. Applied to business, for example, it’s seen that 80% of sales come from 20% of clients. In health care, 20% of patients use 80% of services. And so on.
The Pareto Principle is important in ICT4D when you think about scaling a project, and the types of users you’ll want to engage. Often enough, the advice from the Pareto Rule is that you don’t have to please everyone — just a small but significant portion that will end up using your services.
This can have real consequences for how you build data-driven products as well. By keying into the functionality that delivers to your 80% market, you can make more efficient decisions rather than trying to build for everyone.
Finally, this can also help tell you when to stop researching your user data and move to building. See optimal stopping for more related fun in this area.
Literally ‘egg-laying-wool-milk-sow’. This is one of my favorite German words — and I’d love for someone to teach me how to pronounce it. The tragedy of the egg-laying-wool-milk-sow is that it’s a single animal that contains all the positive attributes of a variety of animals and can perform many functions.
Except, of course, it’s a fantasy.
How many projects in ICT4D are designed to contain every imaginable feature, all the functionality of multiple, specialized tools in one place? This is a great term to toss in to help lean a team away from scope creep and trying to build a magical do-all ICT4D magic bullet solution.
10. The missing concept
This one is left open to recognize that none of us at any time will know and be aware of all the useful concepts, biases, ideas, and principles in this space. That’s what these communities are for. So it’s up to you to help out — please let us know which concepts you find most helpful in your work!
Gabriel Krieshok is an ICT consultant in Washington DC, the ICT4D Program Specialist at Peace Corps, and founder of ICT4DGuide.io. His views do not necessarily represent those of his employers.