Talking about tools: an early warning system in Kenya

7 minute read

Communications workshop with community peace representatives—Kitale, Kenya

At SIMLab we place a lot of value on the time before a project begins—the design phase, which comes after a context assessment but before project implementation. Project design is the foundation of a project so we devote quite a lot of time and resources to ensure the project is set-up for success. We also ensure each of our projects is thoroughly documented and shared so that others can learn from our findings, failures and fun! Here are some insights about how organizations use, modify and abandon tools illustrated in part through our ICT4COP pilot project in Kenya.

In May SIMLab traveled to Kitale, Kenya to visit our partners in advance of our upcoming pilot on Early Warning Systems in Kenya, and to review the technology and communication systems in place. This project is part of our ongoing Horizon 2020-funded research on police reform and community policing described here.First, in November we conducted a Context Analysis based off of our framework which helps us to understand the people directly and indirectly targeted by the project; the community and culture in which they live; the market and technology environment; the political economy; and the implementing organization. We spoke with local police, community based security groups, village chiefs and elders, local youth, women and girls, and Handicap International (HI), our project partner. During the context assessment we also learned about other key organizations who support the work of HI on an armed violence reduction program—Justice and Peace Centre (JPC) and Free Pentecostal Fellowship in Kenya (FPFK).

After we had analyzed our notes and insights from activities conducted during the context analysis we found that SMS was the most inclusive way to communicate with the target groups for the project (more on that below). But we didn’t know how the technology and communications could be improved in the next phase of the program. In order to make recommendations and implement changes we needed to go to the project site to talk with staff, participants and other important stakeholders about how to best shape the project plan.

The Project: Early Warning System in Kenya

Since 2012, FPFK has run an Early Warning System that relies on SMS reports sent from community members, which are then read, responded to and forwarded to relevant actors through an SMS platform called ActiveXperts. Before starting the next phase of the project SIMLab needed to do a technical assessment to first understand whether or not ActiveXpert’s system was fit for purpose, and whether there were improvements that should be made. The context assessment made it clear that SMS is an inclusive, widely accessible channel in the target communities, which made ActiveXperts a feasible tool. But before committing to using the tool we needed to understand its features and how it was being used by FPFK. Specifically, we wanted to see whether ActiveXperts had the potential to help us close the feedback loop between incident reporters, the implementing organizations, local security institutions and other NGO actors in the area.

Some questions derived from our context assessment framework specific to the tool are:

• Does the tool require internet; does it have an offline mode?
• Does data remain in the system or can it be exported and saved in a locked and encrypted file?
• Is the tool open source?
• Is support for the tool offered? Over what channels (e.g. online, Skype,)?
• What costs are associated with the use of the tool?
• Are there capacity constraints associated with messages sent, received or stored in system?

Is a new tool the best way forward?

FPFK felt that SIMLab would be able to help make the EWS system work better, which to them meant replacing ActiveXperts for a new tool that would cover all the desired functionalities. In our experience, organizations hit a point where they feel the tool in front of them does not work in the way they need, and they stop using it. Sometimes the function of the tool is so essential to the organization that they immediately find a new tool and work through the kinks, but many times an organization will completely abandon tools for the task and take a backwards step to a manual, analogue solution. Can this be prevented?

Like so many of our conversations with implementers, FPFK felt ActiveXperts generally worked well, but there were some additional functionalities they wanted and felt a new tool would be the best way forward. Our first goal is to find out more about the tool and needs of the program without jumping straight to replacing the technology; this approach is often at odds with our client’s initial desires. Sometimes tools face problems with speed, efficiency, reliability, or lack of features, but many of these issues can be ameliorated within the tool itself. Usually, users know what they need, and they will often refer to another tool they’ve read about or heard of and say ‘won’t this tool fix our problem?’ This scenario and the frequency of ‘tool heresay’ is more fully teased out in a research report by The Engine Room where organizations were asked how they approach tool selection. We work closely with clients to discuss our methodology and instill confidence that we will help them implement the best solution.

Tool burnout

‘Tool burnout’ occurs when an organization is fed up with a tool not working in the way they would like. But we think tool burnout can often be prevented. One way to safeguard from this feeling of discontent over a tool could start with taking more time to choose the right tool from the beginning, really investing time in fitting the tool into operations, and learning how to use it. A proper context assessment that leads to a discrete design phase and tool selection can increase an organization’s confidence that the tool is fit for purpose. Could that confidence encourage organizations to continue making effort to make the tool work, ensure end-users know how to use it, ensure staff have the proper buy-in process, training and more?

It’s not just about the tool

Another mindset we start with, and try to help our clients to see, is that maybe the tool isn’t the problem after all. Rather, many challenges may be resolved by improving business processes and behaviors which are key to improving the overall system. We know that’s not easy to hear—tech is the easy thing to pick on, people and complex systems are not.

The trip to Kenya was no different. By the end of the visit we had a whole list of identified challenges and solutions, and it turns out some of the solutions are pretty quick fixes. For instance, there was quite a lot of manual work being done with the EWS, but after searching through the ActiveXpert documentation it turns out there are functions that weren’t configured but were readily accessible on the tool - such as auto responses, auto forwarding and contact groups. Luckily we will be able to hire someone from ActiveXperts who can make a few changes in a couple hours, and much of the technology will be straightforward and automated. But that’s the easy part. Although the automation will free up some of the time of the EWS staff, the solutions required to make the whole system work better will take extra time.

We’re still working out what various improvements to the overall system will look like, but we know we need increased training for those who submit SMS reports and data protection best practices for their mobile phones. With FPFK we will implement various hardware improvements such as a backup battery and phone for when the office loses electricity.

We will be working on the EWS in Kenya to help rural and remote pastoralist communities in northwest Kenya monitor and respond to violence and insecurity. We expect the northwest region, like several other hotspots in Kenya, to become increasingly insecure in the lead up to, during and following Kenya’s national presidential election in August. These political issues make our work even more critical, and we’ll continue to write about this essential project and our work on tool modifications and closing the feedback loop.