Tips from the IFRC’s partnership with University College London
One of the best things about a network such as the IFRC (International Federation of Red Cross and Red Crescent Societies) is that there are lots of people willing to help, if only you know how to connect. This is a short blog about how one such connection was made between the GO team and a British university, and what we learned from the first exchanges.
The British Red Cross has strong links to academic partners in the UK and is generous in sharing those opportunities for the wider benefit of the 192 Red Cross and Red Crescent National Societies across the world. University College London is one of the world’s leading universities, with a focus on impactful research which benefits society, especially if that uses leading-edge technologies. The Industry eXchange Network (IXN) programme, a partnership between several British Universities (including UCL), tech companies, and third-sector organizations, is designed to match problems such as those the Red Cross Red Crescent (RCRC) tries to address, with solutions that academic and private sector institutions can deliver.
This type of programme is relevant for all RCRC societies as it reduces the need to invest humanitarian funding aimed at providing lifesaving assistance in innovative solution development and data science capacity. While that investment might lead to some major organisational gains to simplify procedures, automate routine tasks, build evidence and provide better data analytics, there is also a fair chance of ‘failure’, or wasted time and resources on underperforming or expensive solutions. Working with research partners helps to mitigate that risk, encouraging innovation and the freedom to try, fail, and try again. There’s also a distinct advantage of being able to work with students, whose fresh take on new or old challenges injects energy and creativity where there might previously have been fatalism and inertia.
Nevertheless, the worlds of humanitarian assistance and academia are not perfectly matched in motivation, concerns, rhythm, or approach. There’s almost a need for a translation service of some sort. Which is where the IXN comes in.
We are halfway through the first batch of project ideas to have been given the IXN ‘treatment’. The student groups have just presented their ‘elevator pitch’ solutions. Things are looking promising.
At the same time, we have identified some lessons for these types of computer-science-focused humanitarian-academic partnerships so thought it worth sharing with a wider audience here.
Get motivated
a. When searching for potential projects, cast the net wide and then prioritize. Problems and potential solutions can come from surprising places — it is worth taking the time to explain the opportunity to a wide audience to see what comes back.
b. Clarify who are the focal points or ‘problem owners’. Make sure there’s more than one per project as redundancy is essential. These types of programmes usually have strict timelines due to the academic calendar so, given that humanitarian personnel might be suddenly unavailable (e.g., because of a last-minute deployment to the field), multiple focal points guarantee continuity.
c. Ensure ownership. The problems need to be genuinely part of the responsibility or workload of the focal points. This way they will prioritize their engagement, rather than seeing it as yet another series of meetings or tasks.
Shape the problem
a. Briefly describe the project. You should be able to synthesize what the project is about and what you specifically want out of it in the length of a paragraph (3–4 lines). Sometimes in the humanitarian sector we lack clarity of the specific asks we have, as we feel the need to directly mention the potential impact and implications it might have; but many times, that lack of clear communication hinders the message, making it difficult for partners to understand what we actually need. We also use impenetrable jargon, but that’s a habit hard to shake.
b. Estimate the problem’s size and complexity. Evidently, it is quite difficult for us in the humanitarian sector to estimate whether a data science project will take 175 hours to develop or 350 hours. Nevertheless, it’s important to give an indication of how interconnected with other processes each idea is and how many elements and functions we foresee it would have. Defining the problem dimensions, however approximate, will massively help to identify the right team to tackle the solution, whether in terms of their skillset or seniority, e.g., undergrad or master students, whether it could be part of a course project or a thesis project.
c. Use keywords. As in an academic article, keywords help to summarize the central points of the content, even if those terms couldn’t make it to the header, or summary of the article. In those you could specify whether it is more of a software development project, or more of a data analysis project, which programming languages you would prefer the students use, and which aspects are specifically relevant to you.
Set the rhythm and deadlines
a. Different institutions have different timelines — ask for any deadlines or expected deliverable dates upfront to be able to plan.
b. Identify crunch moments. The level of needed interaction might fluctuate throughout the project so clarify what might be needed and at what point during the development.
c. Be realistic about your availability. Communicate how many hours you can dedicate to the project weekly. Set a recurrent meeting to safeguard the time and establish a rhythm.
Establish rules of engagement
a. Think about and document data protection. Consider your personal and institutional obligations regarding data that could be used to identify individuals (e.g. names, locations, and photographs), IT security, and potential reputational risks of the project. The IFRC has some resources that can help with data protection.
b. Alert your legal and partnership colleagues early. Remember to spare enough time for any necessary clearance to happen in case they need to formulate terms of reference or shape agreements accordingly. Try to identify early if there are likely to be problematic clauses so that you can find solutions together. Don’t make your bad planning someone else’s emergency.
c. Be willing to compromise. There might be a need to find a middle point between your institution and the students’/developers’ vision for the solution. Keep verifying that you are still on the same page. If not, clarify what can and cannot be expected from both sides.
d. Clarify who the students can contact. Will it be only the team of ‘focal points’? Or would you be able to connect them with staff in the field? Students might feel the need to directly talk to ‘final users’ which might or not be possible within your specific context. If doing so, make sure to manage expectations on both sides. You might consider that it is only when there is sufficient trust built in the potential solution that then it is worth your colleagues’ time to engage in the project.
The road to building lasting partnerships is long, slippery, and full of unexpected hurdles. We hope the above motivates and guides you to take on the journey toward more meaningful collaboration.
