4.6 Humanitarian Technology
3. Project time to completion: Quantify time to completion of the project
by converting expected project duration via Equation (4.2) so that short
project durations are good and high durations are bad. Call this fi2 for
each alternative. Define w2 .
In this case, the criteria of quality of match of team skills to the project, and
the technical feasibility, are not included as they are not a concern.
The preferences for this case are defined using the idea in Equation (4.6) via
Pi = γCDIi + (1 − γ) (w1 fi1 + w2 fi2 )
where γ ∈ [0, 1] can be used to emphasize meeting the CDIi objective or the cost
and time constraints. Next, uncertainty ranges for all the parameters should
be defined, and used in RobustMCDM.m to make a project choice. To do this for
the CDIi , it may be necessary to define the uncertainties in the assessments for
income, health, and education, and then translate these through the formula
that defines CDIi (e.g., uncertainty on the Equation (4.8) aij values translated
via Equation (4.9) and also Equation (4.10)).
There are many other ways to define the Pi , and you will need to specify
an approach that fits your community and range of projects you may want to
consider. Once a project choice is made, it is time to implement the project,
which generally requires some type of project management, which was discussed
in Section 4.3.3.
4.6
Humanitarian Technology
Assume that you use participatory development to identify client and community needs, and to understand the context the technology will be embedded in.
Assume that you have chosen a development project. Now, we need to begin to
address the development of technology solutions.
4.6.1
The Technology Spectrum: From Novelty to Maturity
The practice of humanitarian engineering “on the ground” has provided a number of general principles that should be attended to. In humanitarian engineering, generally, three situations can arise when trying to develop a technological
solution concept to meet some community need:
1. No technology available: It could be that no one has ever developed a
technological solution for a need, or that there is clearly no acceptable
technological solution for reasons of cost, performance, reliability, lack of
use of local materials, lack of infrastructural support, etc. Such situations
can create very challenging technology development problems, ones that
may require multiple years of advanced research and perhaps even discovery of new underlying science. Discovery of new technology solutions
535
4.6 Humanitarian Technology
536
requires both a detailed understanding “on the ground” of people and
context, and a highly competent engineer.
2. Related technology available: Often, needs have been encountered by
someone in the world before and solutions have been attempted, perhaps
for different local conditions, or variations on the need your community
has identified. The approaches to design used for such technologies should
be considered as it is likely your team will learn a lot about modifying the
technology to adequately solve the problem at hand (this is standard practice in some industries where “reverse engineering” is used to understand
what a competitor is up to, and is not necessarily considered unethical so
long as you credit your sources). Sometimes, when you start out trying
to modify a technology you discover that you are actually in the category above where there is no technology that will fully and properly meet
needs, and significant innovation is then demanded. Indeed, you should
not underestimate the difficulty of modifying an existing technology; there
is a spectrum between items 1. and 2.
3. “Off-the shelf” technology available: There are an increasing number and
diversity of technological solutions for needs arising from communities in
the developing world (see references starting on page 714 for information
on these). It is possible that conditions and needs in the community you
are working with closely match those in other communities and hence solutions developed for other communities may be useful to you. In this
case, there may be little if any engineering needed, just a creative matching of technologies to expressed community needs, that involves selecting
a technology (see Section 4.6.5) and deployment of a technology, which
of course can require some technological skills that engineers often have.
In relatively rare cases, it may be possible to use technologies created for
the developed world, however this is not common as needs and conditions
are very different (e.g., use in the tropics, cost, cultural differences, reliability, or user demands) if context and community needs are properly
understood. While it is normally dangerous to assume that a technology
from the developed world will directly apply, it is likely irresponsible (unprofessional) not to consider the possibility, at least in case it gives you
solution ideas so you can modify the technology for local conditions (i.e.,
the last case above).
Notice that creativity is required for all of the above cases, but the amount of
creativity generally required decreases as you go from 1. to 2. to 3. A professional engineer will know where they stand with respect to where technology
solutions are in their long-term advancement: very new technologies are often
unreliable whereas old well-tested and widely-used technologies are “mature”
and may provide elegant and reliable solutions, perhaps with some well-designed
modifications.
To emphasize, the problem is not to find a technology, then hunt for a need.
However, you have to know what is feasible when you are listening to community
Community needs
may have
off-the-shelf
technological
solutions, a demand
for modification of
technological
solutions, or need to
invent novel
technologies.
4.6 Humanitarian Technology
537
needs so that you do not give false hope about effectiveness of solutions. If you
are considering very large challenges, sometimes with no apparent solution, it
makes sense to “bite off a small piece” and start on some tangible and feasible
technology solution. This may require you to accept that you are not directly
getting at “root causes,” but hopefully you are “chipping away” at the root
problem and not just treating symptoms. But of course, there are times when
just treating symptoms can be valuable as for a number of situations you can
argue that nothing is wrong with using technology to alleviate suffering.
It is important not to ignore cases where problems identified by a community
seem completely intractable. You may not in the short-term take on such a
problem, but it should be viewed as an “innovation opportunity.” You may
want to get an advanced research program started to try to address the issue
(e.g., involving faculty and graduate students, or the research division of your
company). Take a long-term perspective. If it is truly an important problem
for the community, and you also determine that it is a widespread problem, you
certainly want to pay attention to it.
4.6.2
Challenges of Extreme Constraints and Unusual TradeOffs
From the extensive experiences in deploying technologies in the developing
world, one thing that has emerged is that “design constraints” (what is acceptable, how the technology must perform, etc.) are often “extreme” in the
sense that they are often far different from those encountered in the developed
world. These arise from client and community needs, in a different context
than the developed world (e.g., in the tropics or a desert). In a certain sense,
using the word “extreme” is ethnocentric; constraints discussed below can be
viewed as normal and natural in many parts of the world. It is often persons
from the outside (e.g., visiting humanitarian engineers) who call the constraints
“extreme” (“tough” or “demanding”).
Another finding of humanitarian engineers is that “trade-offs” defined by
clients and communities in the developing world are “unusual” (“unexpected,”
“strange,” or “mind-bending”) relative to what they have seen in the developed
world. Clients’ views must dominate your view of how trade-offs should be
made in technology design. Clients and context are different so it should not
be surprising that trade-offs are different. The proper attitude toward extreme
constraints and unusual trade-offs is to view them as welcome challenges that can
drive significant innovation and make sure that the participatory development
process results in appropriate and good community impacts.
Next, a sample of extreme design constraints and trade-offs are listed; there
is no intent here of listing all possible constraints and trade-offs as that is impossible. The main intent is to provide concrete examples so that you are on the
look out for these issues, acknowledge them, and listen to what the client and
community are saying, no matter how unusual it seems to you. This is critical
for the success of a humanitarian technology.
Design constraints
and trade-offs that
arise from the local
context can be quite
different from those
found in your own
country.
4.6 Humanitarian Technology
Extreme Design Constraints
Consider the following cases:
1. Ruggedness, reliability, robustness, and resilience: These terms mean similar things in many contexts, and sometimes are interchangeable. Ruggedness, often, though, means that the technology can survive under harsh
mechanically-induced conditions (e.g., dropping the technology). Reliability typically means that the technology will continue to perform adequately over a long period of time in spite of use under a wide variety
of conditions. Robustness was discussed in Section 4.5.2, and is a general
property present when a technology’s functional performance quality is not
sensitive to relatively small variations (e.g., mechanical or environmental).
Resilience can be thought of as the same as robustness, depending on how
these terms are used in different fields, but this term is often reserved for
very large-scale complex systems (such as cities or in the wide-area technologies discussed below), sustainability studies for large regions, and in
humanitarian engineering it often refers to community resilience (Amadei,
2014). Engineers in the developed world design such properties into every
technology that has any chance of surviving with users and in the market
in the developed world. Why? Competition with other industries drives
this as they are often key properties in establishing long-term value of a
product and through this, the success of the product. A similar concept
can hold for the developing world. However, “extreme” demands along
these dimensions frequently arise. For instance, will an electronic technology designed for the developed world with a temperate climate be reliable
in, for instance, the tropics or arid regions of the developing world? Are
humidity and temperature conditions going to result in premature product
failure, or performance degradation? Products must always be developed
for local conditions, and often tested for such conditions to make sure the
design performs adequately, and over a long time period, before manufacturing and distribution.
2. Low cost: If you are taking a social business approach, clearly you can
have severe cost constraints that result in a “price point” (what you determine the customer will spend) that is extremely low by developed world
standards. Yet, of course, the customer wants top performance also. If
you are developing a technology to sell to the aid community, then clearly
cost will also play an important role: you may be competing with another company to provide the technology, or the aid agency will want it
at the lowest possible cost so that they can affect more people (e.g., at
a subsidized price). If you are working with a community on developing
a technology and you plan on donating it at the end (since they participated, “paid,” in other ways), then again, you have a motivation to keep
all costs low as the money comes out of your own pocket. This emphasis
on cost is not surprising: the very definition of engineering typically includes a comment on low cost, no matter where you are doing engineering.
538
4.6 Humanitarian Technology
The only thing “extreme” is typically a demand to make cost significantly
lower than what an engineer who works in the developed world usually
deals with.
3. Local materials and maintenance: Often, you want to put together a product that uses locally-available materials or other resources. Why? It drives
down costs, and may not pollute as much (e.g., to transport materials). If
you are engaged in social business, this can be a critical issue as manufacturing simply may not be feasible if you are relying on imported materials,
or materials from very distant locations. Connected to this is the need for a
good supply chain and support structure for the technology. For instance,
what if the technology breaks down? Who will be able to service it? Are
people with proper expertise nearby? Maintenance people? Technicians?
Can a local person be trained for this? Can they be incentivized for this?
Examples of such technical support are the many micro-businesses that
have sprung up around the developing world to fix cell phones.
4. Size and weight: Often, for usability and cost reasons, it is best to make a
product as small as possible, and to weigh as little as possible. Of course,
for some technologies, making it lighter or smaller may cost more money.
The key is to recognize the value of low size and weight in the context of
the needs of your community.
5. Safety and risk: A principle of engineering ethics is that safety and risk
depend also on local conditions and the types of clients that will use
the technology, which can be different in the developing world. Are labels/warnings on a product in the local language sufficient? Or, to be
responsible, must an educational program be associated with some technology that can impact safety and health of the user and the community?
The safety constraints arising in the developing world may be viewed as
“extreme,” but must always be a central concern of a professional engineer.
Examples here are health care technologies, energy supply approaches,
some agricultural technologies, or water filtration methods for drinking
water. For the last case, the contaminants can be “extreme” creating
a very challenging filtration technology problem, sometimes where with
affordable filtration you may not meet high standards of water quality.
This can create significant ethical considerations, especially with respect
to whose standards must be met for “potable.”
6. Environment and sustainability: These issues are at least as important in
the developing world as in the developed world, and often more important.
In the developing world there may not be the funds to have recycling or
waste remediation programs, or the community may exist in more fragile
ecosystem, or have nearby rare species.
In many cases, these constraints cannot be thought of as independent of each
other. Constraints can have complex interactions or coupling. Moreover, within
539
4.6 Humanitarian Technology
the “design space” (the range of all parameters of a design), there are “tradeoffs” between the designs that will result in satisfaction of the extreme design
constraints to various extents as is discussed next.
Unusual Design Trade-Offs
Some examples of the ways that clients and communities may view trade-offs
in meeting their needs, which then translate to trade-offs in a human-centered
design (IDEO, 2014, 2015), include:
1. Ruggedness vs. cost: In different contexts, and for different technologies,
clients may favor a very rugged product that lasts a long time even if it
costs more. This can happen if maintenance services for break-downs are
not near by, are expensive, or if the technology has a continual impact
on them (e.g., clean water on their health). In other situations, a client
may accept a less reliable product if they at least get a year of good
performance out of it; if this is all they can afford, and if the technology
has a “return on their investment” in purchasing it, a low-cost relatively
unreliable product may be acceptable.
2. Ease of use vs. reliability: In some situations it may be that clients may
prefer a product that is difficult to use (e.g., requires more human labor) so
long as it is more reliable and has a longer expected period of service/use.
This may contrast with the developed world where such a trade-off may
not be acceptable.
3. Functionality/ease of use vs. cost: Sometimes, a community may prefer
a simple low-cost product over one that has what they may view as the
“unimportant” or “peripheral” functionalities of a technology. Such peripheral functionalities may make the product easier to use, but they may
happily invest their time or effort so long as the cost is low.
4. Cultural issues vs. functionality: It can be very difficult to know the impact
of cultural values (e.g., religious values) on the design of a technology and
how it functions. The culture you work with may have a view that the
environment is a “spirit” (God-like) and hence greatly value not polluting
with a technology. Or, they may be in such dire need that they have no
concern whatsoever about the environment and just want needs met. In
other cases, it may be that it is unacceptable for one gender to operate a
technology if it functions in an “improper” manner.
Of course, several of these trade-offs may seriously challenge your own values
and competence. For instance, should you accept their view of safety, where
they may accept very unsafe operation in exchange for low cost, considering the
central dictate of engineering ethics to protect the safety, health, and welfare
of the public (see Section 2.3.3)? In the developed world that would generally
be considered unacceptable. Or, should you accept their views of willingness to
pollute considering the views of engineering ethics on sustainability, sometimes
540
4.6 Humanitarian Technology
541
arising from a concern that a polluted environment degrades human health?
These are difficult issues; however, sometimes a very competent engineer can
indeed meet client needs and respect the mandates of engineering professionalism and ethics. You should understand, acknowledge, and aggressively seek to
meet such challenges, seeking technical advice from others as needed. It is your
professional and social responsibility as a humanitarian engineer.
Of course, the above is only a brief but representative list. Also, such tradeoffs can interact or are coupled: if you favor one direction for one trade-off
you may want to favor a different direction for another. You certainly would
not assume that you will encounter each of these constraints and trade-offs, or
indeed, any of them. Or, in some contexts, some of these may be relatively
similar to those in the developed world (e.g., cell phone functioning). Your
situation for a community may be different, and ultimately the clients and
community are the sources of information on constraints and trade-offs; you
always keep the technology human-centered.
4.6.3
Appropriate Technology
Though Indian leader Mahatma Ghandi is often thought of as the “father” of
appropriate technology, E.F. Schumacher popularized the notion of “small is
beautiful” (Schumacher, 1975), and connected to this there has been significant
work done on this ideas, and Schumacher’s philosophy is often cited as a basis
for the appropriate technology approach. There are a whole range of available
definitions, but typically:
“Appropriate” technologies are small-scale (e.g., personal), have suitable complexity for the need and scale, are simple to operate and
maintain, are energy-efficient, use local materials (respect the realities of “supply chains”), are environmentally friendly, are low-cost,
and are “human centered” (Hazeltine and Bull, 2003; Martin and
Schinzinger, 2005).
There is a long tradition of openly publishing all details of how such innovations are made, but of course this may be at odds with a business approach to
development where intellectual property and patents are important to protect
a company. Humanitarian engineers think of appropriate technologies as ones
directed toward helping people in the developing world, and as the key concept
underlying humanitarian technology. Here, we will simply think of any technology that satisfies the extreme design constraints and unusual design trade-offs
listed in the last section as being an “appropriate technology.” For instance,
technologies for homeless people, no matter where they live, are considered to
be appropriate technologies (see Section 4.6.4), as are technologies for STEM
education in a learning community (see Section 4.8).
Some examples of areas that appropriate technologies have been developed
for include the following:
• Water/sanitation;
Appropriate
technologies are
ones that meet
needs and
constraints in a
community.
4.6 Humanitarian Technology
• Food/agriculture;
• Energy (e.g., electricity, lighting, heating, and cooking);
• Health/medical technologies;
• Education (e.g., technologies for projects and laboratories discussed in
Section 4.8);
• Shelter and infrastructure (e.g., homes);
• Information systems; and
• Environment/sustainability.
No technical details for any of these technologies are discussed here as: (i) they
are freely available on-line or in easily accessible books or papers; and (ii) the
field is continually evolving and advancing and it is therefore best that you adopt
the approach of doing a literature/internet search (or attend a conference) to
find the latest and greatest innovations that may be useful for the community
you are working with. To give you a sample of what is available, a good source
for appropriate technologies is
Village Earth: Appropriate Technology Sourcebook
but other sources are provided in references starting on page 714.
There are a number of ways to categorize appropriate technologies into
groups. A common and logical approach is to group technologies according to
the need they address. Here, appropriate technologies are categorized according
to whether they are directed at individuals or communities as this often provides a clear line between two types of approaches for humanitarian engineering
projects via participatory development.
Personal Technology
In a number of contexts in the developing world there a serious lack of infrastructure and services, and it is unacceptable to wait for these to be put in place
by, for instance, a government. Needs must be met with a strong sense of urgency. In such situations, it is logical to seek solutions for individuals rather than
groups (like a community, region, or country). Such a client-centered approach
can work to meet a number of basic human needs such as:
• Water filtration systems (hand-held, effective, and low-cost);
• Sanitation approaches (e.g., see case below for homeless people);
• Electricity generation (e.g., a bicycle and generator, small wind-based, or
small-scale solar panel are common approaches);
• Food production approaches like gardens (sustainable with effective agricultural technologies to enhance yield including irrigation); and
542
4.6 Humanitarian Technology
543
• A low-cost non-polluting transportation method (of course, the common
approach world-wide is the bicycle).
Many examples of appropriate personal technologies are referenced starting on
page 714 (including references in those sources); however, to provide concrete
examples now, you can consider the cell phone or low-cost lighting which has
been studied for many years and been developed by many organizations. A
sample case is at d.light (however these systems are sometimes not used as
personal technologies, but may also impact several people, for example, in a
family).
In seeking to develop a personal technology it is important to keep the
human-centered aspect of participatory development in mind, paying attention
to critical needs, and the ideas in Section 4.1 on an engineer helping a single
individual (if that is relevant). For instance, if cost is the dominant challenge
for an individual, you may be able to use the “modularity principle” from design (see Section 4.7.8) to produce an expandable (“incremental”) technology
where one piece of the technology is bought at a time, and each piece provides
some level of benefit and functionality, and later additions can be chosen by the
client to meet needs, and fit within their earning pattern (e.g., earning daily
wages, but periodically). There are a number of times when this is possible
(e.g., in drip irrigation (Polak, 2009)), sometimes in surprising cases relative to
what is found in existing technologies in the developed world. For example, consider the modular phone PHONEBLOKS, developed for sustainability reasons,
but with obvious incremental cost implications that can be very important for
affordability as discussed in (Banerjee and Duflo, 2012).
There are many
candidate personal
appropriate
technologies that
can be used to help
people.
Community Technology
Lack of community-wide or country-wide (e.g., rural or urban slum) infrastructure is often the driver for these technologies. Water filtration, sanitation,
energy generation, and transportation (a “village truck” for taking agricultural
products to market or for moving water) can all be approached from a community (group) perspective by seeking technologies that meet the needs of multiple
individuals rather than just one. In some contexts it may make more sense to
address basic needs by doing so for an entire community together, rather than
each individual in the community (e.g., for cost per person reasons and a desire
to have wider impact).
A community technology approach has many advantages:
• It is naturally inclusive if executed properly;
• It hopefully improves conditions uniformly and hence does not create inequalities and bad feelings in a community where one person has an advantage over another;
• It often promotes the idea of sharing and cooperation and therefore not
only empowers individuals, but also the entire community’s functionings;
Sometimes, it is
more cost effective,
and greater impact
can be achieved, if a
community
appropriate
technology is
developed.
4.6 Humanitarian Technology
• It may offer lower cost and less negative environmental impact per person;
• It may be more reliable if effective group operation and management
strategies are used; and
• It also has technical advantages in some cases, such as centralizing a solution and having the resources to make that solution perform better (e.g.,
in water filtration maintaining more consistent reduction of contaminants,
in electricity generation providing a more reliable source that does not periodically shut down, or in agriculture via community fields/gardens).
Of course, in some cases it can be much more difficult to succeed in a communitywide participatory development project as the objectives then often include
infrastructure development (e.g., laying pipe, installing a large water storage
tank, or stringing wire). Challenges also include acquiring initial development
funds and putting in place approaches to operate and maintain the community
technology as is discussed in the next section.
The idea of “modular” technology above also works for a community in some
cases. One example, that could be either a personal or community technology,
is “drip irrigation” (Polak, 2009) that has a water source, and pipes with holes
for water to come out that can be connected to each other, and that can be
expanded to larger and larger regions of fields, for more and more farmers,
depending on availability of funds (e.g., an initial small purchase may result in
increased yields in one year, so that profits can be used in the next to expand the
system to cover a greater portion of a field, and so on–unfortunately, however,
in practice the systems does not work so well always, e.g., due to clogging of
holes).
Technical challenges to creating community technology may be more or less
significant than personal technology. Each case is different. However, there
is often a clear difference between engineering a humanitarian technology for
individuals versus a community, often requiring different engineering expertise
(engineering a personal water filtration technology is quite different from engineering a clean water system for a community 100 people). Also, special issues
arise for community technologies in coordinating their use as is discussed next.
Technology for Cooperation
Personal technologies are always designed to be human-centered (IDEO, 2014,
2015), and typically they are single-human-centered. Community technologies
are designed to be community-centered and hence multiple-human-centered.
There is a very basic difference in the two cases. In personal technology, issues
like ease of use and operation involve one person. Naturally, the ease of use and
operation for community technology involves a group of people with a “shared
technology” and is going to create different challenges and opportunities.
The Human Cooperation Challenge: Some of the most complicated challenges associated with community technology are social. For instance, if you
544
4.6 Humanitarian Technology
work with a community using participatory development to install a community
technology, should the community require financial, work, or time commitments
from all individuals who obtain the benefits of the technology? Why do this?
It clearly delineates ownership, has an empowering effect on those who buy in,
and can have a broader impact on helping the community believe in its ability
to work together to solve problems in the future. One approach is to use a
cooperative strategy to make sure the technology will be “self-supporting,” via
pooled saved funds, for maintenance, repairs, and eventual replacement at the
end of the life of the product. The community will need to come to an agreement
on what each person has to give, in order to receive benefits. But, the details
matter. For instance, how much money does each person (family?) have to contribute each time (per use-event, per month, or per year)? Does everyone pay
the same amount, even though some may not have as much wealth as others?
What is the dollar value of contributed work (e.g., a person who maintains the
system)? Should prevailing local wage rates be used? Should an incentive be
used to get people to buy in (e.g., one month of use at no cost)? Do all users get
the same benefits from the technology (e.g., if your payments are family-based,
then does a family of eight pay the same amount as a family of three?). What
happens if someone “cheats” by skipping payments or by not living up to the
agreement? Who decides the “punishment”? The group of users? A single
leader? Then, there is the difficult question of whether an outsider can suggest
a cooperation policy for the community? Can an outsider present the important
concepts of how it “might work”? This issue is at least as complicated as the
question about whether to suggest a technology for a need that was discussed
above.
Technology Design for Facilitating Human Cooperation: From a humanitarian engineer’s perspective, the cooperation challenge is “socio-technical”
(and perhaps “socio-eco-technical”) as it involves individual and group human
behaviors (and hence individual and group psychology), there may be significant
cultural aspects (tendency to trust or cooperate with a basis in anthropology,
sociology, and psychology), and the engineer must keep these socio-challenges
in mind and try, right from the start, to design the community technology so
that it is easier to implement an effective long-term community cooperation
strategy for operation and maintenance. There are two general issues: how
the technology and human group interact (“cooperate” with the view of the
technology as an “artificial agent”), and how to design technology to promote
cooperation. The first lies in the well-studied realm of “human factors” and
“human-technology interface.” The second will be discussed here in a bit more
detail.
Success of the community technology project can depend critically on the
ability of your participatory development team to “design for cooperation.”
There are a few principles that may guide the development of cooperative technologies:
1. Cooperation theory: The engineering design team is going to need to study
545
Human cooperation
of technology use
and maintenance
can be very
challenging.
Technologies can be
used to promote
human cooperation
for community
technology use and
maintenance.
4.6 Humanitarian Technology
546
the principles of human cooperation using a number of areas of social
science (psychology, social work, sociology, economics, political science,
anthropology) and natural sciences (evolution and behavioral ecology have
much to offer by considering human and animal models) in order to design
a good solution (e.g., see Section 4.3.1).
2. Cooperative technologies: The engineering design team is going to need to
learn about cooperative technological approaches that exist for other applications. There are solutions for cooperative task processing, cooperative
scheduling, cooperative resource allocation, cooperative choice (agreement
or consensus), cooperative motion, cooperative leader election, etc. You
should search the relevant literature, but be aware that this can be difficult as there are many terms used for “cooperation,” or that have close
meaning, like “collaboration,” “crowd-based,” “crowd-sourced,” “group,”
“multi-agent,” “team”, “collective,” or “coordination.”
3. Deployment: The community should be involved in specifying the cooperation strategy and be given the autonomy to change the strategy if they
feel it is not working; hence, it is likely that you will need to make it possible to change the strategy periodically, and this often then implies that a
software system is used since it is then possible to produce a user interface
that allows for changes (reprogramming). This also raises the issue of controlling access to making changes (e.g., should there be a software system
that requires entry of multiple personal passwords from some number of
community members, or via the internet to someone somewhere else?).
Socio-technical systems that achieve close human-technology interaction and effective human cooperation present fascinating and very challenging engineering
problems. In Section 4.12.1 the ideas of this section are explored further, and in
particular one strategy for “cooperative management of community technology”
is introduced, simulated, and analyzed.
4.6.4
Example: Technologies for People Who Are Homeless
Section 1.1.2, but also Section 1.2.1, and Section 1.2.2, discuss issues with homelessness world-wide and in the US. While great suffering results from homelessness, there are humanitarian technologies that can help.
Examples of humanitarian technologies for people who are homeless in the US include low-cost
versions of the following:
• Make-shift shelter: For a make-shift (personal) shelter for living in, for
example, the woods or street, some requirements may be: (i) use of free
or low-cost local materials; (ii) weather-resistance to cold, snow, ice, and
rain; (iii) protection from a possible wet, muddy, and cold ground which
may require slightly elevating the shelter (e.g., via a pallet) or using a tarp;
(iii) sturdy so it will not collapse under snow and ice loads; (iv) having
There are a range of
technologies that
can help people who
are homeless.
4.6 Humanitarian Technology
convenient ventilation; (v) easily convertible between winter and summer
living; (vi) rugged/durable to get a long life; (vii) good internal light;
(v) possibly transportable (e.g., via carrying it or via the cart discussed
below); (viii) secure against theft of the shelter and what is in it; and (vii)
aesthetically pleasing and/or camouflaged so that people will not be as
likely to be removed from various locations by authorities. Each person
living outside may have different requirements.
• Heating for a tent or shelter: Some requirements may be: (i) safe and
non/low-polluting so it can be used inside a tent or shelter that is closed
in the winter, (ii) provides sufficient heat output during winter, (iii) lowcost fuel, and (iv) lasts all night without tending so people can sleep well.
• Lighting for a tent or shelter: Some requirements may be: (i) safe and
non/low-polluting so it can be used inside a tent or shelter (e.g., energy
via renewables like solar), (ii) provides sufficient light for reading or work,
(iii) low-cost fuel, and (iv) lasts a sufficient amount of time.
• Cooking methods: Some requirements may be: (i) safe and non/lowpolluting so it can be used inside a tent or shelter, (ii) provides sufficient
heat for completely cooking meals, and (iii) low-cost fuel. It may be possible that cooking, lighting, and heating methods are all provided with one
approach.
• Sanitation methods: Some requirements may be: (i) methods to capture
human waste and dispose of it and (ii) methods to dispose of trash.
• Cart for materials and belongings: Some requirements may be: (i) larger
wheels so the cart is easier to move over rough terrain such as in a woods,
(ii) a cart that can be secured against theft, and (iii) water/weather protection methods. A pull-behind, rather than push-ahead, cart may be
better for rough terrain. For example, a pull-behind piece of luggage may
be suitable for personal belongings.
While these are aimed at the US, it should be clear that in various forms similar technologies could be useful on an international scale. The features of each
technology above are ideas rather than definite requirements. Of course, participatory development (Section 4.2.4) and participatory technology development
(Section 4.7) should always be used, complete with participatory action research
to assess needs (Section 4.2.8). People who are homeless need to be asked what
features of a technology are important to them. Of course, technologies such
as those above would have to be better than what is currently used (e.g., in
terms of cost and features), and it may be useful to simply provide the designs
or instructions via prototypes, so that individuals can construct the technologies themselves. This may be better than donating an actual physical piece of
technology, or even providing it at a subsidized cost. In some cases, however,
for example for the severely mentally ill, such technologies could be provided by
social support services in the area for free, at a subsidized cost, or at-cost (e.g.,
547
4.6 Humanitarian Technology
a homeless shelter that does not have enough beds for everyone in the winter
could provide make-shift shelters using donations from the community).
Progress on some of the above technologies has been made here
Tech4 Community
(Technology for Community) which was created based on ideas in (Passino,
2009). Tech4 Community is focused on working with an urban US community
and having engineers work with the community to create useful technologies,
typically, ones for individuals or families, analogous to a free medical clinic or
legal aid clinic. Also, there is a focus on providing “technology services” for
local service providers (i.e., engineering for helping the helpers), such as food
pantries. While at the present time it is based in Columbus, there is no reason
this model would not work in other US cities, and with adaptations, to other
locations.
4.6.5
Technology Selection for Clients, Communities, and
NGOs
When considering the range of options for a humanitarian technology for a
client, community, or NGO there is often the challenge of comparing and selecting a technology from a set of candidate off-the-shelf technologies, or assessing
available off-the-shelf technologies to see if there is a need for a humanitarian
technology invention. Local problems are always different; hence, the need for
the creation of new technologies is not necessarily an unusual case, or at least
there may be a need to modify an off-the-shelf technology to adapt it to solving
a local problem, and this can take significant creativity. Sometimes, NGOs need
technical assistance in evaluating technologies that they want to purchase, typically ones for their communities or individual clients. The NGO may purchase
these technologies with donor funds or receive them via in-kind donation and
may give them away, provide them at a subsidized cost, at-cost, or simply by
providing a recommendation to their clients. It can be difficult to match needs
and context to technology solutions; there are typically too many technology
options to consider, and to do a good evaluation may require significant technical skills and possibly experimental evaluations of technology options. This
may create the need for a humanitarian engineer’s assistance. Just like the case
for clients and communities, the end result of such an evaluation may be that
there is no technology that is suited for the problem at hand. One option for
this case is to invent one.
Making the Problem Statement
To start, it is best if a very clear problem statement can be made that includes needs, context, and technology solutions. The inputs from the community
and/or NGO, who typically know quite a bit about these issues, but possibly
not the technology part, are crucial as discussed throughout the earlier sections
of this chapter. The manner in which you phrase questions to the community or
548
4.6 Humanitarian Technology
NGO so that you can formulate the problem statement is important. Getting
a good problem statement is a large part of the technology evaluation problem.
All the above participatory development ideas (e.g., PAR) are relevant here.
Some typical questions you may want to consider asking are:
• What need do you have in mind? How many people have this need? How
does this need rank relative to other needs? How will meeting this need
help people? How were these needs determined? How much are end users
willing to pay for a solution?
• Who is going to use the technology? How and where will the technology
be operated? What conditions do the users live in? Can you tell us about
the context within which the technology will be operated?
• What are the client/user expectations? To what extent do they expect
their needs to be met?
• What technology is used now (if any) and what is wrong/right with it?
What additional technology features would you like to see and why? Is
increased performance for some aspects of the technology needed? Can
performance be decreased for other features? Do you have alternative
technologies in mind?
• What problems, that are not being solved now, should be solved with the
new technology solution?
• What are the operational characteristics that should be present? Which
features are essential and which are optional? How complex can the technology be? How easy should it be to use? Is the technology solving the
real problems or problems that do not really exist?
• What is the price target initially and the price of operation and maintenance for the technology? Delivery costs? How complicated is operation
and maintenance?
• If working with an NGO, can I meet the community/clients on-location to
learn about needs and context first-hand? Can I see the current technology
in operation? Can I survey the community (do PAR) about needs and
current technology effectiveness? Can I run field tests on its effectiveness?
• What technologies are locally available? Is it acceptable to order technologies from other countries or locations?
• Can the technology be locally maintained, repaired, and replaced? Who
is responsible for maintaining the technology? Are there affordable spare
parts or service available?
Of course, some of these questions may be inappropriate for a particular case,
or these questions may change for different communities and NGOs, needs,
contexts, and technologies. Whatever questions you use, your goal in asking
549
Establish a clear
problem statement
on what issue needs
be addressed with
the technology.
4.6 Humanitarian Technology
550
these questions is to formulate a detailed problem statement for technology
evaluations.
Evaluation Methodology
Given the problem statement developed in the last section, the next step is to
begin work toward developing a technology recommendation for the community
or NGO. There is no single methodology for evaluation of technologies, but some
broad guidelines are as follows:
1. The starting point is the problem statement, with needs, priorities, context, and existing technologies defined.
2. Conduct fieldwork that includes PAR for needs, an evaluation of context
(including operational conditions), and evaluation of current technologies
if they exist.
3. Learn more about needs and contexts for other (similar) locations for a
similar technologies.
4. Research and learn about the technologies (science, operational characteristics, technical specifications, cost, etc.).
5. Identify key performance metrics (e.g., how long it should be able to be
continuously operated, reliability, ease of operation, the quality of the
products it produces, affordability, cultural acceptability, sustainability,
etc.).
6. Do a cost evaluation for each candidate technology that includes purchase/delivery cost, operational costs, and maintenance costs. Study supply chain issues for the technology and its components, and whether they
are available locally.
7. Choose a subset of technology options, the ones that appear to be the
best, and quantitatively and quantitatively assess each one and compare
them to each other (see below). This subset could include an existing
technology that the community/NGO is using, if there is one. The subset
under consideration probably should not hold too many options as full
evaluations for many options may not be possible, especially field tests.
Moreover, sometimes it is simply obvious that some technology will not
fit the needs.
8. Evaluate the technologies at multiple sites, repeat above as necessary, and
adjust evaluations.
9. Do experimental evaluations of the technologies if needed and possible
in a laboratory, and if feasible do the evaluations at the site. Conduct
surveys, focus groups, and ethnographic observations of technology in use
in actual environment. Gather data from customers, including end users
in the community, and intermediary NGO personnel.
Try to follow or
establish a
systematic
methodology for
technology
evaluation.
4.6 Humanitarian Technology
10. Develop a ranking methodology for the technologies using the set of qualitative and quantitative assessments (see below) along with an overall
quality evaluation for each candidate technology.
11. Select and recommend a technology to the community or NGO, or a set
of technologies to consider. Sometimes, this would include a technical
report that includes all the above aspects, and perhaps the spreadsheet
that would automate the computation and ranking of technology quality
evaluations (see below).
12. Repeat above steps as necessary after getting community and NGO feedback on the selection and report.
13. Involve, for all steps above, the community and/or NGO as much as possible. Put them in the driver’s seat.
This process is also more broadly iterative. After the chosen technology is
deployed for some period of time, the whole process (including in the last section,
and the next one), or parts of it, may need to be repeated to make sure a
technology is properly meeting needs in context at the present time, or to try
to find a better technology (e.g., if new ones have been developed) for current
needs and context.
Multicriteria Decision Making for Selection of Humanitarian Technologies
Rather than providing a specific numeric example, here it is explained how to use
the multicriteria decision making approach in Section 4.5.2 for the off-the-shelf
technology selection problem. To do that, it is convenient to slightly change the
terminology from that section according to:
• Preference → Technology quality (but both terms could work)
• Criteria → Feature (assessment of feature)
The term “alternative” is appropriate here, or “option.” Normally, it will be
natural to use “importance” and not priority, but that may not always be the
case. All of the ideas on how to define the Pi from Section 4.5.2 apply here,
as do the ideas on sensitivity analysis and robust selection, and the use of the
computer program RobustMCDM.m. Hence, the technology selection problem
here is a straightforward application of multicriteria decision making, as is the
project selection problem in Section 4.5.3.
4.6.6
Humanitarian Systems Engineering
The design of a humanitarian technology that affects a sizable system (e.g., a
manufacturing system), a wide area problem (e.g., a whole country), and many
people, but is a single integrated system (it may be centralized or “distributed”)
is created by humanitarian systems engineering. Assessing need for a wide-area
551
4.6 Humanitarian Technology
solution is difficult and may come from data gathered by, for instance, the UN
or World Bank (see Chapter 1); however, the engineer should stay as “close to
the ground” as possible, working with locals and talking to people (e.g., average
citizens or experts in an NGO, aid organization, or government organization).
While you may naturally think of the technologies below as applying to large
regions, a number of ideas can be scaled down to local communities or specific
locations.
Engineering and Sweatshops
A relatively small-scale humanitarian systems engineering problem is the design
and operation of manufacturing facilities in the developing world in a way that
does not result in “sweatshop” working conditions and environmental degradation. Manufacturing engineering for such sites includes the following concerns,
ones that can be broadly broken down into exploitation of low-income people
and the environment:
1. Health and safety standards when there may not be laws, or at least enforced ones, protecting workers and ensuring healthy working conditions.
2. Worker rights, including a living wage, protection from abuse (e.g., from
supervisors or being forced to work overtime), right not to work as a child,
freedom of association with unions, and the right to strike.
3. Pollution and excessive resource use in order to operate the sweatshop at
low cost and maximize profits.
See pp. 89, 131, and 135 of (Rivoli, 2009), and also Chapter 2 (e.g., Section 2.2.2).
What can an engineer do to improve the conditions at a sweatshop, or make
sure that a manufacturing site is set up not to be a sweatshop in the first place?
There are clear standards to be met for such sites, such as ones established
for the developed world, but the key problem is whether raising standards will
result in raising costs to the extent that the sweatshop is put out of business,
only set up to run in a similar exploitative manner in another country (called the
“race to the bottom,” e.g., in Part II in (Rivoli, 2009))? Of course, that could
be very undesirable as workers may be relying on a steady wage, one that is
better than anything else available to them, and better working conditions (e.g.,
compared to working in rural agriculture (Rivoli, 2009)). See the discussion on
this and related issues in Section 3.2.1 and also Section 3.2.4. Historically,
however, locations that had won the race to the bottom, then later lost to
another location, reaped some benefits for their people (e.g., see (Rivoli, 2009)).
See Problem 4.52.
Wide-Area Problems
There are a number of “wide-area problems” (in both development and disaster
relief) that arise and that technology can be very useful for, and they often
552
4.6 Humanitarian Technology
involve “sensing” (getting information) and coordinating its use across large
areas (see, e.g., (Davis and Lambert, 2002; Meier, 2015)):
1. Natural and human-made disasters: Information technologies may be useful for gathering data about conditions on the ground (e.g., via crowdsourcing from individual cell phones) when some communication infrastructure is adversely affected by a hurricane or earthquake. War often
creates great humanitarian need across large populations and areas. For
both cases, there is a need for humanitarian technologies (e.g., logistics)
to coordinate transport of essentials (e.g., food), coordination of services
(e.g., refugee housing), all to avoid wide-spread suffering (e.g., famine).
2. Coordination of services: Information technologies can be very useful to
coordinate services not only for disasters but for existing social services
in a country (i.e., to make the “helpers” more effective). For instance, in
Columbus, Ohio, it would be very useful to have a county-wide web-based
information system to coordinate all social services, including: scheduling
shelter, scheduling access to food pantries and soup kitchens, making the
mental health services more effective with clients (e.g., via e-reminders
to take medications), or having e-identification to avoid the problem of
having paper/plastic identification getting lost or stolen.
3. Digital mapping: It can be useful to map information relative to poverty,
development, and efforts to help (e.g., a digital map that uses global positioning system (GPS) information, coupled with other aspects such as
population density and health service locations “overlaid” on a spatial
map, to identify areas of need).
4. Agriculture: Digital mapping can be used for assessing moisture content
and planning irrigation to reduce effects of drought and efficiently use
water. Supplying weather information to cell phones may provide useful
information for local farmers. Obtaining information about a distant market (e.g., via a cell phone) may be useful for a farmer to plan how to get
the best price for her/his produce.
5. Environment: Monitoring and gathering information about environmental
variables can be very useful in coordinating activities to reduce adverse
impacts on the environment (i.e., an “eco-technical” system).
Technology for Fighting Structural Injustices
It is a principle that if you are trying to help a group of people solve a problem
(e.g., poverty and development), you need a group of people to make it happen.
This is highlighted in areas from social work (Homan, 2011) to social justice
(e.g., consider the need for activism). Often, problems for groups of people arise
due to “structural injustices” that you can think of as the “rules of the game”
or “patterns of oppression or corruption” in economic and political systems, or
even the workplace. Such problems are pervasive. They occur all the way from
553
4.6 Humanitarian Technology
554
the family and community, to the country and world levels (e.g., unfair trade
policies, wide-spread discrimination, economic inequalities, and conflict/war).
They are naturally “wide area,” and social justice perspectives from Chapter 2
highlight the problems, provide us a broad understanding of the problems, and
often give hints at solutions, at least by saying what “ought to be” (religious
approaches), what is “ideal” (e.g., Rawls), or what to change to remove injustices
or promote justices (e.g., Sen). While the environment is listed above as a widearea problem, it is of course also a justice issue, as are the other issues above if
you view poverty and lack of development as an injustice, which most do.
To be more concrete, some specific humanitarian systems technologies include:
1. Open systems and structural problems at work, in economics, in politics:
Transparency is a fundamental strategy to fight corruption, promote participation, and ensure fairness. Specific examples include (i) open webbased database technology for publishing a government’s budget and full
real-time tracking of flow of all money; (ii) electronic media for promoting open communication to a populace from a government and vice versa,
open communication to a government from the populace (including “data
analytics” to interpret the data from the populace in a fair manner) to
promote democracy; and (iii) open web-based information on all aspects
of the market to ensure that it is free and fair. All of these ideas are
technologically feasible today, requiring no fundamentally new technology; however, there is a need for basic advancements in systems theory
(e.g., distributed algorithms) to address a number of these challenges, such
as fraud detection (Finke, 2013). See Section 1.1.2, Problem 4.54, and also
Problem 4.55.
2. Fighting systemic evil in illicit markets: The significant problems of human trafficking (adult and child, female and male, for sex trade, slavery/forced labor, forced child soldiers, forced begging rings, etc.), the illicit drug and weapon trade, garbage trade, and organ and rare species
trade, all demand more attention from engineers. In some cases, root
causes certainly cannot be addressed by an engineer (e.g., root causes for
why someone would capture and hold a child as a sex slave). However,
there are ways to use technology in the fight against these injustices. For
instance, sensing and data gathering via smart phones can, perhaps via
geo-mapping methods, help identify sources of problems and patterns of
flow that may help solve problems some times. For instance, (Chongsiriwatana, 2013) indicates an interest in humanitarian engineers developing
distributed information technologies (data base and tracking) to help fight
child trafficking. Data analytics could be useful in this context if the scale
of the problem is large. See Section 1.1.2 and Problem 4.56. Similar
concepts will, perhaps, be useful to fight the evils in other illicit markets.
Each of these systems is a large scale socio-eco-technical system that is incredibly complex, and each presents especially large challenges for “humani-
Technologies may be
useful in addressing
some wide-spread
injustices.
4.7 Participatory Technology Development
tarian systems engineering.” It is unlikely that a small group of engineers can
solve these problems by themselves. Team/organization expertise is needed
in a number of areas, including social justice (religious and secular perspectives); social science foundations; information technology, data analytics, big
data, distributed algorithms, and software engineering from computer science
and engineering and electrical engineering; nonlinear dynamics and stochastics;
feedback control theory and engineering; and a number of other areas like signal
processing, communications, and computer networks. As usual, the principles
of use of local knowledge and expertise on understanding the problem (context),
how to fix the problem, and how to make sure it does not re-emerge are crucial for the success of humanitarian systems engineering. Clearly, to make this
happen, significant advances in engineering technological systems that cooperate between themselves, and promote cooperation in human groups are needed
(i.e., an expansion of the ideas on cooperation and technology for communities).
For more relevant discussion, see Section 4.12.3.
For additional related issues, particularly in engineers’ involvement in weapons
development and law enforcement, see Problem 4.57, and for humanitarian military intervention, see Problem 4.58.
4.7
Participatory Technology Development
Participatory technology development (PTD) involves the use of helping theory
(Section 4.1), participatory community development (Section 4.2), coupled with
human-centered design (IDEO, 2014, 2015) and traditional product design (Ulrich and Eppinger, 2012), to provide a process for participatory humanitarian
technology product design. The process of participatory development shown in
Figure 4.2 is general enough to include PTD as a special case, and it is suggested that the reader use it as a guide for thinking about interconnections
and dynamics in the overall PTD process. For Figure 4.2, challenges/needs
are identified that have technologically-feasible solutions and these define the
project. The participants in PTD typically include engineers, possibly from
the outside. While PTD is a special case of participatory development, in this
section, and sections to follow, we discuss specific details of the engineering
participatory technology development process for products to make the process
more concrete. The reader should not, however, ignore all the issues discussed
in Section 4.2.4; all those apply here also, but many of them are not repeated.
4.7.1
Participatory Technology Development Up Close
To start, it is suggested that the reader view the YouTube videos of
The Water of Ayolé (search the internet for this)
For this video, identify the key elements of participatory development for pumps,
a technology product. See Problem 4.20. Next, view the talk
Creating a New Handpump Solution in Africa
555