Similar initiatives

Basics

Find out who else has built, or is building, a tool for the same problem with the same kind of users in the same place. Look at local groups, international agencies, government and private firms, and at the applicant's own organisation src-039 p13; src-004 p14. For each one, find out what they built, how it went and what they learned src-037 p13; src-028 p23. Then decide whether the new project should reuse, join, partner with or step back from that work, rather than start from nothing src-010 p4; src-030 p37.

Why it matters for AI tools

Health AI in Africa is a crowded field with little coordination. One guide on clinical language models describes funders, implementers and innovators working apart, which limits shared learning and leads to repeated effort src-008 p5. A large language model (LLM) is software trained on large amounts of text to answer questions in ordinary language.

Without a look at similar work, a team may spend donor money building a chatbot that already exists nearby. A guide on ethical chatbots lists duplication of existing initiatives as a way to waste development resources src-012 p21. The Principles for Digital Development say that going it alone wastes resources, which matters more when the money is public, and puts extra burden on the people served src-010 p4.

A landscape review also shows the pitfalls others have hit, so the team can plan around them src-028 p23. For AI tools, it can show whether a non-AI approach already works, and so whether AI is needed at all src-025 p18.

What good evidence looks like

• A list of similar tools and projects in the same country, sector and user group, with who runs each one and what it does src-028 p23; src-039 p13.
• For each similar project, what happened: results, problems and lessons, not only its name src-037 p13; src-028 p23.
• A search inside the applicant's own organisation, since past technology work is often not labelled as such and gets missed src-039 p13; src-004 p10.
• A comparison of other AI approaches, with their strengths and weaknesses set side by side src-025 p18.
• A clear statement of why existing tools, data or frameworks cannot be reused or adapted src-030 p37; src-010 p4.
• Named partners found through the review, and what each will contribute src-028 p25; src-039 p40.
• Notes from at least one conversation with someone who has built something similar, covering problems, upkeep and running costs src-031 p9.

How to find out

Desk research: search reports, project databases, blogs and network sites for similar tools in the same country and sector src-012 p21; src-039 p40. Blogs and networks are sometimes the only way to learn about projects still under way src-039 p40.

Internal mapping: ask colleagues and country offices directly what technology work they have done, since it may not show up in reports src-039 pp13, 22.

Stakeholder mapping: map technology providers, development projects and networks working in the area, with local partners or community volunteers src-004 p14; src-039 p13.

Interviews with builders: talk to people who have built a similar tool about problems, costs, maintenance and sustainability src-031 p9.

Case study review: collect case studies of other AI projects and compare their approaches in a simple table src-025 p18.

These methods suit different budgets and stages. If none can be done during design, the budget should set aside time for it in the discovery phase src-012 p21.

Limits and disagreements

The sources agree that teams should look before they build. They differ on why.

• Some frame the review as competitor analysis src-012 p21; src-028 p20. Others frame it as finding collaborators and reusing what works src-010 p4; src-039 p40. A funder may want to see both.
• NetHope's toolkit uses the review to show where existing systems fall short and where AI could add value src-025 p18. Girl Effect's safeguarding guide asks whether the project might get in the way of others with a better approach src-037 p13. The first can lead to a case for building; the second can lead to a decision not to build.
• Digital Futures Lab treats landscape analysis as core to every AI project src-028 p23. Plan's guidance treats it as a step that runs through the whole project src-039 p16.

Context limits:

• Six of the ten sources are not about AI. They come from earlier ICT for development work (using phones, computers and the internet in aid programmes), much of it from Plan in East and West Africa src-004 p14; src-039 p22. The advice is general, but the examples predate AI tools.
• The AI sources cover health in Africa src-008 p5, India across several sectors src-028 p23, chatbots for behaviour change src-012 p21 and gender in humanitarian work src-025 p18. None gives a worked example of a landscape review for an AI tool.
• Four sources share MTI-linked authors (src-012, src-030, src-037, src-039). Their agreement is less independent than it looks. src-030 also restates the Principles for Digital Development (src-010), so those two are close to one voice src-030 p35.
• Support is broad but shallow. Most sources give the instruction in a sentence or two. Only src-031 describes how to run one part of the review, and that is for an online course, not an AI tool src-031 p9.

Practitioner detail

A landscape review can feed the theory of change (a map of how activities lead to results). Digital Futures Lab lists competitor analysis among the first activities for a generative AI project src-028 p20. It also suggests a separate landscaping study to find partners who can help co-create, roll out and evaluate the tool src-028 p25.

PATH's planning tool puts the question of related or benchmark projects in its first stage, next to defining the problem and the users src-008 p14. Plan's guidance treats learning from others as both the first and last step, and asks teams to share their own lessons for those who come after src-039 p16.