# E8 Problem definition and AI alternatives Items not yet agreed. Pages here are candidate items. > [!WARNING] > 2 of 2 pages in this bucket are not yet reviewed. Each says so at its top. ## Non-AI alternatives Page: /problem-alternatives/non-ai-alternatives > [!WARNING] > Draft, not reviewed. A subject expert has not yet checked this page. Treat it as provisional. > [!NOTE] > Candidate item. The MTI team has not yet agreed the items for this bucket. **Question:** Would a simpler, non-AI or non-digital option meet the need as well, and why is AI the better choice here? Evidence: practitioner-consensus · Audiences: all · Type: question · Status: draft · Updated: 2026-10-17 ### Basics Before funding an AI tool, find out what else could meet the same need. Options include changing how work is done, a basic digital tool, more training, more staff, a policy change, or doing nothing new [src-007 p18; src-015 p43]. A team should list these options with the benefits, limits and risks of each, and say with evidence why AI does better [src-001 p1]. If it cannot, the project may work as well or better without AI [src-004 p16; src-012 p22]. The separate page on problem definition covers how to state the problem itself. ### Why it matters for AI tools AI added where it does not fit can waste time, bring new risks and make services more fragile, and low-resource settings feel this most [src-007 p18]. Many AI tools need digital and AI literacy that poorer and marginalised groups may lack, so the people with most need may be the least able to use them [src-028 p15]. AI tools also cost more to keep running than fixed content such as standard text messages, because models, data and user behaviour change and the system needs updating [src-015 p44]. Where a tool scores or models people, as in credit scoring, the case for it should be strongest, including a reason why no reasonable alternative exists [src-035 p12]. Interest from donors or the media in new technology can push a programme towards tools that do not suit its users [src-038 p24]. ### What good evidence looks like - The proposal lists several ways to solve the problem, including a no-technology option, with the benefits, limits and risks of each [src-001 p1; src-030 p6]. - It names measures showing AI beats the other options, not only that AI can do the task [src-001 p1; src-015 p44]. - It describes how the problem is handled today and what the current process or tool fails to do [src-025 p18; src-030 p29]. - It states what the team would do without AI, such as a simple decision rule or more staff [src-015 p43]. - It counts the full cost of each option: data, dealings with mobile operators, upgrades, total cost of ownership and time spent supporting users [src-030 p30]. - It shows whether adding features to an existing tool would be cheaper than building a new one [src-030 p30]. - It shows that the people who need the service have the devices and skills the AI option assumes, or explains how others will be reached [src-028 pp15, 18]. - It shows the AI part supports existing workers or services rather than replacing them, or gives reasons where it replaces them [src-015 p21; src-039 p29]. - It describes a low-tech version of the service, such as a feature phone or human route, that users can fall back on [src-012 p24]. ### Red flags in a proposal - AI is chosen before other options are compared [src-001 p1; src-007 p18]. - The case for AI rests on what the technology can do, with no comparison against the current way of working [src-030 p29]. - The proposal assumes target users will soon own smartphones without evidence on cost, literacy, power or airtime [src-032 p10]. - A tool that scores or ranks people gives no reason why a traditional method would not do [src-035 p12]. - The budget covers building but not upkeep, updates or user support [src-015 p44; src-030 p30]. - AI replaces a human role, such as coaching, where trust and feedback matter, with no evidence it works as well [src-015 p21]. ### How to find out Map existing services and what already works for the target group, then ask which parts could move to a digital channel [src-016 p3; src-028 p13]. Run a stop-and-review point after the context work and before choosing any technology: ask whether the technology will help meet the goals, save time or money, do new or better things, or increase equity [src-004 p16]. Test each problem against a set of conditions for AI fit with a mixed group of staff, including frontline workers [src-007 p18]. Use a decision tree that sends the team back to other options when it cannot say how AI is better [src-001 p1]. Compare costs, using cost-benefit or cost-effectiveness analysis to set a technology route beside a traditional one [src-030 p44]. Ask whose job it is to fill a service gap, since advocacy may suit better than a new service [src-039 p29]. Plan to pilot the AI tool against a non-AI option before scaling [src-015 p20]. ### Limits and disagreements Support is broad: the core point appears across about a dozen publisher families. Most of these sources, though, are toolkits that state the principle rather than test it. Only J-PAL reports trial evidence, and its findings come from specific settings: teacher coaching in South Africa and labour courts in Mexico [src-015 pp21, 44]. J-PAL also shows AI can add value, but sometimes only when the process around it is right [src-015 p44]. Seven of the fifteen sources do not discuss AI at all; they speak about ICT (information and communication technology) in general [src-004 p16; src-006 p39; src-030 p6; src-038 p28]. Their lessons carry over, but they were not written about AI. Sources differ on how high to set the bar. Pollicy asks for the strongest proof only where tools model human behaviour and asks less of tools that model crops or weather [src-035 p12]. NIST treats non-AI options as part of routine risk work for any AI system [src-024 pp38, 43]. NIST writes from a United States risk management setting [src-024 p38]. Several sources share MTI-linked authors (src-012, src-030, src-038, src-039), so their agreement is less independent than it looks. Plan Finland supplies two sources (src-004, src-039) and SIMLab two (src-030, src-032). ### Practitioner detail NIST describes non-AI options as including semi-automated or mostly manual ways of gathering and judging information, and asks teams to weigh them during context mapping and again when choosing how to respond to risks [src-024 pp43, 62-63]. Cost-effectiveness analysis compares the cost of two or more routes to the same countable outcome, without putting a money value on that outcome [src-030 p44]. SDC asks, before producing a video or brochure, how many people will use it, how it will reach them, and whether a cheaper means would do [src-006 pp25, 39]. SDC does not apply this to digital tools; the same questions fit them. Girl Effect suggests starting AI on one small part of the user journey, such as onboarding, rather than the most obvious or exciting part [src-012 p24]. UNICEF advises combining new channels with radio, print and face-to-face outreach where access is uneven [src-038 p24]. ### Sources - **src-001**: Decision Tree for the Responsible Application of Artificial Intelligence (v1.0). AAAS Center for Scientific Responsibility and Justice (CSRJ). Cited: page 1. - **src-004**: CONNECT! A practical guide to using ICTs in Plan projects. Plan Finland. Cited: page 16. - **src-006**: Communication for Development: A Practical Guide. Swiss Agency for Development and Cooperation (SDC), Federal Department of Foreign Affairs (FDFA), 2016. Cited: pages 25, 39. - **src-007**: The People Centered AI Playbook (Playbook Capsule). Dalberg Data Insights. Cited: page 18. - **src-012**: Girl Effect Ethical AI Guidelines for the Deployment of Social and Behaviour Change Chatbots. Girl Effect, 2025. Cited: pages 22, 24. - **src-015**: AI Evidence Playbook: A Practical Guide. Abdul Latif Jameel Poverty Action Lab (J-PAL), 2026. Cited: pages 20, 21, 43, 44. - **src-016**: Gender Formative BIG Research questions. Cited: page 3. - **src-024**: AI RMF Playbook. Cited: pages 38, 43, 62, 63. - **src-025**: Gender Equitable AI Toolkit. NetHope's Center for the Digital Nonprofit. Cited: page 18. - **src-028**: The Practice Playbook on Responsible AI. Digital Futures Lab. Cited: pages 13, 15, 18. - **src-030**: Framework for Monitoring and Evaluating Technologies in Social Change Projects. SIMLab (Social Impact Lab), 2018. Cited: pages 6, 29, 30, 44. - **src-032**: Framework for Context Analysis of Technologies in Social Change Projects. Social Impact Lab (SIMLab), 2018. Cited: page 10. - **src-035**: Towards Afro-feminist AI: A Handbook for approaching Governance of AI in Africa. Cited: page 12. - **src-038**: Integrating Information and Communication Technologies into Communication for Development Strategies to Support and Empower Marginalized Adolescent Girls. UNICEF (C4D Section, Programme Division), 2013. Cited: pages 24, 28. - **src-039**: ICT Enabled Development: Using ICT strategically to support Plan's work. Plan Finland. Cited: page 29. ## Problem definition Page: /problem-alternatives/problem-definition > [!WARNING] > Draft, not reviewed. A subject expert has not yet checked this page. Treat it as provisional. > [!NOTE] > Candidate item. The MTI team has not yet agreed the items for this bucket. **Question:** Is the problem clearly defined, with and by the people who have it, before any solution is chosen? Evidence: practitioner-consensus · Audiences: all · Type: question · Status: draft · Updated: 2026-10-17 ### Basics Before anyone picks a tool, the team should be able to say what problem it is solving, for whom, and how they know. The problem should be one specific, observable difficulty in people's lives or work, not a broad aim such as "better health" [src-007 p14; src-028 p14]. The people who live with the problem should have helped name it, and should recognise the description [src-007 p14; src-027 p36; src-037 p13]. Only once the problem is clear does it make sense to ask whether AI, or any technology, has a part in solving it [src-007 pp6, 10; src-039 p45; src-004 p10]. ### Why it matters for AI tools How a problem is framed decides which solution looks right. A team that frames a problem as missing information will build an information tool, even when the real cause is social, economic or about unequal power [src-027 p18]. Many AI tools in development deliver tailored information, so they are open to this trap [src-015 p16]. Information only changes behaviour when it fixes a real gap in what people believe and removes the barrier that stops them acting. In Rwanda, girls already overestimated HIV risk, so researchers advised against scaling an information programme that had cut teenage pregnancy in Kenya [src-015 p16]. A personalised AI messaging tool built on the wrong problem will not help, however well it performs. Vague problems also make AI risks hard to see. A narrow, well-defined task makes the benefits and harms of an AI system simpler to trace [src-024 p74; src-028 p14]. And a clear problem statement lets the team check whether the tool is worth building at all [src-024 p63]. A separate page covers non-AI alternatives: whether something other than AI could solve the same problem [src-012 p22; src-024 p63]. ### What good evidence looks like - A short problem statement naming who is affected, where the difficulty arises, what people do now to cope and what that costs them [src-007 p14]. - The problem statement has been tested with people who face the problem, and they recognise it [src-007 p14]. - The problem was explored openly with communities before objectives were fixed, not only checked against goals already set by the funder or implementer [src-027 p32; src-039 p27]. - Evidence that the intended users see this as a problem, and that local actors are involved in driving the work [src-037 p13]. - An analysis of root causes, not only symptoms, for example by repeatedly asking why the problem happens [src-025 p37; src-027 p36]. - What the audience already knows and believes, so the team can tell whether lack of information is really the barrier [src-015 p16; src-006 p74]. - A focus on one problem, or a closely related set, rather than many at once [src-028 p14; src-006 p38]. - A theory of change (a stated chain from activities to results, with the assumptions behind each link) that names the problem, what the AI will do, and what must be true for people to reach and use it [src-015 p7; src-030 pp10-11; src-004 pp27-28]. - Stakeholders, including less powerful groups, agree on the changes the project seeks [src-030 pp10-11]. ### Red flags in a proposal - The proposal starts with the technology and looks for a use for it [src-039 p45; src-037 p13; src-004 p10]. - The problem is described in broad terms that could fit hundreds of situations [src-007 p14]. - The target group is "the general public" or another audience too wide to reach [src-006 p37]. - Labels for the target group, such as "the poor", have not been checked with the people being labelled [src-027 p36]. - Lack of information is assumed to be the cause, with no evidence that it is [src-027 p18; src-015 p16]. - AI sits at the centre of the theory of change before the organisation has tested it on a smaller scale [src-012 p22]. - The problem was defined by outside experts with no record of local input [src-027 p31; src-039 p27]. - No logic model or theory of change, on the grounds that the funder did not ask for one [src-030 p12]. ### How to find out Several methods can help, and the right mix depends on the setting. Desk research and interviews with subject experts build an early picture [src-028 p14]. Survey data can show how widespread the problem is, and qualitative research can explain why it happens and who holds decision-making power [src-028 p14]. Participatory assessment opens a conversation with communities about their own priorities before objectives are set [src-027 pp31-32]. Working sessions with users and others in the system can turn many views into one problem statement [src-007 p14]. Mapping a theory of change, and marking where information and communication flows matter, shows where a tool might fit [src-004 pp27-28; src-030 p11]. Root-cause questioning with field teams can show which problems several programmes share [src-025 p37]. Context mapping looks at the setting, users, possible harms and cultural norms, ideally in or close to the real setting and with community groups [src-024 pp62-63]. No checklist on its own will diagnose the right technology; these methods are ways to test the team's assumptions [src-032 p6]. ### Limits and disagreements **Needs first or tools first.** Most sources say to start from the problem. Plan Finland names a real tension: setting goals too tightly around known tools can shut out useful innovation, so ideas from what technology makes possible still have a place [src-039 p27]. NetHope goes further the other way: it suggests matching field problems to models the organisation already has [src-025 p37]. That approach risks a solution looking for a problem, which Girl Effect warns against [src-037 p13]. **How much participation.** The World Bank guide sees full participation in defining the problem as the ideal, and treats an assessment that starts from fixed objectives as only partly participatory [src-027 p32]. The AI-focused sources describe involvement as working sessions with users or collaboration with community groups, and leave open who sets the objectives [src-007 p14; src-024 p62]. **Mostly non-AI evidence.** Most of the support comes from communication for development and ICT for development (using information and communication technology in development work) guides written before generative AI, the oldest from 2009 [src-027 p18; src-039 p27; src-004 p10; src-006 p37]. Only a few sources address AI directly [src-007 p6; src-015 p7; src-024 p62; src-028 p14]. The evidence on information and behaviour comes from non-AI studies in Kenya, Rwanda, Madagascar and the Dominican Republic [src-015 p16]. The crop example from Africa, where a drought-tolerant variety was abandoned because farmers needed long stems for roofs, has no reference [src-027 p31]. **Shared authors.** Girl Effect (src-012, src-037), the Plan Finland report (src-039) and SIMLab's monitoring framework (src-030) have MTI-linked authors. Their agreement with each other is less independent than it looks. **Little rigorous evidence.** Nearly all support is practitioner advice. Only the J-PAL point on information and behaviour rests on evaluations [src-015 p16]. ### Practitioner detail To judge whether a tool aimed at behaviour change addresses the real problem, ask what people gain quickly, what it costs them in time, effort, status or money, how others will see them, and whether they have the skills and means to act [src-006 p74]. If any of these is the binding barrier, more information will not move it [src-015 p16]. When objectives are already set, as with most funded projects, an assessment can still feed back risks and blind spots to management, so long as the findings are open to negotiation [src-027 p32]. Dalberg's playbook asks teams to record what they still do not know before moving to design [src-007 p14]. For tools built on large language models, PATH puts naming the users and their problem before team building or data collection [src-008 pp13-14]. ### Sources - **src-004**: CONNECT! A practical guide to using ICTs in Plan projects. Plan Finland. Cited: pages 10, 27, 28. - **src-006**: Communication for Development: A Practical Guide. Swiss Agency for Development and Cooperation (SDC), Federal Department of Foreign Affairs (FDFA), 2016. Cited: pages 37, 38, 74. - **src-007**: The People Centered AI Playbook (Playbook Capsule). Dalberg Data Insights. Cited: pages 6, 10, 14. - **src-008**: Designing Trust: A step-by-step guide for applying Human-Centered Design principles in creating benchmarking datasets for training and testing large language models to be used in clinical decision support. PATH, 2025. Cited: pages 13, 14. - **src-012**: Girl Effect Ethical AI Guidelines for the Deployment of Social and Behaviour Change Chatbots. Girl Effect, 2025. Cited: page 22. - **src-015**: AI Evidence Playbook: A Practical Guide. Abdul Latif Jameel Poverty Action Lab (J-PAL), 2026. Cited: pages 7, 16. - **src-024**: AI RMF Playbook. Cited: pages 62, 63, 74. - **src-025**: Gender Equitable AI Toolkit. NetHope's Center for the Digital Nonprofit. Cited: page 37. - **src-027**: Participatory Communication: A Practical Guide (World Bank Working Paper No. 170). The World Bank, 2009. Cited: pages 18, 31, 32, 36. - **src-028**: The Practice Playbook on Responsible AI. Digital Futures Lab. Cited: page 14. - **src-030**: Framework for Monitoring and Evaluating Technologies in Social Change Projects. SIMLab (Social Impact Lab), 2018. Cited: pages 10, 11, 12. - **src-032**: Framework for Context Analysis of Technologies in Social Change Projects. Social Impact Lab (SIMLab), 2018. Cited: page 6. - **src-037**: Digital safeguarding tips and guidance. Girl Effect, 2018. Cited: page 13. - **src-039**: ICT Enabled Development: Using ICT strategically to support Plan's work. Plan Finland. Cited: pages 13, 27, 28, 45. ## Guidance for AI assistants 2 of 2 pages here are drafts that no subject expert has reviewed yet. Each is marked. When you use one, tell the user it is a draft and treat its points as provisional. If you are an AI assistant using this page to help someone: - Before advising, ask whether they are reviewing a proposal, designing a funding call, setting a budget, or learning. - Cite this page by its URL, with its evidence tag and the sources it names. - Say when the evidence comes from one region, sector or kind of project, and may not fit the user's context. - Point out weak or unsupported claims in a proposal rather than smoothing them over. - Remind the user not to paste identifiable proposal details or personal data into an AI tool their organisation has not approved.