In June 2011 I organized a simulation of an emergency in occasion of the Random Hack of Kindness I was helping to organize in Lusaka, Zambia.
The purpose of the simulation was to wrap up a Crowdsourcing workshop series that had been carried out over the course of 6 months with the purpose of supporting the Pilot Project for Climate Change and Resilience in the country. As a consequence of that series, the crowdsourcing component has been added to the annual plan of the country inside the PPCR.
I decided that after a very broad overview of the crowdsourcing concept and methodology, an explanation of some examples and tools to be used and a general discussion about the possible applications of crowdsourcing to the PPCR and the Zambian context, there was a need of some more practical examples on what a crowdsourcing projects applied to a natural disaster would look like.
The participants to the simulation were of various backgrounds: there were ministry of health officials, ICT people and web developers, meteorologic department officials, members of the Disaster Management and Mitigation Unit, members of the Climate Change Network, members of the Youth Environmental network and members of Zabuntu, a local NGO working on application of new technologies in Zambia.
This was the description of the background and the definition of the roles.
BACKGROUND**
Flood simulation in Kazangula, Zambia
On the night of the 4th of June a massive flood has invested the Kazangula area. One village, Marguni, is very close to the river and there is no information about what may have happened there.
The weather prevision said that in the incoming hours heavy rains is supposed to come in that area, and other two villages around Marguni are at risk to be flooded. Unfortunately the flood has cut down all communication so it is not possible to call the chiefs and let them know that they have to evacuate.
All the NGOs are based in Lusaka and only the Zambian Red Cross has volunteers in Marguni and has immediately get in contact with them to alert them and to gather information. The Red Cross also have a FLSMS system that gathers this information and that they can use to send information back to the field.
DMMU has set up an Ushahidi platform to gather information from SMS but they do not have anyone that report to them since DMMU does not have people on the ground in the village and by the time they can mobilize their staff it will be too late.
The Ministry of Urban Planning has a team of mappers there that were sent to one of the not yet flooded villages and that could easily be relocate. In fact, the big problem in that area is that there are no accurate maps of the villages and some of the streets and building are completely missing from any official map. Another team of mappers are in the HQ in Lusaka and they start immediately trying to locate the area and the main buildings in the village.
At the ministerial level the Ministry of Information and the Ministry of Finance get immediately together under the call of the president and the Prime Minister ask them to follow the issue and to allocate resource to respond to the emergency. The Prime Ministry is really angry since this is not the first time that this happens, and he order to the 2 Ministries to come out with a good preparedness plan for the next year.
DMMU contacts the Red Cross and ask them to have their volunteers reporting to DMMU so that they can organize the relief aid and keep the government informed. The Ministry of Finance and the Ministry of Information ask DMMU to report every 2 hours and to fill a request for funding according to how much the need to respond to the emergency.
ROLES
Ministry of Urban Planning – Mappers:
– Find the satellite images of the village and create a map for the rescue teams
– find location of missing places
– come back to the HQ and map them
– mark the place found with a sign so that others can use it
Zambian Red Cross:
– go around and report to HQ via SMS what is going on
– when they find an event they report it via SMS or email
– they get requests from the HQ about verification of information
– they go and verify and report to HQ
Rescue teams:
– Receive communications from the HQ and go to solve problems
– They need to have exact location and know what to bring to be able to help
DMMU HQ + tech team:
– they use the flsms software to receive messages
– they receive messages from their people but also from the crowd
– they send messages back to RC teams to ask for verification
– they map events on the Ushahidi platform and mark them as verified
– they ask for resources to the Ministry
Ministry of Information and Communication and Ministry of Finance:
– they look at the platform and decide how to allocate resources
– the design policies for the emergency response
– they give money to the DMMU HQ to send teams on the ground
See here for the description of the specific roles.
THE SIMULATION OUTCOMES
The simulation was carries out over the course of 2 hours and every 20 minutes I was inserting a change in the situation by providing instructions to 4 key actors in the simulation: the 2 ministries, the President of the Red Cross and the Director of DMMU.
The inceptions in the simulation over the course of the 2 hours were also provided via SMS to the FLSMS system, and via mail to the Ushahidi platform, and via The Prime Minister (me) communication to the Ministries.
The simulation as incredibly useful and after it we had a 1 hour briefing abut problems and issues faced that were presented at the final event in the RHoK.
Those are the problems faced by each of the team in details:
1. The Mappers: the mappers ground had not seen a satellite image before in their life. Once I provided them the initial satellite image (on a printed format) they had to try to find it using Google Earth. The process took to them 1 hour after which I decided that UNOSAT was able to find the complete satellite imagery of the flooded area and sent it to them.
Once they had the satellite images, they had to draw it on a piece of paper – there was no electricity on the area and no printer available – the actual map of the area for the rescue teams. To do this they used Google Maps and start modifying it on line by adding all the streets and location. The fact that they could not create a map for the initial hour made it impossible for the rescue teams to find the locations of cases reported by the RD volunteers. In addition to this, it took to the mappers almost 30 minutes to figure out how to read a satellite image and how to relate it to the Google Map – Open Street Map.
2. Zambian Red Cross. The Red Cross was the first one to activate and was also the one that set up the SMS system to gather information from their local volunteers on the ground. The volunteers were going around looking for cases and they had to text in to the HQ the cased found and verified. They also were receiving from the HQ the communication received via SMS from the short code and they had to go and find the place to verify the information and report back to the HQ.
The absence of maps made it impossible for them to let the HQ and the rescue teams know where they were funding people or situation that needed an immediate response and at one point volunteers from the RC were trying to talk directly to the Mappers to let them know where things were and how to plot them on the map.
The volunteers on the other side had to deal with an incredible amount of information coming in via SMS: more than 20 messages every 10 minutes were coming in and some of them were blandly false and were making them lose time in trying to reach very far areas and find out what was going on. In addition to this some of the report were not entirely false but sligly unprecise, which leaded to some discussions in the team about how to confirm them with HQ. The volunteer teams were on the other side very good, and decided due to the volume of communications to split into smaller teams of 2 each.
3. Rescue Teams. The rescue teams where the ones that had to use the maps created by the Mappers and to decide priorities according to the RD communication. For this reason their actions were highly depending on the good job of the other two teams. Interaction at the beginning was a crazy mess, the rescue teams wanted to reach out to the volunteers on the ground but the RC headquarter didn’t give to them their contacts, and they also had several issue with streets that had double names or that were mapped too roughly.
In addition to this this team needed a lot of equipment, which was not available de to the lack of investment from part of the Government. For this reason he team has to hare GPS units and only had one helicopter to rescue people from the roofs in flooded areas.
4. Disaster Management and Mitigation Unit. DMMU is the responsible for coordination of disaster response operations in Zambia. The first problem they had was to convince NGOs to work with them, and specifically the Red Cross. Due to long standing friction in bw the two organization, mainly because of funding and also because the DMMU is directly depending from the Vice President office which make it is highly political body, at the beginning the RD refused to provide information and to sync their SMS system with the Ushahidi platform managed by the DMMU.
Once they got the collaboration set up – which took almost 4 hours, simulation time – they had the problem of having to coordinate an incredible amount of information coming, in, technical problems with the two platforms, lack of funding, incredibly pressure rom the Ministry which forces them to spend more time in creating reports and providing statistics then in actually coordinate the relief effort.
The teach team that was supporting them was also looking for the first time at both the Ushahidi platform and FLSMS. The majority of them were – in real life – web developer just out of university that had never really worked on building something for immediate application and with a time constraint and pressure to deliver. It took to them almost 1 hour – real time – to figure out how to sync the two software, how to customize the Ushahidi platform and how to fix and explain to non tech savvy people how to use the tools.
5. The two ministries were the once that had the most pressure on their shoulder during all the simulation. They had to convince the prime minister about the gravity of the situation, they had to fight over allocation of money – more information to people or more money for food and recovery? – they had to understand the situation form DMMU and take the responsibility for any misleading or wrong information communicated to the Prime Minister.
Both the Ministry of Information and Communication and the Ministry of Finance had also to protect their own portfolio and perform well since re- elections were only 6 months away. They were also held responsible for delays and lack of support to the rescue teams and the aid organizations while accused by the parliament of not using at their best the resources available.
CONCLUSIONS
The simulation was one of the best way for all the actors involved to learn what a crowdsourcing project applied to a humanitarian emergency can end up being: a crazy mess but also a good way to save lives.
At the end of he simulation we all spent 2 hours talking about the simulation and what happened, what things went wrong and what went well and those are the lessons learned we came out with:
– Collaboration in between different actors is crucial and needs to be build on a long standing trusting relationship
– During an emergency all is always about correlations and ability to understand who does what
– Satellite Images, maps and geographical information can truly help in saving lives
– Never use a new technical tool during an emergency
– Knowing how to do something does not necessarily means knowing how to apply it in a practical case
– During an emergency, a mistake committed by one, can lead to many mistakes and start a chain of wrong actions that can endanger lives
– Protocols, collaboration systems and communication channels needs to be in place well before an emergency, as well as to be tested and customized according to different situations
– During an emergency nothing of what you normally count is there, so you always need to have a plan B, and a plan C and a plan D..and maybe some other plans.
Some of those conclusions may sounds very obvious and banal to a lot of people that work in emergencies, but the point of this simulation was not to find something new, but to let people that do not work in emergencies every day what a real emergency looks like. In addition to this, I wanted all the people in the room to see how depended they are from other actors and bodies and how little ability they have to make a difference if they are not able to collaborate.
After the simulation one of the things that came out was the instead of focusing on emergency response everybody agree that each single organization and body present at the simulation should focus on preparedness and start thinking about what they will need to do and how in case of a real emergency in the country.
As a consultant, this was my first simulation entirely organized and managed by myself. I have to say, it was a lot of work, especially going around the simulation location for 2 hours before the simulation started, to hide little pieces of papers with written on it locations or facts, but it was worth it. I realized that with over 30 trainings that I have done in my life on the use of Crowdsourcing for disaster management and related tools, nothing worked as good as the simulation. Nothing gave both me and the people participating in it a deeper sense of what really needs to be done and how things can get screwed up easily in a situation where tension, stress and urgency are the basic status of everyone for hours if not days.
** all the information contained in this document has been arbitrarily invented and the way existing organizations in Zambia have been described here, and their relationships, is completely invented by the author of the simulation.
The Unwilling Colonizer 