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