Collaborative Cash Delivery (CCD) Network brings together humanitarian non-governmental organizations (NGOs) delivering cash aid in emergencies, cash that enables affected populations to leverage local resources to meet their needs without delay. CCD includes NGOs from 15 organizations, such as Action Against Hunger, Catholic Relief Services, Danish Refugee Council, International Rescue Committee, Mercy Corps, Oxfam, and Save the Children. By facilitating collaboration among the NGOs, CCD helps them reach greater scale and amplify their impact.
Collaboration among NGOs during emergency response operations is necessary for providing coordinated relief efforts. But unsurprisingly—given the fast-paced nature of responding to a crisis while still competing for donor funding—it is also challenging. In order to address this challenge, CCD needed a way to facilitate collaboration among its 15 member NGOs. So it joined forces with the VMware Pivotal Act team to explore addressing the following challenges:
-
Implementing the collaboration, which usually involves data management
-
Educating the member NGOs on the benefits of collaboration by making educational content easily accessible
-
Modeling a collaboration of NGOs to operate in an existing or future crisis
Making software choices based on sustainability
The VMware Pivotal Act team traveled to Washington, D.C.; Colombia; and Ethiopia to interview various NGOs. We needed to understand the problem while keeping in mind that any technical solution had to be affordable. Meeting with the NGOs in person would help us prioritize which of these three challenges to focus on together.
From our findings, we learned that the first challenge—of implementing the collaboration along with the associated data management—would be too expensive and beyond our capacity to solve because of data security requirements and the level of trust needed to work with the various NGOs.
We also deprioritized the second challenge—around educating the NGOs—because we realized it could be addressed initially in a lean way by giving the groups access to static content in the form of PDFs and other electronic documents, which are easily searchable. We also deprioritized the capacity planning and geographic mapping components of the collaboration as we didn’t know what data was needed to build them.
But we could tackle the third challenge, of modeling the ways in which NGOs could work together in a response, including removing any barriers to cooperation. This would involve walking them through all the steps of forming a collaboration, such as:
-
Segregating roles and responsibilities across the various NGOs
-
Registering beneficiaries (the people receiving the cash aid) across geographic areas
-
Managing contracts and relationships with financial service providers (FSPs)
-
Managing complaint response mechanisms (CRMs) across geographic areas
After in-depth research, we decided that modeling a collaboration was indeed the most beneficial and cost-effective problem to solve.
In the early phase, a few agencies offered to provide us with developers and designers who could help create the infrastructure needed for hosting the modeling tool. However with their limited technical resources and lack of funding, it became clear that they wouldn’t be able to continue the development or maintain the modeling tool themselves once it was built. That meant it would have to be designed, built, and hosted within a very limited budget, and operate without any further iteration or maintenance until the next phase of development could be funded.
Do more with less!
As soon as we had an initial idea of the user experience and low-fidelity wireframes of the modeling tool in hand, the engineering team began to look for low-cost ways to build and host the tool without expensive licenses and maintenance fees. We chose Google Cloud Platform over other cloud services due to its generous free tier quota and the free credits it provides for the first year of hosting.
In order to reduce the maintenance costs, we had to reduce the tool’s complexity by combining two or more components into one, such as the database, API, and web app. Google’s Firebase platform fit the bill with all of the following components hosted out of the box:
-
Cloud Firestore, which stores collaboration data in a NoSQL format
-
Firebase Authentication, which restricts access to collaborations through unique URLs without having to sign in or maintain usernames and passwords
-
Firebase Hosting, which hosts the Angular web app, which in turn provides the UI
All three components came with generous usage limits to get started under the Firebase Spark plan. Firebase then served as the single platform where all of the collaboration data was stored, processed, and served to clients. We also used Bitbucket Pipelines to create a low-cost CI/CD pipeline that would build and deploy source code from Bitbucket to Firebase Hosting.
In the end, we were able to build and host the product with very little cloud infrastructure expense. When working for clients with a limited budget, it helps to evaluate a wide breadth of cloud service providers based not only on their feature set but also their pricing flexibility.
A 3D problem
After several iterations of research, design, and development of the collaboration modeling tool, which had a name by then—ResponseBuilder—it consisted of the following capabilities:
-
Collaboration Details, where users could store basic information about the collaboration including details such as the agencies involved and the geographic areas affected
-
Program Design, which describes what the collaborating agencies want to do, and the processes and mechanisms they use to achieve their objectives
-
Delivery Design, a three-dimensional grid that maps duties, geographic areas, and agencies, the details of which were tricky (more on this later)
-
Contractual Design, which describes the governance, funding, agreements, etc.
-
Report, which displays a summary of the above sections
The Delivery Design page went through several iterations before taking its final shape. We had to find an intuitive way for a user to be able to assign agencies to each duty in each geographic area. Once it became clear that multiple agencies can perform the same duty in a single geographic area, we realized we needed to display three-dimensional data. That way, each agency working inside each geographic area to perform a particular duty could use a different tool/platform for data management, FSP, CRM, etc., all of which needed to be stored. We also needed to be able to easily move or copy agency and tool assignments from one geographic area to another. We developed and tested several UX patterns, including drag-and-drop tiles representing agencies inside a grid.
Delivery Design, where NGOs assign responsibilities for their collaboration by geography
Prototyping is critical
Although we deprioritized geographic mapping early on, we revisited the idea periodically in order to add graphic images to reports. There is a good chance the next phase of this project will display static or dynamic maps, because mapping is considered to be an important component in reporting and analysis.
The tool was built iteratively and was consistent with XP practices. Towards the end of the project, we had to shuffle priorities to meet a hard deadline for the team to demo it to various NGOs at a public event called Cash Week 2019. This led to us implementing several unvalidated features ahead of the event, which generally is not a sustainable approach to software development. And while we learned a lot from demoing the tool at that event, a better approach would have been if we’d created quick prototypes rather than fully functional features. Such prototypes would have also saved us time when it came to making necessary changes to the tool after the event was over. Finding a balance between delivering features that drive value for users vs. features that donors like and may agree to fund further isn’t a challenge unique to the impact sector.
ResponseBuilder is now live!
We had four engineers, two product managers, and one designer bring this tool to fruition. Six months after its release, the ResponseBuilder collaboration tool is alive and well. And because we took the time early on to consider ways to make it sustainable, the amount it’s costing the agencies to operate it is zero!
