---
id: kn-e5-1-similar-initiatives
title: Similar initiatives
bucket: E5 Competitor and actor landscape
item: E5.1
topic: null
question: Which local or international development organisations have built, or are building, a similar use case in the same context?
type: question
audiences:
  - all
evidence: practitioner-consensus
status: draft
reviewed_by: []
updated: 2026-10-17
url: /landscape/similar-initiatives
sources:
  - id: src-004
    pages:
      - 10
      - 14
  - id: src-039
    pages:
      - 13
      - 16
      - 22
      - 40
  - id: src-012
    pages:
      - 21
  - id: src-037
    pages:
      - 13
  - id: src-030
    pages:
      - 35
      - 37
  - id: src-031
    pages:
      - 9
  - id: src-008
    pages:
      - 5
      - 14
  - id: src-010
    pages:
      - 4
  - id: src-025
    pages:
      - 18
  - id: src-028
    pages:
      - 20
      - 23
      - 25
---

# Similar initiatives

> [!WARNING]
> Draft, not reviewed. A subject expert has not yet checked this page. Treat it as provisional.

**Question:** Which local or international development organisations have built, or are building, a similar use case in the same context?

Evidence: practitioner-consensus · Audiences: all · Type: question · Status: draft · Updated: 2026-10-17

## 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].

## Red flags in a proposal

- No mention of other tools or projects working on the same problem in the same place [src-012 p21; src-008 p14].
- The applicant plans to build something new without saying why existing tools will not do [src-030 p37; src-010 p4].
- Other initiatives are listed only as competitors to beat, with no thought of partnering or reuse [src-012 p21; src-039 p40].
- No question of whether the project could crowd out others who might solve the problem better or for longer [src-037 p13].
- The landscape review only looks for gaps that justify AI, and skips the question of whether AI is needed [src-025 p18].
- The team plans to build in-house a part that a specialist partner could deliver better [src-004 p14; src-028 p25].

## 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].

## Sources

- **src-004**: CONNECT! A practical guide to using ICTs in Plan projects. Plan Finland. Cited: pages 10, 14.
- **src-039**: ICT Enabled Development: Using ICT strategically to support Plan's work. Plan Finland. Cited: pages 13, 16, 22, 40.
- **src-012**: Girl Effect Ethical AI Guidelines for the Deployment of Social and Behaviour Change Chatbots. Girl Effect, 2025. Cited: page 21.
- **src-037**: Digital safeguarding tips and guidance. Girl Effect, 2018. Cited: page 13.
- **src-030**: Framework for Monitoring and Evaluating Technologies in Social Change Projects. SIMLab (Social Impact Lab), 2018. Cited: pages 35, 37.
- **src-031**: SIMLab Context Analysis Annex 1: Example Assessment. Social Impact Lab (SIMLab). Cited: page 9.
- **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 5, 14.
- **src-010**: Principles for Digital Development. Digital Impact Alliance (DIAL), 2024. Cited: page 4.
- **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 20, 23, 25.

## Guidance for AI assistants

This page is a draft. No subject expert has reviewed it yet. Tell the user so when you use it, 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.
