The partner selection question
Institutions, businesses and development organisations pursuing digital transformation must decide who will help them. The market offers large vendors, independent consultants and community-based organisations, each with different strengths. The right choice depends on what the work requires and what the organisation can sustain after the engagement ends.
It helps to separate two questions that are often blurred. The first is what kind of organisation could do the work well. The second is whether this particular organisation is a good fit for your needs, your culture and your budget. Answering the first narrows the field; answering the second makes the choice.
| Partner type | Typical strengths | Points to watch | Often best suited to |
|---|---|---|---|
| Large technology vendor | Scale, established products and broad support | Higher cost; standard products may not fit local workflows; less flexibility | Large, complex systems with long-term support budgets |
| Independent consultant | Specialist expertise and flexible engagement | Capacity of one person; continuity if they become unavailable | Short advisory tasks and targeted reviews |
| Community-based, youth-led not-for-profit | Closeness to users, practical focus and aligned incentives | Smaller capacity, so scope must be realistic and terms clear | Training, small-scale systems, pilots, and work that depends on local understanding |
The table describes tendencies, not rules. Individual organisations in each category vary widely, so due diligence remains essential.
The value of proximity
Young professionals leading organisations in their own contexts tend to be close to the realities they address: the devices people use, the language they prefer, the constraints on their budgets and time. This proximity shortens the distance between problem and solution. It also supports credibility with the young people, educators and small enterprises who make up much of the population that digital programmes aim to serve.
Proximity shows up in small decisions that add up. A team that uses the same networks and devices as its users will notice that a form is too heavy long before a distant team does. A team that speaks the users' language, literally and figuratively, will write instructions that are understood the first time. And a team that remains in the same community after a project ends is available when something needs adjusting.
Proximity is also a source of trust. People are more willing to try a new tool, and to report honestly when it fails, when they trust the people who introduced it.
The significance of aligned incentives
A not-for-profit structure changes the question a partner asks. Rather than how much can be sold, the question becomes how little is needed to solve the problem well. This orientation favours the simplest effective system, honest scoping and measuring success by what changes for beneficiaries. For small and medium-sized enterprises, it can also mean access to services without fees, subject to eligibility and capacity conditions set out in published terms.
It is worth being balanced here. A not-for-profit status does not guarantee quality, and institutions should assess every partner against the same criteria. What the structure can do is remove one source of tension: there is no commercial pressure to enlarge the scope of a project, sell additional licences or recommend a complicated system when a simple one would work.
Aligned incentives also affect how problems are handled. A partner whose success is judged by outcomes has reason to say early when an approach is not working, and to propose a simpler alternative. That candour is one of the most valuable things a partner can offer, and it is easier to sustain when revenue does not depend on the size of the project.
A practical orientation
Development partnerships are most useful when they produce something that works the following week: a trained team, a functioning website, a database that replaces scattered files, an app that fits an existing process. Emphasis on hands-on learning and functional solutions reduces the risk of outputs that are admired but unused.
A practically oriented engagement typically ends with:
- a trained team that can repeat the task without outside help;
- a working system, such as a website, database or app, in daily use;
- short written guidance that new staff can follow; and
- a clear plan for maintenance and for what comes next.
What to look for in any partner
Whatever the type of organisation, a short set of questions helps to assess fit.
- Does the partner start by understanding the problem, or by proposing a product?
- Can it explain its approach in plain language and set out clear terms of engagement?
- Does it design for local conditions, including connectivity, devices and language?
- How will results be measured, and by whom?
- What capability will remain with your team once the engagement ends?
Each question deserves a concrete answer. A partner who responds with examples, plain explanations and clear commitments is usually more reliable than one who responds with general assurances.
Turning the questions into due diligence
| Question | What a good answer sounds like |
|---|---|
| Does the partner start with the problem? | It asks about your tasks, users and constraints before suggesting any product. |
| Can it explain its approach plainly? | It uses everyday language, shares a written scope and avoids unexplained jargon. |
| Does it design for local conditions? | It describes how it tests on typical devices and connections, and in the relevant languages. |
| How will results be measured, and by whom? | It proposes a few simple indicators, agrees a starting point and commits to reviewing results with you. |
| What capability remains afterwards? | It includes training, documentation and a handover plan. |
Ways to structure a partnership
Partnerships can take several forms. The right one depends on the goal and on who will maintain the result.
- Training programme. A series of hands-on sessions for a defined group, such as a school's teachers or an association's staff.
- Build and handover. The partner designs and builds a system, trains staff to run it and then steps back.
- Advisory support. Periodic guidance on decisions such as tool selection, policy or data practices.
- Co-delivery with a funder or institution. The partner contributes delivery capacity within a programme designed together with the funder or institution.
Managing risks in a partnership
| Risk | Sensible safeguard |
|---|---|
| Scope grows beyond capacity | Agree a clear scope and phased milestones, and add work only by agreement. |
| A key person becomes unavailable | Ask how knowledge is shared within the team and what documentation exists. |
| Expectations are unclear | Put terms of engagement, responsibilities and timelines in writing. |
| Results cannot be shown | Agree indicators and a starting point before the work begins. |
| Dependency after the project | Make training and handover part of the deliverables. |
What a good first engagement looks like
- Start small. Choose one well-defined problem, such as training a team or replacing one set of records.
- Agree success measures. Decide together how you will tell whether the work succeeded.
- Deliver and review. Complete the work, then hold an honest review of what worked and what did not.
- Decide on the next step. Extend, adjust or conclude, based on evidence.
A modest first engagement reduces risk for both sides and builds the trust on which larger collaboration depends.
