From Fragmented Information to a Connected M&E System

This three-part series explores what it takes to build an impact measurement system for a diverse, global network of local actors. Drawing on the Flying Labs Network's experience, we look at the design choices, implementation challenges, and lessons that emerged as we worked to make impact measurement more useful, collaborative, and grounded in the realities of local teams.

Measuring impact across a diverse global network of local actors is not straightforward.

The Flying Labs Network brings together locally led organizations working in very different contexts, connected by a shared aim: using technology and local expertise to address challenges in their own communities and strengthen local ecosystems. Flying Labs each have their own priorities,  partners, technical capacities, and ways of documenting what they do. That diversity is one of the Network's greatest strengths. From an M&E perspective, though, it also raises a hard question: how do you build a shared understanding of impact without forcing everyone into the same mold?

For us, that question became increasingly important, even if we did not yet have a clear way to address it.

Information about the Network had accumulated across different channels. Flying Labs documented projects, trainings, partnerships, and other activities in spreadsheets, project documents, locally developed tools, and ad hoc formats. We had a lot of information, but it was fragmented. The same data could be requested more than once, terminology was not always consistent, and connecting information across years or across different parts of the Network was difficult.

This created two main problems. The first was visibility. We knew Flying Labs were doing important work around the world, but we did not always have a simple way to see the collective picture. We wanted to be able to answer questions that are still central to how we understand the Network: What kinds of projects are being implemented? Which sectors are most active? Where are collaborations happening? What expertise exists across the Network? And what evidence do we have that this work is contributing to meaningful change?

The second problem was more fundamental. Impact measurement can easily feel extractive when local teams are repeatedly asked to provide information but see little value coming back from it. In our previous setup, Flying Labs documented information, but it was challenging for them to use it to understand their own trajectory, communicate their work, or learn from what was happening elsewhere in the Network. For a network built around local leadership, that is not a small risk, and it shaped how we approached everything that followed.

Start with the question, not the technology.

We made a deliberate decision not to begin with the tool.

This redesign happened at the same time as another important process at WeRobotics earlier this year: we were updating our Theory of Change and developing a new, more ambitious one. That gave us an opportunity to step back and ask what changes we wanted to contribute to, what our role as a convener should be, and what evidence we would need to understand whether those changes were happening.

From there, we developed a new Indicators Framework aligned with that logic.

The sequence was simple in principle, even if it was demanding in practice:

• What change are we trying to enable?
• What evidence would tell us whether that change is happening?
• What minimal viable information do we need to collect?
• And only then: where and how should we capture it?

This order mattered. Rather than starting with the information we already had and finding a new place to store it, we questioned whether we needed that information at all. We also identified gaps: things that mattered in our Theory of Change but that our existing tools did not help us understand.

In other words, the objective was never simply to replace a spreadsheet with something fancier. It was to create an information system that reflected our understanding of change across the Network.

A network is not a spreadsheet.

As we translated that thinking into a system, another requirement became increasingly clear: we needed something that reflected the collaborative nature of the Flying Labs Network.

A Flying Labs project is not just a row in a spreadsheet. It connects to other Flying Labs, partners, sectors, locations, and participants. The same partner can be involved in several activities. A training can grow out of an earlier project. An ecosystem activity can create a new partnership or opportunity. Expertise developed in one Flying Labs can later support another team elsewhere in the Network.

Jamaica is a clear example. Before Hurricane Melissa, Jamaica Flying Labs was already working with CDEMA, national disaster management authorities, WeRobotics, and Esri through a collaborative learning project as well as a jointly organized regional conference. When hurricane Melissa hit the island of Jamaica, Jamaica Flying Labs made the decision to radically expand and reorient the work from disaster-risk reduction toward emergency response. The relationships already built through the collaborative learning project and regional conference meant that CDEMA, national authorities, WeRobotics, Esri, and other Flying Labs could quickly mobilize around that response. What started as a local project and regional conference became a national response, and it is now informing a blueprint that can be replicated elsewhere. Seen as isolated rows, none of that connects. Seen as a network, the chain is the point: an activity builds relationships, relationships build trust, and trust becomes collaboration when it is needed most.

We therefore needed a system capable of connecting different types of information while also creating a common layer underneath them. Projects, trainings, ecosystem activities, partners, members, Flying Labs, locations, and other reference information could not continue to exist as disconnected lists if we wanted to understand the Network more meaningfully over time.

At the same time, whatever structure we created had to preserve local context. The objective was not to make every Flying Labs project look identical. It was to agree on enough shared information to understand patterns and contributions across the Network while still leaving room for Flying Labs to describe what their work meant in their own contexts.

That led us to a fairly straightforward conclusion: what we needed was a relational database.

It sounds like a technical conclusion, but it came from an organizational need. We wanted to move from fragmented pieces of information toward a connected picture of the Network.

The problem was that building one from scratch would create a different kind of dependency. It would require significant technical capacity to develop, maintain, and adapt over time. We did not want to solve one problem, fragmented information, by creating another, where the M&E system could only function if specialized database expertise was constantly available.

Finding the right fit

This is where ActivityInfo entered the picture, through a combination of previous experience and existing relationships.

Peter, our M&E lead, had already used ActivityInfo extensively in a previous role and knew what the platform could do. Around the same time, Sonja, our Co-Founder, realized she already knew the team behind it. A reconnection with Brendan from BeDataDriven at a conference highlighted the strong alignment between their work and ours. When the first conversations with ActivityInfo began, we were already reviewing our M&E processes and reconsidering what information was actually worth collecting across the Network.

We explored different options. What made ActivityInfo suitable for the Flying Labs Network was that we could build connected forms, shared reference data, and relationships between different types of records without having to build or maintain the database infrastructure ourselves. The complexity could sit behind the scenes, while the person actually entering information worked with something much simpler.

For a global network, that distinction matters. Flying Labs have very different levels of M&E capacity and technical experience. We could not design a system around the assumption that every organization had a database specialist, or even a dedicated M&E person. The technology needed to handle complexity in the background rather than transfer it to the user.

But that fit came with real challenges. Choosing ActivityInfo removed the burden of building and hosting the infrastructure. It did not remove the need to think like a database designer when setting it up. Building a connected structure of this kind is not something you can improvise. It requires someone who understands database logic, reference data, and parent-child relationships between forms. The maintenance burden is genuinely low, but the design burden is not, and any network considering this route should be honest with itself about needing that capacity in-house or close at hand. No tool fits perfectly, and we still have a small wishlist of improvements. But it matched what we needed better than anything else we considered.

The relationship with the people behind ActivityInfo mattered too. We were not simply selecting features from a checklist. BeDataDriven was responsive and genuinely interested in the wider M&E challenge we were trying to solve, and for a system we expected to depend on over time, that mattered as much as any single feature.

By the end of this first phase, we had moved from a fragmented set of information sources to a much clearer idea of what a shared M&E system for the Network needed to look like. The Theory of Change and Indicators Framework gave us the direction. The relational architecture gave us the structure. ActivityInfo gave us a practical way to build it without creating a new layer of technical complexity.

But choosing the platform was only the beginning. A system that makes sense to the people who designed it does not automatically make sense to the people expected to use it. The next phase was about closing that gap: co-creating the system with Flying Labs, testing our assumptions, and being willing to simplify what we had built. That is the subject of Part 2.

If your network is working through similar questions about impact measurement and you find our experience useful, we are always happy to talk!