In 2016, I spent most of my time on a project helping politicians, donors, civil society and media in Sekondi-Takoradi (Ghana) to co-create commitments for a metropolitan open government action plan. Two of the commitments that were made related directly to open data.

In July 2017, I realised that many of the issues we were discussing at the African Open Data Conference (AODC) were similar to the ones I’d seen in Ghana.

These links got me thinking about the importance of sequencing in designing open government initiatives.

Getting the sequence right

Open data actors can often start by fixating on the solution they want to implement, and then working backwards to find a problem that fits.

This is easy to do. It’s often more exciting to dive into technology than to pause and really try to understand the problem you want to solve. Exploring the types of technology available, the data you have to play with, and working out what you can do with limited resources is both fun and engaging.

But it’s usually the wrong way to start.

My experiences in Sekondi-Takoradi showed me that the sequence matters. Before you decide on an open data solution, you need to define the problem you want to address and the people your project wants to help.

Sometimes, going through this process might make you realise that you need very little technology – or even none at all. At other times, taking this time to reflect could lead your project down an entirely different path.

Either way, locking down definitions of the problem and the people you’re aiming to help gives you an anchor that can ground you for the rest of the project. (In fact, it’s the very first question we ask in Alidade, our interactive guide to bringing technology tools into a project.)

These definitions are also useful for others:

• Funders can use the definitions as a base for conversations about grant success.
• Civil society organisations can use them to measure their progress.
• Governments can use them to translate their agendas into assessments of whether initiatives are making tangible differences to citizens’ lives.

What happens when we invert the sequence?

Here are the lessons I shared at AODC:

In Sekondi-Takoradi, all the actors agreed that ‘open data’ was a powerful, useful commitment area that could improve governance by increasing transparency and economic growth. However, there were more differences when it came to the best way of implementing open data.

At first, they developed solutions and searched for problems. Here, whatever the solution could address was labelled “the problem” – whether it was a real problem or not. When it became clear that the ‘solution’ was going to fail, users took the brunt of the blame.

I came across many examples of the problems this caused:

• An international NGO developed a platform to increase community participation in planning, budgeting and generating revenue in the municipality, particularly among people living in slums. Although a lot was spent on the platform, very few people used it. Three years later, the technocrats and citizens we spoke to felt that that the platform needed a lot of work to use and maintain. It clearly wasn’t the right solution for the problem at hand: a different, cheaper solution could have achieved the same (or better) results.
• After the municipality won a challenge, a global database management organisation offered it expert technical assistance on job-creation, transportation, public safety, healthcare, revenue and social services that was worth half a million dollars. However, they offered the solution – expert technical assistance – before understanding the problem that the municipality was facing. Some people we talked to were worried that the skills they offered might not fit the needs of the municipality.

The Engine Room has often seen this trend in other countries, too. For example, more than half of the 38 organisations we interviewed in Kenya and South Africa as part of a Making All Voices Count research project chose a tech tool for their project before they even knew what they would do with it.

Running a successful open data project involves choosing the right range of skills to accompany it, including questions like how you will acquire users, what kind of training you will offer, and how you will advocate for the initiative in public. It’s impossible to know which of these will enable your solution to succeed if you don’t define your problems and the profiles of your users first.

What’s next?

The Engine Room’s Matchbox programme works with partners to explore ways to increase their impact using data and technology. In Matchbox, we define the problem and user profiles first, and then discuss creating a solution. It seems like a simple tweak, but it’s critical.

We find that the sequence helps to shape our partnerships. For example, in May 2017, the Anti-Corruption Coalition of Uganda (ACCU) joined Matchbox. When we first met, they were interested in developing a new technology tool to increase citizen participation in anti-corruption actions for the health supply chain in Uganda. However, they have now changed their approach, pivoting towards an advocacy campaign to make existing tools designed to increase health supply chain efficiency.

They made the decision on the basis of desk research into health supply chains, and on-the-ground research in one of the communities where the tools are being used. This stage involved contextual inquiries, ethnographic research, interviews, process analysis and ecosystem mapping. We spent a lot of time talking to frontline managers at health facilities, district health teams, citizens and local NGOs to get a deeper understanding of actors around the supply chain, and learn more about the context in which they worked.

After creating several different simulations in which we placed the problem side by side with the resources that the partnership had available, we decided not to build a new tool.

We also realised that a set of existing solutions might be able to tackle the problem that ACCU was trying to address.

As we go forward, we’re collecting questions about the existing tools we’re starting to work with. What is the user experience like for these tools, and can it be improved? Do the tools fit well with existing processes and incentives in the communities we’re working with? How should we manage conversations with the owners of these technologies if we think we’ll need to propose or implement changes or integrations?

It was great to have the opportunity to discuss these issues at AODC. This is an evolving process, and we and others are continuing to learn more about these questions as an open government community. Each time we come together to solve problems and discuss strategy at events like AODC, we come away with lessons learned and new questions to investigate. I’m looking forward to the next one.